Meta/Lagom/ReadMe.md never had any other name; not sure how that typo
happened.
The link to the non-existent directory is especially vexing because the
text goes on to explain that we don't want such a directory to exist.
Found by running markdown-checker, and 'wget'ing all external links.
I can't write these manpages ad-hoc, and in most cases I don't want to
remove the link because it is justified. The hope is that with this
FIXME in place, there is more motivation to write these manpages for
someone who knows enough about them. Or at least we will introduce fewer
dead links in the future, making Help more useful.
Chroot exists neither in code nor in documentation. If we add-in the
feature again, it will be simple enough to add it back in to the
documentation. For now, let's clean it up, instead of refering to things
that don't exist.
Found by markdown-checker.
The list-format strings used for Intl.ListFormat are small, but quite
heavily duplicated. For example, the string "{0}, {1}" appears 6,519
times. Generate unique strings for this data to avoid duplication.
In the generated UnicodeLocale.cpp file, there are 296,408 strings for
localizations of languages, territories, scripts, currencies & keywords.
Of these, only 43,848 (14.8%) are actually unique, so there are quite a
large number of duplicated strings.
This generates a single compile-time array to store these strings. The
arrays for the localizations now store an index into this single array
rather than duplicating any strings.
Some CLDR languages.json / territories.json files contain localizations
for some lanuages/territories that are otherwise not present in the CLDR
database. We already don't generate anything in UnicodeLocale.cpp for
these anomalies, but this will stop us from even storing that data in
the generator's memory.
This doesn't affect the output of the generator, but will have an effect
after an upcoming commit to unique-ify all of the strings in the CLDR.
This used to generate a warning about using a deprecated copy-assign,
default-generated by the compiler, and deprecated because we hand-
implement the copy-constructor. This warning is correct, since the
default-generated copy-assign may or may not be as efficient as memcpy.
This patch gets rid of the warning, and has either no performance impact
or a slightly positive one. If this turns out to be wrong, we should
probably also fix the copy-constructor.
There are only 112 code points with special casing rules, so this array
is quite small (compared to the size 34,626 UnicodeData hash map that is
also storing this data). Removing all casing rules from UnicodeData will
happen in a subsequent commit.
Currently, all casing information (simple and special) are stored in a
compile-time array of size 34,626, then statically copied to a hash map
at runtime. In an effort to reduce the resulting memory usage, store the
simple casing rules in standalone compile-time arrays. The uppercase map
is size 1,450 and the lowercase map is size 1,433. Any code point not in
a map will implicitly have an identity mapping.
A types which have special functions declared with "= default can be
trivially copied. Besides being good practice, the compiler might be
able generate copy and initialize code in a more optimized way.
Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v832/
We can reduce the amount of padding the compiler adds in order to
ensure data alignment of member variables by ordering the types in
a struct by size in decending order.
Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v802/
We can reduce the amount of padding the compiler adds in order to
ensure data alignment of member variables by ordering the types in
a struct by size in decending order.
Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v802/
When the member is initialized in the constructor body, but also has a
default constructor, you pay for default construction to just throw it
away. In this case a StringView is light weight to initialize, but we
might as well fix all cases we find.
Found by PVS-Studio: https://pvs-studio.com/en/docs/warnings/v818/
Since there's no global API for being able to just assign a callback
function to config changes, I've made an inline struct in desktop
mode with the sole purpose of checking to see if the Wallpaper
entry has changed, and then updates GUI::Desktop.
It's pretty neat seeing the wallpaper change as soon as you edit the
config file :^)
If we don't quit, the underlying socket won't get a chance to do much
other than nothing while we spin in read_while_data_available().
Fixes some possible RS spin (especially seen in Google's cookie consent
page).
Prior this patch, you couldn't remove any files from the context menu
if you didn't have write access to them.
It was incorrect, as the write permission for files means that you can
modify the contents of the file, where for directories it means that
you can create, rename, and remove the files there.
