In Python 3, iteration order over the contents of a native `dict` is always unpredictable, which results in bugs like bug 1635755 where `xptdata.cpp` has irreproducible content. To avoid this, we be sure to always write out JSON in a fixed, deterministic order.
Differential Revision: https://phabricator.services.mozilla.com/D74443
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
As of bug 1621451 this argument was ignored, but it just silently runs your code with `python3` if you pass it anyway. Ensure this doesn't happen any more, and protect against any other unexpected arguments as well.
Differential Revision: https://phabricator.services.mozilla.com/D73485
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
This file is used by the searchfox indexer using python2, so maintaining
py2-compatibility is desirable if not unduly burdensome.
Differential Revision: https://phabricator.services.mozilla.com/D74224
The place where it's done right now is just unsound. It modifies
attributes during frame construction and it causes assertions to fire
with lazy frame-construction enabled.
Differential Revision: https://phabricator.services.mozilla.com/D74029
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
We currently generate absolute paths in all of our XPIDL-generated
source files, which is not so great for several reasons (deterministic
generation of files across machines, Searchfox analysis logic, shared
compilation caches, etc.). Let's generate paths that still indicate
where you should be looking, but are identical across compilations,
objdirs, etc.
Differential Revision: https://phabricator.services.mozilla.com/D73747
We currently generate absolute paths in all of our XPIDL-generated
source files, which is not so great for several reasons (deterministic
generation of files across machines, Searchfox analysis logic, shared
compilation caches, etc.). Let's generate paths that still indicate
where you should be looking, but are identical across compilations,
objdirs, etc.
Differential Revision: https://phabricator.services.mozilla.com/D73747
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
In non-DEBUG builds, `OffTheBooksCondVar::Wait` has `AUTO_PROFILER_THREAD_SLEEP`, but it's not in DEBUG builds.
`profiler_thread_sleep` does a `MOZ_ASSERT(mSleep == AWAKE)` in DEBUG builds, so the double call that happens in non-DEBUG wouldn't trigger the assertion!
This patch adds `AUTO_PROFILER_THREAD_SLEEP` in DEBUG `OffTheBooksCondVar::Wait`, to catch more misuses during development.
Depends on D72851
Differential Revision: https://phabricator.services.mozilla.com/D72852
CondVar already calls `AUTO_PROFILER_THREAD_SLEEP`, which shouldn't be called recursively.
mozilla::Monitor also uses CondVar, so it shouldn't be surrounded by `AUTO_PROFILER_THREAD_SLEEP` either.
Depends on D72850
Differential Revision: https://phabricator.services.mozilla.com/D72851
Ricky Stewart
Edgar Chen
Bas Schouten
Simon Giesecke
Valentin Gosu
Jean-Yves Avenard
Chris Fronk
Narcis Beleuzu
Mirko Brodesser
Kartikaya Gupta
Emilio Cobos Álvarez
Dorel Luca
Doug Thayer
Nathan Froyd
Bill Gianopoulos
Bob Owen
Chris Peterson
Csoregi Natalia
Ian Moody
Razvan Maries
Stephen A Pohl
Cosmin Sabou
Mihai Alexandru Michis
Mozilla Releng Treescript
Gerald Squelart