The remaining uses of XPIDL's definition of nsrefcnt in Rust are all
now related to the return type of nsISupport's AddRef and Release
methods. The C++ name of the return types is MozExternalRefCountType,
not nsrefcnt (which is something else entirely), so use a more accurate
name.
I can't use the C++ definition, because it is in C++, and I eventually
want to remove the XPIDL definition, because it isn't accurate for C++,
so in this patch I'll make a specific one for Rust, so the code is a
little easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D159322
The type of the refcount argument to these functions is the C++ type
nsrefcnt, which is actually uintptr_t. This is different from the
definition of nsrefcnt in XPIDL which is currently being used. These
functions are not actually defined in XPIDL, and also uintptr_t
can't be expressed in XPIDL, so let's just change it to the type it
really is in Rust, usize. The goal of the patch is to eliminate
some uses of nsrefcnt from Rust.
Differential Revision: https://phabricator.services.mozilla.com/D159321
This matches the implementation of refcounting in C++ XPCOM objects.
We'll end up crashing if the refcount being returned is too large.
Change inc() and dec() to use try_into instead of as. This will change
the behavior because we'll crash if the value is too large instead of
silently truncating the return value, which might be worse because few
callers actually use the return value, but is unlikely to matter.
Also, use a more precise return type for the get() methods. It is only
used by Rust code, so there's no need to be compatible with
nsISupports. I made that change here to avoid needing to add a coercion
from usize to nsrefcnt.
Part of my goal with this patch is to eliminate an unnecessary use of
nsrefcnt from Rust.
Differential Revision: https://phabricator.services.mozilla.com/D159124
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
I also took the opportunity to mark nsIComponentManager as builtinclass,
and I marked the two methods I changed as noscript because clearly they
aren't being called by JS, so it seems like it should be avoided.
I also fixed some clang-tidy issues.
Based on a patch by froydnj.
Differential Revision: https://phabricator.services.mozilla.com/D145250
This patch contains changes to moz_task to improve it's support for
async execution on multiple threads. Unlike the previous executor
implementation, this new implementation reduces the amount of unsafe
code substantially by depending on the async-task crate
(https://crates.io/crates/async-task) for the core task implementation.
This adds a few additional features:
* Both local (no Send bound) and non-local (with Send bound) execution support,
* Support for spawning on arbitrary nsIEventTargets or the background task pool,
* Returned Task objects from runnables which may be .await-ed on or detach()-ed,
* Support for spawning with the NS_DISPATCH_EVENT_MAY_BLOCK flag set,
* Automatic use of NS_DISPATCH_AT_END when required,
* Support for specifying the runnable priority for runnables.
There are also some correctness improvements, and exposed a better API
for dispatching normal runnable functions to background threads.
After these changes the TaskRunnable API should no longer be necessary.
It is re-implemented on top of the executor and kept in-place to avoid
rewriting all consumers.
Differential Revision: https://phabricator.services.mozilla.com/D130705
While the build system could be improved to actually support those
cases, because of all the legacy things involved, it would be a lot more
work for a low reward.
Instead, we forbid them, which allows to remove the non-unified builds
exception in xpcom/rust/gtest.
Differential Revision: https://phabricator.services.mozilla.com/D127035
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
In the Itanium C++ ABI VTables contain extra fields before the virtual function
pointer list for RTTI information, and these fields are not eliminated even
when RTTI is disabled using -fno-rtti. The two relevant fields for rust-xpcom's
vtables are the "offset to top" field, which contains the displacement to the
top of the object from the corresponding vtable pointer as a `ptrdiff_t`
(`isize`), and the "typeinfo pointer" field which points to the typeinfo object
and is null when building with -fno-rtti. The VTable pointer points after these
fields to the beginning of the virtual function pointer list.
While these extra fields would generally not be accessed in -fno-rtti
situations, gcc and clang still support `dynamic_cast<void*>` even when
-fno-rtti is passed, meaning that the "offset to top" field should be present.
Although I was unable to find documentation for the C++ ABI used on Darwin, it
appears to behave the same as the Itanium C++ ABI when it comes to VTable
layout.
In order to include these fields in the manual vtables built by the rust-xpcom
macros, a `&'static VTableExtra<VTableType>` is used instead of directly using
the vtable type, and the vtable reference stored in the struct is offset into
the allocation.
As the only platform I know of to not include these extra fields is Windows,
they are generated on all non-Windows platforms.
Differential Revision: https://phabricator.services.mozilla.com/D115085
