This uses ICU for all of the Intl.PluralRules prototypes, which lets us
remove all data from our plural rules generator.
Plural rules depend directly on internal data from the number formatter,
so rather than creating a separate Locale::PluralRules class (which will
make accessing that data awkward), this adds plural rules APIs to the
existing Locale::NumberFormat.
This uses ICU for the Intl.NumberFormat `format` and `formatToParts`
prototypes. It does not yet port the range formatter prototypes.
Most of the new code in LibLocale/NumberFormat is simply mapping from
ECMA-402 types to ICU types. Beyond that, the only algorithmic change is
that we have to mutate the output from ICU for `formatToParts` to match
what is expected by ECMA-402. This is explained in NumberFormat.cpp in
`flatten_partitions`.
This lets us remove most data from our number format generator. All that
remains are numbering system digits and symbols, which are relied upon
still for other interfaces (e.g. Intl.DateTimeFormat). So they will be
removed in a future patch.
Note: All of the changes to the test files in this patch are now aligned
with both Chrome and Safari.
Note: We keep locale parsing and syntactic validation as-is. ECMA-402
places additional restrictions on locales above what is required by the
Unicode spec. ICU doesn't provide methods that let us easily check those
restrictions, whereas LibLocale does. Other browsers also implement
their own validators here.
This introduces a locale cache to re-use parsed locale data and various
related structures (not doing so has a non-negligible performance impact
on Intl tests).
The existing APIs for canonicalization and display names are pretty
intertwined, so they must both be adapted at once here. The results of
canonicalization are slightly different on some edge cases. But the
changed results are actually now aligned with Chrome and Safari.
If we get a suggestion from fontconfig, we try those fonts first, before
falling back on the hard coded list of known suitable fonts for each
generic family.
This saves us the trouble of maintaining our own implementation,
and instantly brings us to full WOFF2 feature parity with others.
Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
GC-allocated objects should never have JS::SafeFunction/JS::Handle
fields.
For now the plugin only emits warnings here, as there are many cases
of this occurring in the codebase that aren't trivial to fix. It is also
behind a CMake flag since it is a _very_ loud warning.
Download files to a temporary location, then only move the downloaded
file to the real location once the download is complete. This prevents
CMake from being confused about partially-downloaded files, e.g. if
someone presses ctrl+c in the middle of a download.
Note the GN build already behaves this way.
We already have required this version for quite a while for Lagom,
Ladybird and Serenity. Now that we require it in all of our CMakeLists,
let's scrub for better ways of writing things.
On macOS, it's not trivial to get a Mach task port for your children.
This implementation registers the chrome process as a well-known
service with launchd based on its pid, and lets each child process
send over a reference to its mach_task_self() back to the chrome.
We'll need this Mach task port right to get process statistics.
JPEG2000 is the last image format used in PDF filters that we
don't have a loader for. Let's change that.
This adds all the scaffolding, but no actual implementation yet.
And add a verification step to the emoji data generator to ensure all
emoji are listed in this file. This file will be used as a sources list
in both the CMake and GN build systems.
It is probably possible to generate this list. But in a first attempt,
the CMake code to set the file as a dependency of a pseudo target, which
would then parse the file and install the listed emoji was getting quite
verbose and complicated. So for now, let's just maintain this list.
For Ninja Multi-Config, Xcode and Visual Studio, the way we set up our
output directories would result in exectuables that can't run from the
build directory. Add the same sauce that we added to Jakt to insert
``$<CONFIG>`` where appropriate.
CMYK data describes which inks a printer should use to print a color.
If a screen should display a color that's supposed to look similar
to what the printer produces, it results in a color very different
to what Color::from_cmyk() produces. (It's also printer-dependent.)
There are many ICC profiles describing printing processes. It doesn't
matter too much which one we use -- most of them look somewhat
similar, and they all look dramatically better than Color::from_cmyk().
This patch adds a function to download a zip file that Adobe offers
on their web site. They even have a page for redistribution:
https://www.adobe.com/support/downloads/iccprofiles/icc_eula_win_dist.html
(That one leads to a broken download though, so this downloads the
end-user version.)
In case we have to move off this download at some point, there are also
a whole bunch of profiles at https://www.color.org/registry/index.xalter
that "may be used, embedded, exchanged, and shared without restriction".
The adobe zip contains a whole bunch of other useful and fun profiles,
so I went with it.
For now, this only unzips the USWebCoatedSWOP.icc file though, and
installs it in ${CMAKE_BINARY_DIR}/Root/res/icc/Adobe/CMYK/. In
Serenity builds, this will make it to /res/icc/Adobe/CMYK in the
disk image. And in lagom build, after #23016 this is the
lagom res staging directory that tools can install via
Core::ResourceImplementation. `pdf` and `MacPDF` already do that,
`TestPDF` now does it too.
The final piece is that LibPDF then loads the profile from there
and uses it for DeviceCMYK color conversions.
(Doing file access from the bowels of a library is a bit weird,
especially in a system that has sandboxing built in. But LibGfx does
that in FontDatabase too already, and LibPDF uses that, so it's not a
new problem.)
This patch removes the explicit compile flag that only works for g++
(`-fdiagnostics-color=always`; clang++ needs `-fcolor-diagnostics`) and
uses CMake's built in variable that can control color output.
Now both compilers should output colored diagnostics.
This lets us fail early at configure time if a suitable Python 3
interpreter is not present, instead of delaying the error until Ninja
attempts to run `embed_as_string_view.py` to generate a header in the
middle of the build.
Refs #21791
Also explicitly specify `-mstrict-align` (The current default `-mcpu`
on gcc doesn't support unaligned accesses, so aligned memory accesses
are already implicitly required).
The `-Wcast-align` warning seems to oversensitive as it flags code like
this: https://godbolt.org/z/c8481o8aa
This used to be added for aarch64 in a473cfd71b, but was later removed
in 11896868d6.
These can be quite verbose on the command line if the packages aren't
found. As they do not break the build, let's not spam warnings.
The OpenGL package is also now skipped on macOS, where there's no point
in looking for the package anyways.
ASAN was crying way too much when running the LibJS JIT since the old
OFFSET_OF implementation was too wild for its liking.
By turning off the invalid-offsetof warnings, we can use the offsetof
builtin instead. However, I'm leaving this as a wrapper macro, since
we may still want to do something different for other compilers.
FP contraction is a standard-conforming behavior which allows the
compiler to calculate intermediate results of expressions containing
floating point numbers with a greater precision than the expression type
allows. And in theory, it enables additional optimizations, such as
replacing `a * b + c` with fma(a, b, c).
Unfortunately, it is extremely hard to predict when the contraction will
happen. For example, Clang 17 on x86_64 with the default options will
use FMA only for constant-folded non-constexpr expressions. So, in
practice, FP contraction leads to hard-to-find bugs and inconsistencies
between executables compiled with different toolchains or for different
OSes. And we had two instances of this happening last week.
Since we did not ever used -mfma on x86_64, this patch can only possibly
regress performance on Apple ARM devices, where FMA is enabled by
default. However, this regression will likely be negligible since the
difference would be one additional add instruction, which would be then
likely executed in parallel with something else.
With these changes it is now possible to create OpenGL context on macOS
and run GPU-painter. For now only QT client has a CLI param that turns
it on though.
This is a bit spammy now that we are performing some overload resolution
at build time. The fallback to an interface has generally worked fine on
the types it warns about (BufferSource, Module, etc.) so let's not warn
about it for every build.
https://cldr.unicode.org/index/downloads/cldr-44
Notable changes that affect us include:
* The Islamic Calendar is now localized as the Hijri Calender (in en-US)
but has not been updated for all locales. So this patch updates tests
where possible and removes a few test cases that currently cannot be
localized.
* The und locale has received more likely subtag data (the und locale is
basically a pseudo-locale meaning "undetermined").
* The exponential symbol in the Arabic number system was changed from
U+0627 to U+0623.
This warning warns about variable-length arrays being a non-standard
extension to the C++ language. We still have a few instances of VLAs, so
let's disable the warning for now.
This does not interfere with `-Wvla`, which we use to completely forbid
this (potentially dangerous) feature in the Kernel and LibCrypto.
A bit old but a relatively uncomplicated device capable of outputting
1920x1080 video with 32-bit color. Tested with a Voodoo 3 3000 16MB
PCI card. Resolution switching from DisplaySettings also works.
If the requested mode contains timing information, it is used directly.
Otherwise, display timing values are selected from the EDID. First the
detailed timings are checked, and then standard and established
timings for which there is a matching DMT mode. The driver does not
(yet) read the actual EDID, so the generic EDID in DisplayConnector now
includes a set of common display modes to make this work.
The driver should also be compatible with the Voodoo Banshee, 4 and 5
but I don't have these cards to test this with. The PCI IDs of these
cards are included as a commented line in case someone wants to give it
a try.
When this feature was finally merged, the serenity_option in
lagom_options.cmake had the unintended side effect of always setting the
cache variable to "" in the initial cache. In order to actually set the
linker to use to be lld or mold, we need to set with the FORCE flag in
the use_linker.cmake file.
Found by checking with the CMake variable_watch() function.
This will stop the build from spamming the "Using LLD to link Lagom"
message all over the place :^)
For now, part of this is commented-out. Our current implementations of
`<mask>` and `<symbol>` rely on creating layout nodes, so they can't be
`display: none`.
This flag makes the linker bind default-visibility functions locally, so
that calls to them do not have to go through the PLT. This makes it
impossible to override them by preloading a DSO. This was already the
case partially due to `-fno-semantic-interposition`, however that flag
is only able to optimize call sites that are in the same Translation
Unit as the function definitions.
This removes 80% of the PLT relocations in `libjs.so.serenity`.
Obsoletes #20877
