Controlling is two things:
* initializing Glean
* toggling upload enabled.
Initializing also means setting the internal metrics (client info), some
of which we detect at build time.
`upload_enabled` will eventually be tied to the Firefox Telemetry upload preference.
Differential Revision: https://phabricator.services.mozilla.com/D68543
--HG--
extra : moz-landing-system : lando
This also upgrades the vendored Glean version, which thanks to our
upstream work doesn't change anything else (except one small
Mozilla-developed dependency)
It's still feature-gated to nightly.
In C++ there's now a `MOZ_GLEAN` define.
For Rust it's behind the `glean` feature (enabled on nightly only).
The `fog` crate is empty, so no Glean is actually instantiated.
Differential Revision: https://phabricator.services.mozilla.com/D68539
--HG--
rename : third_party/rust/glean-preview/src/metrics/mod.rs => toolkit/components/glean/src/lib.rs
extra : moz-landing-system : lando
Pick commits
- 20daa86: Revise git hooks (#68)
- 81d0024: Revise `destroy_cubeb_device_info` (#67)
- 1cc8a31: Add a hook to check that commits are formatted and linted correctly (#66)
- aa80b3f: Try using the model id as group id. (#64)
- ab31978: Bail if `cargo clippy` or `cargo fmt` fails (#65)
- 3860bb3: Fix comments in #57 (#63)
- ef5f58b: Run `cargo fmt` and make scripts executable (#62)
- a4c83db: Fix two bugs and add logs (#57)
Differential Revision: https://phabricator.services.mozilla.com/D68402
--HG--
extra : moz-landing-system : lando
Also update the update-rust.sh script in a couple ways:
- Stop copying the source for mp4parse_fallible into the tree; use crates.io
- Include submodules in mp4parse-rust checkout; needed for tests
- Exclude unnecessary build.rs from mp4parse_fallible, it was causing problems
- Update mp4rust_capi/Cargo.toml patch to exclude cdylib. It's only necessary for test_ffi and causes build problems otherwise
Differential Revision: https://phabricator.services.mozilla.com/D68139
--HG--
extra : moz-landing-system : lando
This commit removes the old WasmTextToBinary implementation and replaces
it with a stub that calls into the rust wat implementation.
The old wasmTextToBinary function took an optional boolean parameter to
indicate that additional metadata was desired. This extra metadata was
a list of offsets of instructions in the code section. I'm not sure if
this was intentional or not, but it looks like it only includes root
expressions of nested s-exprs.
These offsets were used in two tests, debug/wasm-breakpoints.js and a
wasm/regress test. Adding this functionality into 'wat' proved to be a large
change for a function that didn't seem to have much use cases. A new
wasmCodeOffsets function was added to replicate this feature. It's implemented
in rust using the 'wasmparser' crate that cranelift uses. When cranelift is
compiled, this shouldn't result in an increased binary size. If the compile
time or binary size proves to be an issue in non-cranelift builds, I think
we can make this a conditional feature for JS-shells only.
Differential Revision: https://phabricator.services.mozilla.com/D67245
--HG--
extra : moz-landing-system : lando
This commit removes the old WasmTextToBinary implementation and replaces
it with a stub that calls into the rust wat implementation.
The old wasmTextToBinary function took an optional boolean parameter to
indicate that additional metadata was desired. This extra metadata was
a list of offsets of instructions in the code section. I'm not sure if
this was intentional or not, but it looks like it only includes root
expressions of nested s-exprs.
These offsets were used in two tests, debug/wasm-breakpoints.js and a
wasm/regress test. Adding this functionality into 'wat' proved to be a large
change for a function that didn't seem to have much use cases. A new
wasmCodeOffsets function was added to replicate this feature. It's implemented
in rust using the 'wasmparser' crate that cranelift uses. When cranelift is
compiled, this shouldn't result in an increased binary size. If the compile
time or binary size proves to be an issue in non-cranelift builds, I think
we can make this a conditional feature for JS-shells only.
Differential Revision: https://phabricator.services.mozilla.com/D67245
--HG--
extra : moz-landing-system : lando
This commit removes the old WasmTextToBinary implementation and replaces
it with a stub that calls into the rust wat implementation.
The old wasmTextToBinary function took an optional boolean parameter to
indicate that additional metadata was desired. This extra metadata was
a list of offsets of instructions in the code section. I'm not sure if
this was intentional or not, but it looks like it only includes root
expressions of nested s-exprs.
These offsets were used in two tests, debug/wasm-breakpoints.js and a
wasm/regress test. Adding this functionality into 'wat' proved to be a large
change for a function that didn't seem to have much use cases. A new
wasmCodeOffsets function was added to replicate this feature. It's implemented
in rust using the 'wasmparser' crate that cranelift uses. When cranelift is
compiled, this shouldn't result in an increased binary size. If the compile
time or binary size proves to be an issue in non-cranelift builds, I think
we can make this a conditional feature for JS-shells only.
Differential Revision: https://phabricator.services.mozilla.com/D67245
--HG--
extra : moz-landing-system : lando
This patch removes the old thread_profiler bindings, and adds
support for profiling WR with the tracy profiler, which is a
much more advanced frame profiler.
Since it's very lightweight, and only instruments annotated CPU
and GPU zones, it can retain very large profiles, allowing
fine grained analysis of thread interactions, CPU spikes etc.
Differential Revision: https://phabricator.services.mozilla.com/D66926
--HG--
extra : moz-landing-system : lando
Updates `wgpu` code as well as our WebIDL bindings.
The `wgpu-types` is a new component crate that has public types available to
Rust applications that target the Web directly.
Differential Revision: https://phabricator.services.mozilla.com/D67013
--HG--
extra : moz-landing-system : lando
This is the skeleton for interacting with the Windows Task Scheduler, it
produces an exe that can register and unregister itself as a scheduled
task.
The schedule is to run once daily. Bug 1568287 is reserved for discussions
of other trigger patterns, possibly depending on the channel.
This uses a the Windows Event Log for logging, Bug 1343676 deals with
possibly extending that to a rotating log file.
Differential Revision: https://phabricator.services.mozilla.com/D35507
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset 85ea1d36da66 (bug 1515451)
Backed out changeset 779bc1fa07ae (bug 1515451)
Backed out changeset 0c6771b60b76 (bug 1515451)
This is the skeleton for interacting with the Windows Task Scheduler, it
produces an exe that can register and unregister itself as a scheduled
task.
The schedule is to run once daily. Bug 1568287 is reserved for discussions
of other trigger patterns, possibly depending on the channel.
This uses a the Windows Event Log for logging, Bug 1343676 deals with
possibly extending that to a rotating log file.
Differential Revision: https://phabricator.services.mozilla.com/D35507
--HG--
extra : moz-landing-system : lando
