These types aren't handled very helpfully by Visual Studio's default
visualizer. Fortunately it's not difficult to write custom visualizers
for them.
This does not handle most flavors of `ResultImplementation` -- only the
one that the present author found most immediately useful. Handling them
is not difficult, but merely tedious; they are left to future authors to
deal with as needed.
Differential Revision: https://phabricator.services.mozilla.com/D149320
Including glean_parser 6.1.1
Two important things in there:
* glean_parser: [data-review] Include extra keys' names and descriptions in data review template
* Glean: Derive `serde::{Deserialize, Serialize}` on `Lifetime` and `CommonMetricData`
Differential Revision: https://phabricator.services.mozilla.com/D149381
Now that we're no longer testing FOG init instrumentation via rust-in-gtest, we
need a new thing to test in this manner or we'll delete this code and (in my
case) completely forget how we used to do this.
So let's replace the real instrumentation test with a boring one that doesn't
actually require all the boilerplate, but isn't harmed by it either.
Differential Revision: https://phabricator.services.mozilla.com/D147451
This instrumentation test has been disabled since bug 1763474 because delaying
init to this test meant that the preinit queue would overflow.
Because GoogleTest runs all at once and in its own decided order, we shouldn't
write any test that depends on FOG init happening at a specific time unless we
make it happen before the test suite even runs.
...and if we do that, the test resets that we perform in between will
obliterate the value in the init instrumentation, meaning we can't test it
anyway.
So let's test this instrumentation in mochi where there's a little more...
control? Certainty, anyway, about how often test resets happen (never) and
whether FOG init happens (it does).
The only thing we then have to worry about that could delete this information
before we can test it is an ill-timed "metrics" ping being sent. Which is why
we skip the test between the hours of 3AM and 5AM (local).
Differential Revision: https://phabricator.services.mozilla.com/D147448
We're seeing a lot of null crashes here. Maybe we're running script since
we last checked mPrintObject and the printer was disconnected or
something along those lines, so just add a null check.
Differential Revision: https://phabricator.services.mozilla.com/D149387
In the console we might receive messages that need to be inserted at a specific
position in the output to respect the chronological order.
This is very visible when evaluating an expression in the console while we are
fetching cached messages, or when the expression is logging lots of messages, since
the evaluation result doesn't go through the ResourceCommand itself.
Since we were relying on the order of insertion in `mutableMessagesById` for the
order of messages in the output, we had no choice but clone the Map to insert
the new message at the specific position.
With lots of messages, this can be utterly slow, and is something people are experiencing.
To fix this, we're adding a new state property, `mutableMessagesOrder`, which holds
message ids in the chronological order. It's then used to compute `visibleMessages`.
As we don't have to clone the Map anymore, it makes reordering as fast as looking
for an index in the array and splicing it (which is fast).
We also take this opportunity to switch away from our `findIndex` usage; most often
than not, the messages will be reinserted at the end of the array, so we can loop
through it backward to find the index faster.
We still keep `mutableMessagesById` as a Map so lookup are fast, and we don't have
to deal with impacts we'd have if we'd switch to an object.
The existing node test helper to get a message at a specific index are migrated
to make use of `mutableMessagesOrder`, and a few test cases and assertions are
added to check that the new property is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D148658
This test demonstrates that the patch in Bug 1764501 does fix the performance issue
we were seeing. Having it in tree will ensure we don't regress this.
Differential Revision: https://phabricator.services.mozilla.com/D149110
The source tree seems to be updated asynchronously after the source selection.
Also, the SourcesTree component wasn't correctly selecting and expanding the tree
when the selected source was immediately selected as it gets created in the source tree.
Differential Revision: https://phabricator.services.mozilla.com/D148838
This in-out parameter business used to be necessary (bug 1249279), but
we don't propagate the new widget scale to remote documents (which are
the common case now) and we seem to be doing just fine without that, so
I'm not sure why this would be needed anymore.
Also simplify some unit conversions while at it.
Differential Revision: https://phabricator.services.mozilla.com/D149032
We already had code to ignore samples where the return address isn't on the stack.
Extend this to the frame pointer, because the JIT frame unwinder will soon need that
too.
Differential Revision: https://phabricator.services.mozilla.com/D149218
The profiler enter-frame instrumentation now happens after pushing the frame pointer,
and the exit-frame trampoline is used before restoring the frame and stack pointers.
This is a little awkward because the frame pointer isn't in the frame layout yet, but
it does move us one step closer to changing that. This will also make it possible to
remove the frame size from the frame descriptor.
Differential Revision: https://phabricator.services.mozilla.com/D149217
