A `CacheData` object holds two things: a VarCache/mirror variable address, and
a default value. The previous patch removed the use of the default value.
Therefore, `CacheData` now only holds an address, so there's no need for a
distinct heap object for it, and we can eliminate `CacheData` entirely and just
use the mirror variable address (a `void*`) directly.
The removal of the `CacheData` objects removes one reason for `gCacheData` to
exist (which is to have an owner for those objects). The other reason is to
detect if two or more prefs get VarCached onto a single variable. But given
that VarCaches are on the way out in favour of static prefs (bug 1448219) this
checking is no longer important. So the commit removes `gCacheData` as well.
The above changes save 20-32 KiB per process on 64-bit platforms.
The patch also removes `gCacheDataDesc`, a diagnostic thing from bug 1276488
that isn't relevant with `gCacheData` removed. This means the return type of
`InitInitialObjects` can be simplified.
Finally, the commit renames a few things, taking another step along the path of
renaming VarCache prefs as mirrored prefs, a much better name.
Differential Revision: https://phabricator.services.mozilla.com/D40906
--HG--
extra : moz-landing-system : lando
This patch changes how a VarCache pref works when deleted (in some cases) --
the VarCache variable keeps its existing value instead of being reset to a
pre-specified default.
In bug 1570212 I have made sure that no VarCache prefs exhibit this behaviour
in practice any more, so this change should not affect functionality. There is
an assertion that checks this.
The next patch will take advantage of this change by removing the need to
store the pre-specified defaults, which will save memory.
Differential Revision: https://phabricator.services.mozilla.com/D39805
--HG--
extra : moz-landing-system : lando
Another step in the renaming of VarCache variables as mirror variables,
matching the 'mirror' field used in StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D40794
--HG--
extra : moz-landing-system : lando
Avoiding lots of `if (isParent)` conditions reduces code size by 2016 bytes for
a local build on my Linux64 box.
Differential Revision: https://phabricator.services.mozilla.com/D40921
--HG--
extra : moz-landing-system : lando
This patch introduces a new Rust crate called `static_prefs`.
It also changes generate_static_pref_list.py to generate two new files.
- StaticPrefsCGetters.cpp: contains C getters, which are just wrappers around
the C++ getters. This is included into Preferences.cpp.
- static_prefs.rs: contains declarations for the C getters, plus the `pref!`
macro which provides nice syntax for calling the C getters. This is included
into static_prefs/src/lib.rs.
The new code is only generated for prefs marked with the new `rust` field in
the YAML. It's opt-in because there's no point generating additional code for
900+ static prefs when only about 20 are currently used from Rust.
This patch only marks a single pref (`browser.display.document_color_use`) with
`rust: true`. That pref isn't accessed from Rust code in this patch, but it's
necessary because the generated Rust code is invalid if there are zero
Rust-accessed prefs. (The next patch will access that pref and others from Rust
code.
Differential Revision: https://phabricator.services.mozilla.com/D40791
--HG--
extra : moz-landing-system : lando
This commit removes `MirrorKind` by splitting the `VARCACHE_PREF` macros in
two, giving `ALWAYS_PREF` and `ONCE_PREF` macros. This is good because most of
the time the generated code is quite different for the two cases.
The commit also removes the examples of code produced by the macros in
comments. These are kind of useful, but also quite verbose and a pain to
maintain.
Differential Revision: https://phabricator.services.mozilla.com/D40166
--HG--
extra : moz-landing-system : lando
This commit:
- improves the wording of some comments;
- renames `UpdatePolicy` as `MirrorKind`, to reflect the new terminology we are
starting to use;
- does a couple of other minor clean-ups.
Differential Revision: https://phabricator.services.mozilla.com/D40161
--HG--
extra : moz-landing-system : lando
They're infallible in practice and always `NS_OK`. (This stems from
`AddVarCacheNoAssignment()` always returning `NS_OK`.)
As a result, the commit removes lots of unnecessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D39804
--HG--
extra : moz-landing-system : lando
It's an annoyingly long name that causes lots of line breaking, and it's not
exposed outside of libpref.
Differential Revision: https://phabricator.services.mozilla.com/D39803
--HG--
extra : moz-landing-system : lando
This makes it clear that these run when prefs are initialized (like
`InitVarCache()`) rather than being vanilla `set` calls that happen at any
point during runtime.
Differential Revision: https://phabricator.services.mozilla.com/D39650
--HG--
extra : moz-landing-system : lando
Lots of operations in Preferences.cpp can only occur in the parent process
and/or on the main thread. It has a bunch of assertions to enforce/document
this. This commit adds some more, because they're really useful for
understanding the code.
The commit also removes an unnecessary `XRE_IsParentProcess()` check in
`pref_SetPref()` (because that condition is always true, as the added assertion
indicates), and renames a parameter in `InitVarCachePrefs()`.
Differential Revision: https://phabricator.services.mozilla.com/D39649
--HG--
extra : moz-landing-system : lando
`AddVarCache()` has a `bool aSkipAssignment` parameter. This patch removes that
parameter by splitting the function in two: `AddVarCache()` and
`AddVarCacheNoAssignment()`. (The former calls the latter.)
There are also tons of `Add*VarCache()` functions with `aSkipAssignment`
parameters that default to `false`. These defaults are never overridden, so
this patch removes the unnecessary arguments.
Differential Revision: https://phabricator.services.mozilla.com/D39433
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
These files exist because they were the proof-of-concept first step for
splitting the static prefs header files. Now that those header files can be
generated from a script, we need to move the `accessibility.*` prefs into the
YAML file.
Differential Revision: https://phabricator.services.mozilla.com/D39132
--HG--
extra : moz-landing-system : lando
There was a missing setter function for this combination, which hasn't been
used before.
Differential Revision: https://phabricator.services.mozilla.com/D39263
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
This implements the machinery for the splitting of static prefs headers, and
uses it for a single header. #includes are used in such a way that the amount
of boilerplate for each static prefs header file is minimal.
Future patches will split the remaining prefs into more header files.
Differential Revision: https://phabricator.services.mozilla.com/D36154
--HG--
rename : modules/libpref/StaticPrefs.h => modules/libpref/StaticPrefsBase.h
rename : modules/libpref/StaticPrefs.h => modules/libpref/init/StaticPrefListBegin.h
extra : moz-landing-system : lando
Now that all static pref getters use snake_case, these renamings make sense:
- Getfoo_bar_bazPrefName() -> GetPrefName_foo_bar_baz()
- Getfoo_bar_bazPrefDefault() -> GetPrefDefault_foo_bar_baz()
Differential Revision: https://phabricator.services.mozilla.com/D36563
--HG--
extra : moz-landing-system : lando
This doesn't change the way C++ code uses static prefs. But it does slightly
change how Rust code uses static prefs, specifically the name generated by
bindgen is slightly different.
The commit also improves some comments.
Differential Revision: https://phabricator.services.mozilla.com/D35764
--HG--
extra : rebase_source : 13cf215aeb713e188103ef0cd04d094aa150853e
Static VarCache prefs have setters. These are dangerous because they can
violate the primary invariant of VarCache prefs, which is that the global
variable always matches the pref value in the table.
Fortunately they are only used in tests, and we can use vanilla pref setters
instead, and get rid of the VarCache setters.
Differential Revision: https://phabricator.services.mozilla.com/D35632
--HG--
extra : moz-landing-system : lando
We can initialize the StaticPrefs as soon as the SharedMap object is created outside the parent process.
Additionally when resetting the preferences to their default values, we no longer modify the `Once` StaticPrefs as they are immutable, only the underlying preference.
Differential Revision: https://phabricator.services.mozilla.com/D35263
--HG--
extra : moz-landing-system : lando
When testing, the Preference behing a `Once` StaticPrefs should never get modified as this indicate that this StaticPrefs should have a `Live` policy instead.
This is placed behind the preferences.check.once.policy which will get enabled during automated testing.
Differential Revision: https://phabricator.services.mozilla.com/D34107
--HG--
extra : moz-landing-system : lando
Rather than attempting to determine when the Once policy StaticPrefs should be set we initialize them when one of the getter gets called. They become immutable after that.
In a future change we will prevent those values to ever be changed once they have been initialized.
Differential Revision: https://phabricator.services.mozilla.com/D33440
--HG--
extra : moz-landing-system : lando
When we create the SharedPreferenceMap we store the value of the Once pref in it. All child processes will now read the Once pref from the read-only SharedPreferenceMap.
This makes the Once prefs immutable once we start the first child process.
Differential Revision: https://phabricator.services.mozilla.com/D33421
--HG--
extra : moz-landing-system : lando
This allows for an entry to not show in about:config.
This will be used to store Once StaticPrefs once they become immutable.
Differential Revision: https://phabricator.services.mozilla.com/D33420
--HG--
extra : moz-landing-system : lando
And set the underlying preference. StaticPrefs::Set becomes a convenience access to the original preference which is what gfxPrefs was actually doing.
Differential Revision: https://phabricator.services.mozilla.com/D31749
--HG--
extra : moz-landing-system : lando
And set the underlying preference. StaticPrefs::Set becomes a convenience access to the original preference which is what gfxPrefs was actually doing.
Differential Revision: https://phabricator.services.mozilla.com/D31749
--HG--
extra : moz-landing-system : lando
