Pad the source notes with SRC_NULL such that the code and notes arrays
together maintain uint32_t alignment. This is will later be used to add
optional trailing arrays with uint32_t alignment. The allocator would
already be rounding up our allocation so actually memory usage should be
neutral.
Differential Revision: https://phabricator.services.mozilla.com/D34788
--HG--
extra : moz-landing-system : lando
Make access to trailing arrays more consistent with other data
structures and better encapsulate the reinterpret_casts.
Differential Revision: https://phabricator.services.mozilla.com/D34787
--HG--
extra : moz-landing-system : lando
As PrivateScriptData contains less data, we need to make this test have
more complicated functions so that the test is not sensistive to
allocator rounding. This also removes the binjs variant of test until
they next time they are regenerated.
Differential Revision: https://phabricator.services.mozilla.com/D35840
--HG--
extra : moz-landing-system : lando
We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
--HG--
extra : moz-landing-system : lando
This needs https://github.com/eqrion/cbindgen/pull/362, but I expect it to be
uncontroversial. I'll add a patch to this bug when it's merged to update it.
cbindgen historically didn't include these, but it turns out to be pretty useful
to generate constants for the style crate (since the binding crate is
`servo/ports/geckolib`).
An alternative is to get a completely different cbindgen-generated header for
these, but that seems a bit wasteful. This generates the constants with the
Style prefix (so we'll get `StyleMAX_GRID_LINE` for example), which is very
ugly. But we probably want to eventually stop using the Style prefix and use a
namespace instead, plus it's trivial to do `auto kMaxLine = StyleMAX_GRID_LINE`,
for example, so it's probably not a huge deal.
Another alternative would be to use associated consts, which _are_ generated by
cbindgen. Something like:
```
struct GridConstants([u8; 0]);
impl GridConstants {
const MAX_GRID_LINE: i32 = 10000;
}
```
Which would yield something like:
```
static const int32 StyleGridConstants_MAX_GRID_LINE = 10000;
```
I'm not sure if you find it preferrable, but I'm also happy to change it in a
follow-up to use this.
We need to fix a few manual C++ function signature definitions to match the C++
declaration.
Differential Revision: https://phabricator.services.mozilla.com/D35197
--HG--
extra : moz-landing-system : lando
Option<> is not FFI-safe, so if we want to use the same representation
everywhere we need to get rid of it. This also makes it take the same amount of
memory as the C++ representation, and it's not very complex, I'd think.
Differential Revision: https://phabricator.services.mozilla.com/D35195
--HG--
extra : moz-landing-system : lando
Small fixup for bug 1561147 - Linux run tasks now have to set NEED_XVFB
to true in order to get the virtual framebuffer needed to run Firefox in
automation.
Differential Revision: https://phabricator.services.mozilla.com/D36086
--HG--
extra : moz-landing-system : lando
We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
--HG--
extra : moz-landing-system : lando
This needs https://github.com/eqrion/cbindgen/pull/362, but I expect it to be
uncontroversial. I'll add a patch to this bug when it's merged to update it.
cbindgen historically didn't include these, but it turns out to be pretty useful
to generate constants for the style crate (since the binding crate is
`servo/ports/geckolib`).
An alternative is to get a completely different cbindgen-generated header for
these, but that seems a bit wasteful. This generates the constants with the
Style prefix (so we'll get `StyleMAX_GRID_LINE` for example), which is very
ugly. But we probably want to eventually stop using the Style prefix and use a
namespace instead, plus it's trivial to do `auto kMaxLine = StyleMAX_GRID_LINE`,
for example, so it's probably not a huge deal.
Another alternative would be to use associated consts, which _are_ generated by
cbindgen. Something like:
```
struct GridConstants([u8; 0]);
impl GridConstants {
const MAX_GRID_LINE: i32 = 10000;
}
```
Which would yield something like:
```
static const int32 StyleGridConstants_MAX_GRID_LINE = 10000;
```
I'm not sure if you find it preferrable, but I'm also happy to change it in a
follow-up to use this.
We need to fix a few manual C++ function signature definitions to match the C++
declaration.
Differential Revision: https://phabricator.services.mozilla.com/D35197
--HG--
extra : moz-landing-system : lando
Option<> is not FFI-safe, so if we want to use the same representation
everywhere we need to get rid of it. This also makes it take the same amount of
memory as the C++ representation, and it's not very complex, I'd think.
Differential Revision: https://phabricator.services.mozilla.com/D35195
--HG--
extra : moz-landing-system : lando
This version includes several fixes for sccache-dist in addition
to changes that make sccache compatible with cargo pipelining.
Differential Revision: https://phabricator.services.mozilla.com/D36075
--HG--
extra : moz-landing-system : lando
'<image>' elements will look at the current clip when painting. Puting one
of them at negative coordinates exposes potential bugs in the blob recoord work.
Differential Revision: https://phabricator.services.mozilla.com/D36072
--HG--
extra : moz-landing-system : lando
Merge Debugger::addGeneratorFrame into DebuggerFrame::setGenerator, and expand
the role of clearGenerator to fully undo the effect of setGenerator.
The association between a Debugger.Frame referring to a generator or async call
and the underlying generator object must be recorded in five separate places, as
a transaction: either all or present, or none are present. To ensure this is
true, this patch places sole responsibility for emplacing all those relations in
a single function (setGenerator), with another function to tear down those
relations (clearGenerator) as its inverse/antidote/complement/antagonist (in the
anatomical sense)/what-have-you.
Actually, when a Debugger.Frame is GC'd, we cannot reliably undo some of the
connections, and in fact can let the GC take care of those for us, so the
tear-down function clearGenerator is split into two overloads, one which is
suitable for use from a finalizer and the other which takes care of the entire
task.
Differential Revision: https://phabricator.services.mozilla.com/D35607
--HG--
extra : moz-landing-system : lando
Later in this patch series, we will be gathering up all the code to manage the
association between DebuggerFrame and AbstractGeneratorFrame objects into a pair
of functions, one to establish a relation and the other to tear it down. The
removeif method combines iteration and entry removal, but we would rather have
entry removal live next to the code that tears down the rest of the association.
In preparation for that, this changeset replaces the sole use of removeIf with
its (not very large) definition, so that the entry removal can be more readily
moved into another function.
Differential Revision: https://phabricator.services.mozilla.com/D35606
--HG--
extra : moz-landing-system : lando
Without this patch, addGeneratorFrame may be called from any realm, and enters
the debugger's realm to call DebuggerFrame::setGenerator. However, we would like
to merge addGeneratorFrame and setGenerator, and call the combined from various
points which are already in the debugger's realm, so it would be a little nicer
to simply make the function assume it is called from the debugger's realm.
Differential Revision: https://phabricator.services.mozilla.com/D35605
--HG--
extra : moz-landing-system : lando
