This adds c++-side assertions to annotated interfaces, requiring them to use a
threadsafe reference count. This ended up being quite gross due to interface
table entries making it difficult to add a `static_assert` into the code, so it
ended up being done through a constexpr constant which validates before
returning the IID.
Differential Revision: https://phabricator.services.mozilla.com/D183591
This attribute indicates that all implementations of the interface must
implement the `Sync` trait in Rust, meaning that they're safe to share between
threads. This will make storing these values in threadsafe types in Rust more
ergonomic.
To implement this, the vtable types were changed to be `&'static` references
rather than raw pointers. This should be OK as they are always valid non-null
pointers to the VTable, and avoids the need for manual `unsafe impl`s for the
relevant interfaces.
Other interfaces will remain non-send and non-sync due to the marker type.
Differential Revision: https://phabricator.services.mozilla.com/D183590
This adds c++-side assertions to annotated interfaces, requiring them to use a
threadsafe reference count. This ended up being quite gross due to interface
table entries making it difficult to add a `static_assert` into the code, so it
ended up being done through a constexpr constant which validates before
returning the IID.
Differential Revision: https://phabricator.services.mozilla.com/D183591
This attribute indicates that all implementations of the interface must
implement the `Sync` trait in Rust, meaning that they're safe to share between
threads. This will make storing these values in threadsafe types in Rust more
ergonomic.
To implement this, the vtable types were changed to be `&'static` references
rather than raw pointers. This should be OK as they are always valid non-null
pointers to the VTable, and avoids the need for manual `unsafe impl`s for the
relevant interfaces.
Other interfaces will remain non-send and non-sync due to the marker type.
Differential Revision: https://phabricator.services.mozilla.com/D183590
These are exposed as simple associated constants, similar to how they're
exposed in JS. We cannot use rust enums, as they have limited value
requirements, and `cenum` types are treated as arbitrary integers.
Differential Revision: https://phabricator.services.mozilla.com/D183587
aka one specific change in LLVM 16 introducing UB in Rust, take 3? 4?
This time, we have multiple types like:
#[xpcom(implement(nsISomething))]
struct Foo {
foo: RefCell<Something>,
}
impl Foo {
fn from_interface(obj: &nsISomething) -> &Self {
unsafe { ::std::mem::transmute(obj) }
}
}
At first glance, this looks innocuous. But the problem is that
nsISomething, as far as LLVM is informed by Rust, is readonly,
but Foo, via the RefCell, has interious mutability.
LLVM ends up assuming that any mutability that happens to that returned
&Foo can't happen, and removes it.
This is yet another case where https://github.com/rust-lang/rust/issues/111229
would save our feet from this footgun LLVM 16 added and that the rust
compiler doesn't help us prevent the least.
Differential Revision: https://phabricator.services.mozilla.com/D183569
This adds `count` out parameter for recursive file remove calls to report the number of the removed entries.
Having a lot of files removed by `::Remove(recursive=true)` has been a problem, as a slow disk can cause a hang with such call. A counter feature will help us knowing the situation better via telemetry.
The use of out parameter here is to mark it optional and prevent unwanted changes in existing callers (because a return value can't be optional).
Differential Revision: https://phabricator.services.mozilla.com/D156940
This adds `count` out parameter for recursive file remove calls to report the number of the removed entries.
Having a lot of files removed by `::Remove(recursive=true)` has been a problem, as a slow disk can cause a hang with such call. A counter feature will help us knowing the situation better via telemetry.
The use of out parameter here is to mark it optional and prevent unwanted changes in existing callers (because a return value can't be optional).
Differential Revision: https://phabricator.services.mozilla.com/D156940
Apparently the use of these is being turned into an error in Python 3.11.
Fortunately, our uses appears to be rather trivial.
For t_multilinecomment and t_LCDATA, I dropped the (?s) flag and just
replaced the one use of . with (\n|.). (?s) means DOTALL, which means
that dot includes any character, including a newline. Otherwise it means
dot includes any character except a newline.
I took the new t_singlelinecomment from IPDL's parser.py, so I assume
it is reasonable enough. t_multilinecomment is also now the same as
in IPDL.
Differential Revision: https://phabricator.services.mozilla.com/D161738
In XPIDL, the return type of AddRef and Release are nsrefcnt, which
is defined as unsigned long. The first problem is that nsrefcnt is
defined in XPIDL as unsigned long, but in C++ as uintptr_t. The second
problem is that the actual return type of these methods in C++ is
MozExternalRefCountType.
This patch fixes the return type of these methods in XPIDL. However,
due to MSCOM compatibility requirements this type is not expressible
in XPIDL, so I added it as a new builtin type to XPIDL. In C++, it
defers to the typedef and for Rust it uses u32 directly. I tried
using the new Rust typedef I defined in refptr.rs, but it seemed like
it was being used in places that didn't have refptr.rs available.
I also deleted the incorrect definition of nsrefcnt in XPIDL. It is
not used anywhere else in XPIDL files, and my previous patches removed
all uses of this type definition from Rust.
Note that this patch does not really change nsISupports.h,
because this part of the file is ignored via an #if 0. However, this
patch does clear the way for further work to start using the auto
generated nsISupports.h instead of nsISupportsBase.h.
Differential Revision: https://phabricator.services.mozilla.com/D159323
Check that iid_is refers to a parameter, is an nsIID, and has compatible
input-ness.
Make attr_param_idx in jsonxpt.py assert if the expected parameter
is missing, rather than silently ignoring the attribute.
Differential Revision: https://phabricator.services.mozilla.com/D159319
If I remembered anything from my logic programming days, I could
come up a smarter sounding word for this than "input-ness".
Differential Revision: https://phabricator.services.mozilla.com/D159318
This also changes the location from the location of the method to the
parameter which seems better.
Make the other error message use p.location, and change the error
message to say "size_is" instead of "is_size".
Differential Revision: https://phabricator.services.mozilla.com/D159317
Fix the error message for NameMap::get().
Use the location of the identifier in p_param. It was passing in
something that didn't return a valid location, causing bad error messages.
I'm guessing a new thing got added to this production rule without
adjusting the index.
Differential Revision: https://phabricator.services.mozilla.com/D159316
The [noscript] attribute does nothing on XPIDL interfaces, so make it
invalid so people don't think something might be affected if they set it.
Differential Revision: https://phabricator.services.mozilla.com/D158136
When generating code for arrays of interfaces from the rust-xpidl
compiler, the type was declared incorrectly as ThinVec<RefPtr<T>>
instead of ThinVec<Option<RefPtr<T>>> meaning that null values in the
array would be handled incorrectly.
This patch fixes this code generation mistake and updates crates using
the interface to handle null values correctly.
Differential Revision: https://phabricator.services.mozilla.com/D153485
This makes the logic for the rust type line up a bit more with the C++
logic for existing types, and adds support for 'char' and 'char16_t'
native types (for 'charPtr').
This specifically enables `nsIInputStream::Read` to be used from Rust.
Differential Revision: https://phabricator.services.mozilla.com/D152715
This makes the logic for the rust type line up a bit more with the C++
logic for existing types, and adds support for 'char' and 'char16_t'
native types (for 'charPtr').
This specifically enables `nsIInputStream::Read` to be used from Rust.
Differential Revision: https://phabricator.services.mozilla.com/D152715
We'll probably want to do something more accurate in the future with a
custom clang static analysis pass which validates that XPIDL interfaces
have the expected vtable and struct layout, however doing so would be
more involved than the string matching done in this patch.
In addition to checking for extra virtual methods, we'll likely also
want to check for data members on interfaces, and reject them unless the
class is marked as `[builtinclass]` in addition to some other attribute
which we'll need to add to prevent them from being implemented in Rust
(as c++ data members will not be reflected by the rust macro).
There were 2 instances of a comment which contained the word 'virtual'
within a CDATA block. These comments were moved out of the CDATA block
to avoid triggering the error.
Differential Revision: https://phabricator.services.mozilla.com/D151068
Before this change, all XPIDL constants were declared using an anonymous
`enum` rather than using a static constant. This change makes the
generated code more consistent with what is done in languages like Rust.
Some small changes were needed due to signed/unsigned comparison
warnings which were previously silent.
Differential Revision: https://phabricator.services.mozilla.com/D143090
Previously all xpidl constants were specified as `i64` which means they require
casts before being passed to any xpcom methods. The lack of typing was not an
issue in c++ due to implicit casts from enums to integer types, but using the
correct type is much more valuable in Rust.
Differential Revision: https://phabricator.services.mozilla.com/D135165
The constants must fit within an int32_t or uint32_t as that is required by the
JS backend with xpt types holding a `uint32_t` and signed bit.
Differential Revision: https://phabricator.services.mozilla.com/D135164
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
Joel Maher
Sylvestre Ledru
Logan Rosen
Nika Layzell
Noemi Erli
Mike Hommey
Andrew Halberstadt
Cristian Tuns
Kagami Sascha Rosylight
Iulian Moraru
Andrew McCreight
Marco Castelluccio
Butkovits Atila
Ryan VanderMeulen
Molnar Sandor
Andrey Bienkowski
Dorel Luca
nirmay
Mats Palmgren
Masatoshi Kimura