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
The license used to be LGPL so the code lived in other-licenses, but it was changed to BSD eleven years ago. Let's move it over to third_party/python/ply where it belongs.
./mach vendor python ply==3.10
`diff -r` between the original `ply` directory and the new one only comes up with the new file `third_party/python/ply/CHANGES` which isn't relevant to the functionality of the code, so this should be a no-op all told.
Differential Revision: https://phabricator.services.mozilla.com/D73341
With LazyFC in the parent process enabled, we can get here more easily
without frames for the <browser> element.
This causes some assertion failures because we start parenting the
remote browsers to the wrong layer manager when inside a popup.
If we get to nsFrameLoader::TryRemoteBrowser without a frame,
GetLayerManager (which uses GetWidgetForContent) will just fall back to
GetWidgetForDocument. Badness ensues if the widget should actually not
be that one.
Make sure to flush frames when we load an event, so that we can
initialize stuff properly.
We could try to only flush if inside a popup or something, but this code
is a bit tricky so if possible I'd prefer not to diverge.
Differential Revision: https://phabricator.services.mozilla.com/D74177
Add a FunctionBox::emitLazy flag to identify boxes which should allocate a
lazy script. This also is used to avoid allocating JSFunctions for funboxes
that are the result of a failed syntax parse.
Differential Revision: https://phabricator.services.mozilla.com/D74156
Add a plain base class to hold the ScriptStencil data members. This
non-virtual type will later be used to replace FunctionCreationData. In the
long run we will remove the virtual methods entirely.
Differential Revision: https://phabricator.services.mozilla.com/D74155
`network.preload` is off by default and there for not representative of a user of Firefox. By removing that user preference we are more in line
Differential Revision: https://phabricator.services.mozilla.com/D71774
We do this to avoid unnecessarily penalizing subprocess invocations from
within mach (and all child processes) on some Linux setups.
Differential Revision: https://phabricator.services.mozilla.com/D66786
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
Make the WebAssembly baseline compiler address incoming stack arguments from the frame pointer instead of from the stack pointer.
We have a plan to allow interstitial trampoline frames to be inserted between callers and callees, but only for cross-instance calls. This will mean offset to incoming stack arguments from SP is no longer a constant. The design has us instead address stack arguments from the frame pointer, as adding an interstitial trampoline frame won't modify the frame pointer.
The followup patch will do the same for the Ion compiler.
Differential Revision: https://phabricator.services.mozilla.com/D72298
Chris H-C
Dorel Luca
Vlad Filippov
Ricky Stewart
Mirko Brodesser
Kershaw Chang
Tom Prince
ffxbld
Emilio Cobos Álvarez
Ted Campbell
James Graham
Zhao Jiazhong
Kristján Oddsson
Alex Chronopoulos
Kartikaya Gupta
Nathan Froyd
Matthew Gaudet
Jan de Mooij
Simon Giesecke
Mark Banner
Ryan Kelly
Nicolas Silva
Christoph Kerschbaumer
Dmitry Bezhetskov
Joel Maher