Absolute paths in man page links such as
```
[some link](/foo/bar)
```
Were being interpreted as relative paths when rendered in HTML. This
issue was observed in #20889 and #20041.
The fix is to make sure we don't leave any absolute paths when parsing
links. Instead we check if a directory is absolute (by checking for `/`)
and add `file://` accordingly. This turns the above link into:
```
[some link](file:///foo/bar)
```
Which does get interpreted correctly when rendered as HTML.
- fixes#20889
- fixes#20041
Before this patch, opening the Help application would raise an error.
Now all the pictures in the man pages render correctly.
There are a bunch of tests that check for time_t handling 64-bit values
properly. This makes sense, but also obviously doesn't work when time_t
is 32-bit, and causes compile-time errors. Compile these tests out in
that case.
Since there's no straightforward way to check sizeof(time_t) inside the
proprocessor, only do this when glibc's __TIMESIZE is defined.
This is defined when we're compiling against the GNU C Library, whether
on Linux or on other kernels that glibc works on. More AK_LIBC_xxxx
definitions could be potentially added in the future.
Also add AK_LIBC_GLIBC_PREREQ(), which checks for a specific glibc
version.
Previously if the IDL was something like:
```
constructor(optional DOMString data = "");
```
We were generating code that would be passing through to the constructor
an Optional<String> - even though for this situation it is not possible
for it to be null.
Instead, if we know if there is a default value that is non-null and the
type is not nullish, just generate the cpp code as a String.
This change allows IDL interfaces to be compiled using new AK String
which have a attribute in the interface that may return null.
Without this change we would run into a compile error from code such as
the following example:
```
auto retval = impl->deprecated_attribute(HTML::AttributeNames::ref);
if (!retval.has_value()) {
return JS::js_null();
}
return JS::PrimitiveString::create(vm, retval.release_value());
```
As `deprecated_attribute` returns a `DeprecatedString` instead of an
`Optional<String>`. Fix that by using the non-deprecated attribute
implementation, and falling back to the empty string for where we cannot
return null.
Also add a test here to cover a regression I almost introduced here
which was not previously covered by our test suite.
Ideally, all of this should actually just be calling
Element::get_attribute_value, but I'm not entirely sure at this stage
what the behavioral change would be to test for here. Since this
implementation preserves the previous behavior, stick with it, and add a
FIXME for now.
This should allow us to add a Element::attribute which returns an
Optional<String>. Eventually all callers should be ported to switch from
the DeprecatedString version, but in the meantime, this should allow us
to port some more IDL interfaces away from DeprecatedString.
