This patch adds two methods for getting/selecting tasks. The first one (get_tasks) is used to either query fzf directly, or to use interactively for user selections. The second (get_perf_tasks) makes use of the first to query for categories (through the user) and then query for the selected tasks. It also performs all the necesary intersections/unions for the queries.
These two are separated because we need a simple way to allow the user to look and select the raw tasks instead of categories if needed. This way the user can still get a comparison link at the end instead of going to `mcah try fuzzy`. See the next patches.
Depends on D160414
Differential Revision: https://phabricator.services.mozilla.com/D160415
This patch adds a method for expanding the categories. This method takes all the configuration details from the PerfParser (variants, apps, platforms, etc.) and combines them to create the categories that people will be seeing and selecting from. It creates the queries, and checks for any restrictions among them to provide selections that work. See the method for more details on all of this.
Depends on D160413
Differential Revision: https://phabricator.services.mozilla.com/D160414
This patch adds the basics for the perf selector: file, categorizations, selector configuration, and CLI arguments.
Depends on D155980
Differential Revision: https://phabricator.services.mozilla.com/D160413
This patch adds a `capture_log` flag that will allow a user to capture the logs produced when running the `push_to_try` methods. Currently, we use `subprocess.check_call` which causes hg to hang when we attempt to redirect and gather stdout. Using `subprocess.run` is better as it lets us capture the logs, but the log output is very slow and can easily lead people to believe that hg is hanging when it's not. This results in corrupted repos. Using Popen, the logs are output slower than `check_call`, but faster than `run` so you know something is happening. The speed at which these logs are printed is also why I have this log capturing behind a flag.
This functionality will be used in the `./mach try perf` selector to capture the child revisions produced for the try task config file changes and allow us to produce a PerfCompare link to provide the user.
Differential Revision: https://phabricator.services.mozilla.com/D155980
This patch implements br_on_cast_fail for wasm baseline, in a way which shares
some code with the existing br_on_cast. Main changes:
* BaseCompiler::emitBrOnCast: renamed to ::emitBrOnCastCommon, which handles
both the on-cast-success and on-cast-failure cases.
* OpIter<Policy>::checkCastedBranchValueAndPush has been removed and then
reinstated as ::readBrOnCast and ::readBrOnCastFail. Removal of this means
the validation logic and associated comments are located in only one place
rather than two.
* OpIter<Policy>::readBrOnCast and ::readBrOnCastFail: add comments to explain
the types involved, and the validation and run-time checks required. These
are then implemented.
* new test case tests/wasm/gc/br-on-cast-fail.js
Differential Revision: https://phabricator.services.mozilla.com/D158493
This revision changes the logic for creation and updating of accessibles
corresponding to img elements such that alt="" (without click listeners or any
other aria attribute that forces an accessible) will effectively remove that
img's accessible from the accessibility tree. Next, this revision removes the
concept of eNoNameOnPurpose from accessible name handling, since it's now
unnecessary now that alt="" means "don't create an accessible" in most cases.
This revision also adds tests to verify the functionality and updates existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D160706
- Do not allow preallocated processed to turn into Privileged
About Content Processes
- Separate ShouldSanitizePreference into a more logical
'ShouldSanitizePreference' to use when sending a process to
a subprocess, and a separate IsPreferenceSanitized to be used
when accessing a preference
- Remove several now-redundant parts of conditionals like
- gContentProcessPrefsAreInited (now inside IsPreferenceSanitized)
- !XRE_IsParentProcess() (now inherent in the check)
- Remove the aIsDestinationWebContentProcess argument - it's not
needed in IsPreferenceSanitized, and can be checked outside
ShouldSanitizePreference
The original (partial) preference omitting code was done for
performance, and stuck around partially in the sanitization code -
preferences explicitly blocklisted were omitted from all
sub-processes. But those preferences changed from large preferences
to privacy-sensitive ones and with this change we no longer omit
any preferences from all sub-processes, we only sanitize some
preferences for web content processes.
We could bring back this performance behavior though, and tailor
it specifically for performance and not privacy.
Differential Revision: https://phabricator.services.mozilla.com/D159940
In practice, it's only instantiated on the stack; and that's kinda important,
to reduce the likelihood that it somehow outlives the 'gfxSkipChars' instance
that it maintains a raw pointer to and is iterating over.
Differential Revision: https://phabricator.services.mozilla.com/D159922
Before this patch, we implicitly invoke the default constructor for this
member-var, and then immediately stomp on the results with a reassignment.
This patch avoids that unnecessary usage of the default constructor, saving
ourslves a bit of work and getting this member-var more directly into a
fully-initialized/valid state.
Differential Revision: https://phabricator.services.mozilla.com/D159903
Make all expiration date comparison from the same time reference, making
the comparison pedantically valid, and also avoiding repeated implicit
calls to `datetime.datetime.utcnow()`
Use `dict.setdefault` and `dict.get` to decrease the number of control path
in the code, hopefully making it easier to read.
As a bonus, this yields a modest 4% runtime improvement on my setup when
comparing the runtime of
./mach taskgraph tasks --fast --no-optimize -q -o /dev/null
Differential Revision: https://phabricator.services.mozilla.com/D160404
Avoid long lines by using appropriate temporary variables.
Use dict.pop instead of dict.get + del.
Move loop invariant outside of loops.
Differential Revision: https://phabricator.services.mozilla.com/D160467
We want to encourage extension developers to use `browser_specific_settings` instead of `applications`, which will be unsupported in Manifest Version 3+. This patch makes sure test manifests in m-c won't cause any issues in the future.
Depends on D160541
Differential Revision: https://phabricator.services.mozilla.com/D160668
RttValue used to contain parents/children for rtt.sub and this was used
for runtime casting. We have all this information in TypeDef. This commit
basically turns RttValue into a thin wrapper around a *TypeDef. It may make
sense to remove RttValue and replace it with *TypeDef eventually.
Differential Revision: https://phabricator.services.mozilla.com/D159775
This commit implements the declared subtyping from the GC proposal.
With this, in the following example:
0: (type (struct))
1: (sub 0 (type (struct (field i32))))
2: (type (struct (field i32)))
Type 1 is a sub type of type 0, while type 2 is not a sub type of type 0. They
do not canonicalize to the same type either.
A super type field is added to TypeDef which stores the declared relationship.
The subtyping algorithm is split to two phases:
1. Can types be in a subtype relationship
2. Are the types in a declared subtyping relationship
The new algorithms don't require any allocation, and so the TypeCache is
removed. The subtyping methods now have no reason to live on TypeContext
as well, so they are moved to ValType, RefType, and TypeDef.
Differential Revision: https://phabricator.services.mozilla.com/D159058
This commit adds explicit recursion groups and implements type equality using
canonicalization as specified in the GC proposal.
For the following example:
0: (struct)
(rec
1: (struct (ref 0))
2: (struct (ref 1))
)
(rec
3: (struct (ref 0))
4: (struct (ref 3))
)
Type equality is done primarily on a recursion group basis.
The first and second explicit rec's are equal, causing the types within them
to be pairwise equal.
Equality is given by the following transformation of the recs to have 'back edges'
to their local recursion group made explicit. The rest of the equality can be
done in a bottom up (inductive) manner.
(rec
1: (struct (ref nonrecursive 0))
2: (struct (ref recursive 0))
)
(rec
3: (struct (ref nonrecursive 0))
4: (struct (ref recursive 0))
)
With this example, you can see that transforming the 'local' edges to a normalized
format allows equality to done by simple comparison.
The biggest change in this commit is to how we store and create type definitions:
1. TypeDef is now stored inline in a containing RecGroup class
2. TypeContext now has a 'startRecGroup' and 'endRecGroup' method for building
rec groups.
There are several other changes required too:
1. Serialization/deserialization now operates on recursion groups, not type defs
2. (oom handling fix) Serialization/deserialization initializes refptr's at the correct type
3. Canonicalization of function types (which existed already for MVP) is now generalized to
to support canonicalization of all types.
Differential Revision: https://phabricator.services.mozilla.com/D159057
This is to fix Fluent errors being thrown because the Unified Extension panel
isn't created dynamically anymore, and is part of the DOM (in a <template>).
Differential Revision: https://phabricator.services.mozilla.com/D161081
If there's no `COMPILE_ENVIRONMENT`, generate jogfile.json during build.
It contains information about all the metrics and pings.
If we are both not MOZILLA_OFFICIAL _and_ mozilla::IsDevelopmentBuild,
we look for the jogfile on the first use of the Glean or GleanPings global.
If we find the jogfile, we load our metric and ping info from there,
making it available to JS.
JOG isn't instrumented as it only does anything when !MOZILLA_OFFICIAL,
which is exactly the condition for disabling ping upload (see rust feature
`glean_disable_upload`), so we wouldn't expect to ever hear anything.
Differential Revision: https://phabricator.services.mozilla.com/D160540
We can't test source-map package performance yet as it isn't exposed
and only loaded within a webpack bundle.
But it would be nice to also cover the code on top of the source-map package,
the "source map loader".
Differential Revision: https://phabricator.services.mozilla.com/D160199
