I don't know exactly why this is happening but we're now directly constructing
MyContainer and not copying it. I confirmed that this is calling the first
Rooted consturctor so I updated the tests to expect this.
Differential Revision: https://phabricator.services.mozilla.com/D125954
The link pointers move to the base class in a similar way to PersistentRootedBase.
This lets us get rid of a bunch more reinterpret_casts.
Differential Revision: https://phabricator.services.mozilla.com/D125952
I don't think this does anything. The type is always present so we won't
restrict use of this constructor by SFINAE, although I may have misunderstood
the purpose of this.
I tried 'fixing' the SFINAE to what I though it should be by using enable_if_t
but it had the same effect as removing it. In both cases the code compiles, and
if I try to construct a rooted with an inappropriate argument it fails with a
sensible error.
Differential Revision: https://phabricator.services.mozilla.com/D125949
This only adds the API and then adds the profiler payload to the buffer. The
deserialization and streaming will happen in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D124026
You can see the `mozilla::MarkerSchema` for the C++ counterpart. This Rust
struct simply wraps the C++ object and keeps the reference of it as RAII. This
heap allocates the inner C++ object but it's fine to do it here, because it's
we only create a MarkerSchema object at the end of a profiling session and it
happens once per marker type. It should be very rare.
Differential Revision: https://phabricator.services.mozilla.com/D124025
JSON writer will be used for the third and last marker API. This is needed
because we need to describe a marker payload struct on how to serialize it.
Differential Revision: https://phabricator.services.mozilla.com/D124024
This is the second API for the markers. This allows one payload as a text for
more information. See the PROFILER_MARKER_TEXT macro for the C++ counterpart.
Differential Revision: https://phabricator.services.mozilla.com/D124023
This is the first and simplest API for the markers. There will be two more
APIs in the following patches (add_text_marker and add_marker). You can see the
PROFILER_MARKER_UNTYPED macro for the C++ counterpart.
Differential Revision: https://phabricator.services.mozilla.com/D124022
MarkerStack object is a bit more complex in the C++ side. But we don't need a
complex object like that in here. A simple enum is enough to determine what
type of marker stack we are capturing. C++ side will be handling the capturing
of the stack.
Differential Revision: https://phabricator.services.mozilla.com/D124021
These structs are needed for the marker APIs. We also have the same structs as
the C++ classes. See `mozilla::MarkerTiming` and `mozilla::MarkerOptions`.
Differential Revision: https://phabricator.services.mozilla.com/D124020
This is a syntactical sugar to write the categories more easily. I prefer to
have this macro because this is the same syntax as the categories in the label
frames API.
Differential Revision: https://phabricator.services.mozilla.com/D124019
For some reason, I thought that `parse_callbacks(Box::new(CargoCallbacks))`
would also automatically adds the initial header files that are manually added.
But apparently `parse_callbacks` is only executed when the inner included
header files are found.
Differential Revision: https://phabricator.services.mozilla.com/D124017
assertEqBytecode couldn't be used with saveIncrementalBytecode because
we were merging at decode timing.
Bug 1687095 changed it to merge before encoding, and the resulting XDR buffer
becomes same between incremental encode and re-encode.
Differential Revision: https://phabricator.services.mozilla.com/D121262
Before this patch, we fetch HTTPS RR in `nsHttpChannel::MaybeStartDNSPrefetch`, which is too early. It's possible that this http request is blocked by an extension but we still send the query for HTTPS RR.
To improve this, we move the time of fetching HTTPS RR a bit late.
Differential Revision: https://phabricator.services.mozilla.com/D125931
The filter type is `UCAL_ZONE_TYPE_ANY` to ensure all possible time zones are
returned, and not just CLDR canonical time zones. (CLDR canonical time zones
are different from IANA canonical time zones.)
Differential Revision: https://phabricator.services.mozilla.com/D125576
- `TimeZone` objects can be created with any time zone identifier, so the "Default"
part in the name isn't correct.
- The "TimeZone" part is no longer needed, now that there's a distinct class for
`TimeZone` objects.
Therefore let's rename `GetDefaultTimeZoneOffsetMs()` to `GetRawOffsetMs()`.
Differential Revision: https://phabricator.services.mozilla.com/D125575
Time zone functions being part of `UCalendar` is an internal implementation
detail of ICU4C. For the public unified Intl API we should rather follow
Temporal (or ICU4C's C++ API) and have a separate `TimeZone` class.
The files were moved using `hg cp` to preserve the file history.
Differential Revision: https://phabricator.services.mozilla.com/D125574
ICU's public API only provides a function to return the preferred hour cycle
(`udatpg_getDefaultHourCycle()`), whereas for `Intl.Locale` we want to be able
to determine all allowed hour cycles. So we have to do it the hard way and
directly read ICU resource bundles to get the data we need for this feature.
Differential Revision: https://phabricator.services.mozilla.com/D125571
Right now the max resolution is 1024 which is visually fine if the gradient is smooth but can cause very visible aliasing artifacts with hard stops in very large gradients. The best way to address this would be to render very large gradients as brushes as we did before caching but involves more work and code to maintain.
In the mean time, increasing the maximum resolution is only a half solution but significantly improves the visual quality in the bad cases. Very large conic gradients are uncommon enough that it should let us focus on higher priority work.
Differential Revision: https://phabricator.services.mozilla.com/D124193
I don't know exactly why this is happening but we're now directly constructing
MyContainer and not copying it. I confirmed that this is calling the first
Rooted consturctor so I updated the tests to expect this.
Differential Revision: https://phabricator.services.mozilla.com/D125954
The link pointers move to the base class in a similar way to PersistentRootedBase.
This lets us get rid of a bunch more reinterpret_casts.
Differential Revision: https://phabricator.services.mozilla.com/D125952
I don't think this does anything. The type is always present so we won't
restrict use of this constructor by SFINAE, although I may have misunderstood
the purpose of this.
I tried 'fixing' the SFINAE to what I though it should be by using enable_if_t
but it had the same effect as removing it. In both cases the code compiles, and
if I try to construct a rooted with an inappropriate argument it fails with a
sensible error.
Differential Revision: https://phabricator.services.mozilla.com/D125949
This use happened during shutdown, at which time the fallback
behaviour of the WebRender hit tester (to return the root APZC)
is equally suitable.
Differential Revision: https://phabricator.services.mozilla.com/D126158
