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
I feel as though there's a refactor where both IPC and FFI can reuse the same
macros, but for now this is a fairly copy-pasta-heavy change.
Differential Revision: https://phabricator.services.mozilla.com/D144966
We go from one place where metrics can be (the static maps) to two
(we throw in the factory's dynamic maps (warehouses?))
(( Actually from two to three when you consider the submetric maps ))
Thanks to how we architected things, the necessary macro changes are nice and
small.
Differential Revision: https://phabricator.services.mozilla.com/D143049
Pieces include
* A script for collecting all the ids for metric _types_
* A template for generating the factory that can build each of those types
* mozbuild integration
Differential Revision: https://phabricator.services.mozilla.com/D143048
Previously we used the 27th bit to signal if a metric instance was actually a
labeled_* metric's "submetric". This bit is actually part of the metric type
part of the lower (upper?) 32 bits of the metric_entry_t, but that was okay
because builtin metrics all have their top 5 bits scrubbed.
itsFreeRealEstate.jpg
This can no longer work, though, since JOG will need to be able to have its
own submetrics that don't conflict _and_ will need to keep the type bits
around so we know what instances to build.
(( Yes, yes, I could've designed the system so that we didn't need to,
but this was the less complicated way. We can go down this route when we
provision the 34 Millionth metric and run out of space. ))
So that means taking two bits away from the id portion: one for runtime (we'll
give it 2^26) and one for submetric (2^25).
Differential Revision: https://phabricator.services.mozilla.com/D143044
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
Upgrades to Glean v50.0.1, which comes with a rewritten core and
UniFFI-powered bindings.
Glean has some API changes, so we swap it over to that. Mostly mechanical changes.
Also upgrades to inherent v1.0 in fog.
This matches what Glean uses internally and gets rid of one duplicated crate.
Also upgrades to glean-parser==6.0.1
One crate duplication now (change in `python/mozbuild/mozbuild/vendor/vendor_rust.py` required).
Some new crates now vendored.
These are transitive dependencies of Glean dependencies, all with valid
licenses and already used in other products (mobile).
Differential Revision: https://phabricator.services.mozilla.com/D146062
This adds both the core Rust implementation and the
code to enable the needed language bindings. This
additionally enables GIFFT on the URL type, mirroring
them to a string scalar.
Differential Revision: https://phabricator.services.mozilla.com/D145215
