I've wanted to use this recently for a couple things. This uses the
same scheme and even templates we use for attributes, so it's mostly
moving code around...
Inverting the code generation so that the implementation is infallible,
and we actually generate the NS_IMETHOD goop inline somehow could be
potentially desirable, though that causes an extra virtual call for
non-C++ callers I guess, so maybe it's not such a great trade-off. Plus
it seems more complicated...
Explicitly forbid mixing infallible with notxpcom (as it doesn't make
sense), and similarly forbid infallible + returning void (as C++ doesn't
allow us to overload a function that differs only on its return type).
Differential Revision: https://phabricator.services.mozilla.com/D90044
This will allow resolving DOM promises with non-wrappercached XPIDL interfaces
in a more convenient manner, as the wrapped JS object will have more concrete
interface information without needing to invoke QueryInterface.
Differential Revision: https://phabricator.services.mozilla.com/D87002
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
The [[nodiscard]] attribute must precede a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute does not have this order restriction.
Differential Revision: https://phabricator.services.mozilla.com/D89092
This removes variants of "blacklist" from the xpcom directory. The preference name "network.file.path_blacklist" is left in place and will need a more thorough plan for removal. Instances of `MOZ_ASAN_BLACKLIST` remain as well and should be replaced in a larger modifcation of the `#define` in the mfbt component.
Differential Revision: https://phabricator.services.mozilla.com/D80098
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
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
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
Ply doesn't actually support python3. The generation of the files seems
to work with python3 for some reason, but running the corresponding
tests doesn't. The only version of ply that supports python3 is
currently in beta, so upgrading ply is probably not an option at the
moment.
Other commands that do use ply (mach webidl-parser-test and
ipc/ipdl/Makefile.in) have not switched to python3 (probably because
they don't work). Let's go with the simpler thing for now: switch back
to python 2 for xpidllex.py and xpidlyacc.py, which will make them
deterministically created again.
Differential Revision: https://phabricator.services.mozilla.com/D67400
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
It used to be that some XPIDL interfaces were allowed to be non-nsISupports,
and were only used to hold a bunch of constants. It appears that we've now
had enough de-COM work happen that there are no longer any, so we can remove
support for this.
Differential Revision: https://phabricator.services.mozilla.com/D61008
--HG--
extra : moz-landing-system : lando
It used to be that some XPIDL interfaces were allowed to be non-nsISupports,
and were only used to hold a bunch of constants. It appears that we've now
had enough de-COM work happen that there are no longer any, so we can remove
support for this.
Differential Revision: https://phabricator.services.mozilla.com/D61008
--HG--
extra : moz-landing-system : lando
It used to be that some XPIDL interfaces were allowed to be non-nsISupports,
and were only used to hold a bunch of constants. It appears that we've now
had enough de-COM work happen that there are no longer any, so we can remove
support for this.
Differential Revision: https://phabricator.services.mozilla.com/D61008
--HG--
extra : moz-landing-system : lando
This patch changes the xpidl parser to generate the rust trait code for
methods that take or return a cenum value.
Previously this would return an error, which means that adding a method
that uses cenums to an existing interface could cause rust code that
implements that interface to fail to build.
The generated methods take or return u8/u16/u32 depending on the width of the
enum. While this is not optimal (the parameter could contain values that are
not actually part of the enum), this is similar to what we do for nsLoadFlags.
In the future it would be nice to generate code that actually checks the
values are present in the enum, and to use a typedef instead of a plain
unsigned int.
Differential Revision: https://phabricator.services.mozilla.com/D51838
--HG--
extra : moz-landing-system : lando
This patch changes the xpidl parser to generate the rust trait code for
methods that take or return a cenum value.
Previously this would return an error, which means that adding a method
that uses cenums to an existing interface could cause rust code that
implements that interface to fail to build.
The generated methods take or return u8/u16/u32 depending on the width of the
enum. While this is not optimal (the parameter could contain values that are
not actually part of the enum), this is similar to what we do for nsLoadFlags.
In the future it would be nice to generate code that actually checks the
values are present in the enum, and to use a typedef instead of a plain
unsigned int.
Differential Revision: https://phabricator.services.mozilla.com/D51838
--HG--
extra : moz-landing-system : lando
This patch changes the xpidl parser to generate the rust trait code for
methods that take or return a cenum value.
Previously this would return an error, which means that adding a method
that uses cenums to an existing interface could cause rust code that
implements that interface to fail to build.
The generated methods take or return u8/u16/u32 depending on the width of the
enum. While this is not optimal (the parameter could contain values that are
not actually part of the enum), this is similar to what we do for nsLoadFlags.
In the future it would be nice to generate code that actually checks the
values are present in the enum, and to use a typedef instead of a plain
unsigned int.
Differential Revision: https://phabricator.services.mozilla.com/D51838
--HG--
extra : moz-landing-system : lando
