Since we want one glean metrics definition for all of necko, we will ultimately migrate the existing metrics to this one.
Differential Revision: https://phabricator.services.mozilla.com/D156231
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
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
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
This means we need that Arc in boolean, counter & string,
but we avoid cloning the internal metric. Glean already made that
optimization lately.
Note 1: The actual metric types use an Arc internally in glean-core,
so we're nesting Arcs here. I don't think that's problematic though.
Note 2: No measurements have been done whether this really changes much.
Also we probably do not have that many labeled metrics yet for it to
make a measurable difference to begin with.
Differential Revision: https://phabricator.services.mozilla.com/D152017
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.
Depends on D147450
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.
Note also that we skip-OK this test near local 4AM in case a properly-but-
inconveniently-timed "metrics" ping clears the value between FOG init and the
test run.
Now I thought we could put this in mochi, but it turns out that we reuse
browsers between test files. This means previous files' init of FOG and wiping
of all data causes the test to permafail when not run in isolation.
So here we are in xpcshell where we control init ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D147448
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.
Depends on D147450
Differential Revision: https://phabricator.services.mozilla.com/D147451
