XPIDL has the requirement that [scriptable] interfaces with [notxpcom]
methods or attributes are [builtinclass]. Currently, if you don't
explicitly mark something builtinclass when it should be, then the
XPIDL compiler will just silently treat it like builtinclass. This
means that you can cause the JS implementation of an XPCOM to start
failing without any warning by marking a method notxpcom.
This patch instead makes it an error. A prior patch fixed the existing
instances in the tree that relied on the implicit behavior.
I also added a test that we reject such classes missing builtinclass
at compile time, as well as classes that inherit from builtinclass
interfaces without themselves being builtinclass. I left behind a part
of the runtime test for this behavior, but now this test just ensures
that you can't implement a [builtinclass] interface in JS.
Differential Revision: https://phabricator.services.mozilla.com/D30984
--HG--
extra : moz-landing-system : lando
We never emit an XPT for an interface that is not scriptable, so this
flag is never used.
Differential Revision: https://phabricator.services.mozilla.com/D30529
--HG--
extra : moz-landing-system : lando
Before the Array<T> type, the calltype argument could be in, out, or inout,
however with Array<T> the element type was added.
When I added Array<T>, I changed the checks in files which check calltype !=
'in' to instead check 'out' in calltype, such that element would act more like
in in most cases (not adding the outparam *).
However, I never made that change for rust code, as it didn't support Array<T>
at the time. When I turned on Array<T> support for rust code, I forgot to go
through and change the conditions, which lead to this bug.
Differential Revision: https://phabricator.services.mozilla.com/D24283
--HG--
extra : moz-landing-system : lando
Currently the [ref] and [ptr] types share the same underlying
implementation. This is unfortunate, and can cause correctness problems
with outparam refs (as an example).
By using the same tools used to allow other larger objects (such as
jsid, nsTArray, and nsString) to be stored directly in the nsXPTCVariant
object, this patch directly stores the nsID in the nsXPTCVariant object
when calling from JS into C++.
Using this new strategy avoids an nsID* allocation every time we pass
one over XPConnect, and should also allow us to simplify callers.
In addition, some special casing is added to xpidl to make it possible
to use the nsid reference type objects directly inside of Array<T>,
which will allow us to remove `[array] nsIIDPtr` callers.
Differential Revision: https://phabricator.services.mozilla.com/D19175
--HG--
extra : moz-landing-system : lando
They're just integers, so there's no reason they need to be fallible
since they're basically a built-in anyways.
Differential Revision: https://phabricator.services.mozilla.com/D11363
--HG--
extra : moz-landing-system : lando
Add CEnum types to XPIDL, allowing for typed enums in C++ instead of
using uintXX_t types. Javascript will still reflect CEnums as
interface level consts.
Depends on D8593
Differential Revision: https://phabricator.services.mozilla.com/D8594
--HG--
extra : moz-landing-system : lando
After bug 1496622, the IDL parser converts some references to `nsresult` in IDL files to `::nserror::nsresult` in IDL-generated Rust files. But it doesn't convert others. It should convert them all consistently, and this patch makes it do so by adding conversion of the return type of attribute getters/setters and references generated by the IDL parser's Typedef class.
MozReview-Commit-ID: 838K8XGjvTx
Differential Revision: https://phabricator.services.mozilla.com/D10121
--HG--
extra : moz-landing-system : lando
These properties were added in bug 478251 back when XPIDL was sort of emulating
WebIDL. They are not needed any more, and none of our XPIDL files use them.
--HG--
extra : rebase_source : f2f2c54ae787ad90704074eb114f00c3741d5f88
This patch allows us to define methods or getters/setters for any of the
current set of well-known symbols. Those are defined by adding the [symbol]
attribute to a method:
[symbol]
Iterator iterator();
which causes the method to define a property with the well-known symbol which
matches its method name (Symbol.iterator, in this case).
Due to the implementation details of the XPIDL parser, this currently does not
support defining a non-symbol function with the same name as a symbol
function:
[symbol]
Iterator iterator();
[binaryname(OtherIterator)]
Thing iterator(in nsIDRef aIID);
throws for a duplicate method name, even though there is no actual conflict.
Differential Revision: https://phabricator.services.mozilla.com/D3724
--HG--
extra : rebase_source : 1385e2da93113306730f7c087fe7385dbe668e91
extra : histedit_source : 3afd9fe38e7cbddc5576c2bd1673496dd623e489
Summary:
This more closely matches the C++ names, and reflects the fact that the
reflected type is not WebIDL's mozilla::dom::Sequence. The reasoning behind this
type difference is for ergonomics, due to xpidl only being exposed to internal
JS code.
Depends On D2335
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2337
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
Summary:
This means that using these types involves many fewer footguns, while not
requiring any changes to the actual XPConnect implementation!
Depends on D2111
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2334
Summary:
This patch adds support for the `Sequence<T>` type. This is largely a
straightforward type propagation patch, but there are a few notable things:
1. We allow `[iid_is(x)] Sequence<nsQIResult>`, so Sequence can be Dependent.
2. `Sequence<T>` is reflected into C++ as a `nsTArray<T>`, which is different
than WebIDL's `mozilla::dom::Sequence<T>` type. This decision was made for
general ergonomics reasons, as `nsTArray<T>` is more prevailent throughout
the codebase, and lengths in this case cannot be controlled by content, as
XPConnect is only exposed to Chrome JS.
3. Owned pointers in `Sequence<T>` are not reflected as their owned
counterparts. For example, `Sequence<nsISupports>` is reflected as
`nsTArray<nsISupports*>` rather than `nsTArray<RefPtr<nsISupports>>`. This
was done to avoid depending on `RefPtr<T>` and `T*` having the same
in-memory representation, however if that is considered an acceptable
dependency, it would be nice to support that.
4. We also don't reflect singly-owned pointers as their owned counterparts. For
example, `nsTArray<nsIIDPtr>` would be reflected as `nsTArray<nsIID*>`
rather than `nsTArray<mozilla::UniquePtr<nsIID>>`. If we are willing to
depend on `mozilla::UniquePtr<T>`'s in-memory representation, we could also
do this, however.
5. There are no restrictions on what types can appear inside of a `Sequence<T>`
or what can appear inside an `[array] T`. We may want to add restrictions
either at the xpidl level or in XPConnect.
Depends On D2109
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2110
Summary:
This patch allows parsing generic types, such as Sequence<T>, in XPIDL. It does
this by introducing a new type, TypeId, which contains both the name string and
an optional list of generic parameters.
Various places which use the xpidl.py library had to be updated to construct one
of these TypeId objects, as TypeId and `str` are not compatible types.
Depends On D2106
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2109
Summary:
This more closely matches the C++ names, and reflects the fact that the
reflected type is not WebIDL's mozilla::dom::Sequence. The reasoning behind this
type difference is for ergonomics, due to xpidl only being exposed to internal
JS code.
Depends On D2335
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2337
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
Summary:
This means that using these types involves many fewer footguns, while not
requiring any changes to the actual XPConnect implementation!
Depends on D2111
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2334
Summary:
This patch adds support for the `Sequence<T>` type. This is largely a
straightforward type propagation patch, but there are a few notable things:
1. We allow `[iid_is(x)] Sequence<nsQIResult>`, so Sequence can be Dependent.
2. `Sequence<T>` is reflected into C++ as a `nsTArray<T>`, which is different
than WebIDL's `mozilla::dom::Sequence<T>` type. This decision was made for
general ergonomics reasons, as `nsTArray<T>` is more prevailent throughout
the codebase, and lengths in this case cannot be controlled by content, as
XPConnect is only exposed to Chrome JS.
3. Owned pointers in `Sequence<T>` are not reflected as their owned
counterparts. For example, `Sequence<nsISupports>` is reflected as
`nsTArray<nsISupports*>` rather than `nsTArray<RefPtr<nsISupports>>`. This
was done to avoid depending on `RefPtr<T>` and `T*` having the same
in-memory representation, however if that is considered an acceptable
dependency, it would be nice to support that.
4. We also don't reflect singly-owned pointers as their owned counterparts. For
example, `nsTArray<nsIIDPtr>` would be reflected as `nsTArray<nsIID*>`
rather than `nsTArray<mozilla::UniquePtr<nsIID>>`. If we are willing to
depend on `mozilla::UniquePtr<T>`'s in-memory representation, we could also
do this, however.
5. There are no restrictions on what types can appear inside of a `Sequence<T>`
or what can appear inside an `[array] T`. We may want to add restrictions
either at the xpidl level or in XPConnect.
Depends On D2109
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2110
Summary:
This patch allows parsing generic types, such as Sequence<T>, in XPIDL. It does
this by introducing a new type, TypeId, which contains both the name string and
an optional list of generic parameters.
Various places which use the xpidl.py library had to be updated to construct one
of these TypeId objects, as TypeId and `str` are not compatible types.
Depends On D2106
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2109
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
This type is fairly simple on the idl parsing side of things. I handle it in the
same way that special types such as ns[C]String, nsid, and jsval are handled, by
using a special native type.
The logic for converting the value between C++ and JS follows the existing logic
from the nsISupports <=> JS Promise conversions.
They are parsed into a WebIDL object, and lowered into C++, Rust, and XPT.
For C++ code, we generate a correctly namespaced forward declaration. In Rust,
the types are exposed as `*const c_void`, as we don't have WebIDL type
information there.
The XPT code generator needs to know the header filename in order to perform
correct codegen, so we also get that information.
This patch contains the meat of the changes here. The following summarize the changes:
1. xptinfo.h is rewritten to expose the new interface for reading the XPT data,
The nsXPTInterfaceInfo object exposes methods with the same signatures as
the methods on nsIInterfaceInfo, to make converting code which used
nsIInterfaceInfo as easy as possible, even when those methods don't have
signatures which make a ton of sense anymore. There are also a few methods
which are unnecessary (they return `true` or similar), which should be
removed over time.
Members of the data structures are made private in order to prevent reading
them directly. Code should instead call the getter methods. This should make
it easier to change their memory representation in the future. Constructing
these structs is made possible by making the structs `friend class` with the
XPTConstruct class, which is implemented by the code generator, and is able
to access the private fields.
In addition, rather than using integers with flag constants, I opted for
using C++ bitfields to store individual flags, as I found it made it easier
to both write the code generator, and reason about the layouts of the types.
I was able to shave a byte off of each nsXPTParamInfo (4 bytes -> 3 bytes)
by shoving the flags into spare bits in the nsXPTType. Unfortunately there
was not enough room for the retval flag. Fortunately, we already depend in
our code on the retval parameter being the last parameter, so I worked
around this by removing the retval flag and instead having a `hasretval`
flag on the method itself.
2. An xptinfo.cpp file is added for out-of-line definitions of more complex
methods, and the internal implementation details of the perfect hash.
Notable is the handling of xptshim interfaces. As the type is uniform, a
flag is checked when trying to read constant information, and a different
table with pointers into webidl data structures is checked when the type is
determined to be a shim.
Ideally we could remove this once we remove the remaining consumers of the
existing shim interfaces.
3. A python code generator which takes in the json XPT files generated in the
previous part, and emits a xptdata.cpp file with the data structures. I did
my best to heavily comment the code.
This code uses the friend class trick to construct the private fields of the
structs, and avoid a dependency on the ordering of fields in xptinfo.h.
The sInterfaces array's order is determined by a generated perfect hash
which is also written into the binary. This should allow for fast lookups by
IID or name of interfaces in memory. The hash function used for the perfect
hash is a simple FNV hash, as they're pretty fast.
For perfect hashing of names, another table is created which contains
indexes into the sInterfaces table. Lookup by name is less common, and this
form of lookup should still be very fast.
4. The necessary Makefiles are updated to use the new code generator, and
generate the file correctly.
