AsmJS will emit a call site line number for call, call indirect, and math builtins.
We currently read from the call site line number array for more operations than
these. This is normally fine, as long as the operations that try the read are
never emitted from AsmJS. If that is not the case, we will get out of sync and
can read outside of the array. This caused an issue when I added a use of
readCallSiteOrBytecode() in TeeGlobal, copying from SetGlobal. This commit
fixes this.
Differential Revision: https://phabricator.services.mozilla.com/D141030
Ion has an easier time switching to the precise post-write barrier
as it's already unconditionally doing a call (postBarrierFiltering),
and so there's little extra cost in switching that call to be the
precise post-write barrier everywhere.
We cannot remove the postBarrierFiltering builtin because it is
still used by cranelift.
Differential Revision: https://phabricator.services.mozilla.com/D141029
Add a post-write barrier which will remove a previous store buffer entry if the
new value stored in the field would not require it. This requires the previous
value to be loaded before the store and propagated to the post-write barrier
call.
We only require a precise post-write barrier for storing into tables, as they
are implemented using a GCVector<HeapPtr<..>> which requires the invariant
that each write of null/tenured when the previous value was nursery will
remove the existing store buffer entry.
Differential Revision: https://phabricator.services.mozilla.com/D141027
The barriered store function emits the post-write barrier directly, but calls
out to a function for the pre-write barrier. We should factor the post-write
barrier out so that we can use a different post-write barrier implementation
depending on requirements more easily.
Differential Revision: https://phabricator.services.mozilla.com/D141026
Add test for issue with a post-write barrier that doesn't remove
store buffer entries when used on a table that may grow.
Differential Revision: https://phabricator.services.mozilla.com/D141025
* Rename global.inc.css global-shared.css and @import it from the desktop-platform-specific global.css stylesheets
* Move all the global.css / global.inc.css %includes to @imports
* Move the rules from notification-popup.inc.css into popupnotification.css
* Remove preprocessor indicators from the manifest entries for CSS
Depends on D141547
Differential Revision: https://phabricator.services.mozilla.com/D140276
* Bug 1754271 Moved these rules to the shared alert.css, and removed the manifest entry but neglected to actually rm the file
Depends on D140907
Differential Revision: https://phabricator.services.mozilla.com/D141546
As part of our migration to cloud-hosted Sentry, it looks like our
authentication value is now an "auth token" instead of an "API key".
Update the environment variable name accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D141967
At this point, no code in mozilla-central references these.
In comms-central, the string is still used, but provided there
by local brand.properties and brand.dtd files.
Depends on D141860
Differential Revision: https://phabricator.services.mozilla.com/D141861
The dataReportingNotification is the last place where the .properties
vendorShortName is used. As notifications already support Fluent,
porting this to use Fluent as well seems pretty strqaightforward.
Differential Revision: https://phabricator.services.mozilla.com/D141860
The Mach site is asserted to be compatible with all command sites, but
command sites are deliberately //not// asserted to be compatible with
each other - they're //supposed// to have the flexibility of being
able to be incompatible.
Accordingly, let's fail loudly if code tries to activate from one
command site to another.
Note that, due to the Mach site being a superset of common, it's safe to
activate from "common" to "<other command site>". This is needed for
cases like `./mach python --virtualenv ...`.
This required updating the `mozproxy` tests, who would deliberately
activate the `common` site so they could call a `mozproxy` entry point
script. These tests were fixed by instead invoking `mozproxy` as a
module (`-m`) of the current `python-test` site.
Differential Revision: https://phabricator.services.mozilla.com/D141659
This is needed for a few reasons:
* All mach commands can use virtualenvs, not just `build`-related
commands, so the files don't make sense to be in `build/`.
* When locking is added, more files associated with virtualenvs will be
added, and this will change will ease the related directory structure
setup.
* This removes the need for a redundant "_virtualenv_packages" keyword
as part of the manifest filenames.
Differential Revision: https://phabricator.services.mozilla.com/D140382
The intention is to remove all the files in the vendoring directory
(which may be the yaml directory or may not be) except those
specified in 'keep'.
However convert_patterns_to_paths expects a list of patterns, and
we were providing it with only one. This resulted in it iterating
over '**' as a string (one iteration for '*' and a second for '*')
This prevented it from traversing recursively. Turning it into a
list fixes it.
Depends on D141901
Differential Revision: https://phabricator.services.mozilla.com/D141902
This creates a way to override the 'tracking: tag' mechnaism
of a moz.yaml file without having to edit it. Useful to
test a library update when there is no new tag available.
Differential Revision: https://phabricator.services.mozilla.com/D141901
Because right now we only have hardware concurrency wired
up to the fine-grained RFP checks this is a copy of the
regular RFP test but with the hardware concurrency field
set to the non-spoofed value
Depends on D141772
Differential Revision: https://phabricator.services.mozilla.com/D141773