MOZ_ALWAYS_TRUE() evaluates its expression in both debug and release builds. This bug will change MOZ_ALWAYS_TRUE() to use MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT(). MOZ_ALWAYS_TRUE(NS_SUCCEEDED(rv)) would then fail in Nightly release builds (reintroducing InitStaticPrefsFromShared crash bug 1573731) if not for this changeset.
Differential Revision: https://phabricator.services.mozilla.com/D67679
--HG--
extra : moz-landing-system : lando
MOZ_ALWAYS_TRUE() evaluates its expression in both debug and release builds. This bug will change MOZ_ALWAYS_TRUE() to use MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT(). MOZ_ALWAYS_TRUE(NS_SUCCEEDED(rv)) would then fail in Nightly release builds (reintroducing InitStaticPrefsFromShared crash bug 1573731) if not for this changeset.
Differential Revision: https://phabricator.services.mozilla.com/D67679
--HG--
extra : moz-landing-system : lando
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--HG--
extra : moz-landing-system : lando
This speeds up startup by 140ms on a Moto G5 Android device because it avoids almost 3 million calls to CallbackNode::Matches.
The patch contains the following changes:
- InitAlwaysPref no longer calls AddMirrorCallback.
- InitAlwaysPref loses its aIsParent and aIsStartup arguments and is now only called in the parent.
- InitAll is now only called in the parent, and doesn't care if it's called for startup.
- There's a new function, `StaticPrefs::StartObservingAlwaysPrefs()` which gets called after all prefs have been loaded on startup.
- The new function calls AddMirror rather than AddMirrorCallback so that any pref values from the data files get picked up into the mirrors.
- AddMirror requires a fallback argument. I used the current value of the mirror as the fallback value.
Differential Revision: https://phabricator.services.mozilla.com/D66142
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
Explicit initialization of these static pointers appears to resolve these intermittent failures.
Differential Revision: https://phabricator.services.mozilla.com/D53842
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
Because it's violated when updates occur, and when the violation occurs it's
safe to continue, for reasons explained in the patch. This should fix a top
crash.
Differential Revision: https://phabricator.services.mozilla.com/D44102
--HG--
extra : moz-landing-system : lando
Because `InitAlwaysPref` is an internal function, we can reasonably take
`const nsCString&` parameters, which avoids having to needlessly flatten
the already-flattened literal strings being passed to `InitAlwaysPref`.
Differential Revision: https://phabricator.services.mozilla.com/D42836
--HG--
extra : moz-landing-system : lando
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
