This patch tries to address the issue that legacy CJK extensions have various
extended variants where the core of the encoding is compatible but the edges
are incompatible. Without this patch, we reject e.g. Big5 if it has a single
character from the UAO extension or a single Windows end-user-defined character.
Likewise for the other legacy CJK encodings.
This patch tolerates:
* All Big5 extensions (the motivating part of this patch).
* Windows EUDC for EUC-KR.
* Classic Mac OS extensions to Shift_JIS, EUC-KR, GBK, and Big5 to the
extent practical considering conflicting definitions of what constitutes
a lead byte in the Encoding Standard but a single-byte extension in
Classic Mac OS.
* JIS X 0213 / 2004 extensions to Shift_JIS and EUC-JP. (It's unclear if
these have actual deployment.)
Tolerating means that the occurrence of an extension character doesn't
disqualify a candidate but only applies a penalty to the pending score.
If there is enough other convincing content, it should be able to overcome
the penalty.
Differential Revision: https://phabricator.services.mozilla.com/D111372
Updates wgpu, WebGPU IDL, in particular the ImageCopyXxx types and render pass attachments.
Adds explicit mapping of the GPUTextureFormat enum. Our old casting was incorrect, because the enums diverged a bit.
Differential Revision: https://phabricator.services.mozilla.com/D110997
Updates wgpu, WebGPU IDL, in particular the ImageCopyXxx types and render pass attachments.
Adds explicit mapping of the GPUTextureFormat enum. Our old casting was incorrect, because the enums diverged a bit.
Differential Revision: https://phabricator.services.mozilla.com/D110997
This is a minimal implementation of a WER exception module that can intercept
crashes of Firefox processes and write out a fully formed crash report, that is
a minidump, an .extra file containing the minimum annotations required by
Socorro and an event file.
The module in and by itself is not functional: an entry needs to be added to
the registry and the processes which want to be monitored need to register it
at runtime. With this patch applied it will only be built but it won't be
packaged with Firefox nor it will be used when doing local development.
The module implementation has a few notable properties:
* We use an empty C++ shim (mozwer) to build the module DLL. This is
because the build system doesn't support building DLLs directly from Rust.
* The actual implementation is written in Rust (mozwer-rust) and exposes the
callbacks that will be invoked by the WER service.
* We use the winapi crate to access Windows native functionality but given it
is missing some bits (including upstream!) we declare them in our crate for
the time being.
* The minidump uses the same options we use in Firefox and should be of
similar size. I manually tested different type of crashes including
__fastail() ones and they're all reliably captured.
* The .extra file contains only the annotations that are strictly required for
submitting the crash to crash-stats.mozilla.org. More should be added in the
future. The existing annotations are all extracted from within the module
code because we have no way to access the ones that were stored in Firefox'
crashed processes (nor should we, since we hope to catch crashes that happen
even before Firefox sets up crash reporting internally).
* The module does not distinguish between main process and content process
crashes at the moment. This will need to be implemented when we hook it up
with the crash reporting code within Firefox.
* We use libc's time() function to get the crash time in order to be consistent
with what the regular exception handler does.
Differential Revision: https://phabricator.services.mozilla.com/D101708
This also includes an upgrade of glean_parser to v2.5.0
This was done using the following command:
./mach vendor python glean_parser==2.5.0
Differential Revision: https://phabricator.services.mozilla.com/D108448
This also includes an upgrade of glean_parser to v2.5.0
This was done using the following command:
./mach vendor python glean_parser==2.5.0
Differential Revision: https://phabricator.services.mozilla.com/D108448
This should help us isolate what rayon changes could've caused this
stability issue on 32-bit windows.
Automatically generated with:
$ cargo update -p rayon --precise 1.4.1 && cargo update -p rayon-core --precise 1.8.1 && ./mach vendor rust
Differential Revision: https://phabricator.services.mozilla.com/D108045
This should help us isolate what rayon changes could've caused this
stability issue on 32-bit windows.
Automatically generated with:
$ cargo update -p rayon --precise 1.4.0 && cargo update -p rayon-core --precise 1.8.0 && ./mach vendor rust
Differential Revision: https://phabricator.services.mozilla.com/D108045
We're already vendoring 0.8 so no reason not to do this. We're still
held back by an ancient tokio version, which I filed bug 1697845 for.
There are no breaking changes that affect any of our internal consumers.
Differential Revision: https://phabricator.services.mozilla.com/D108046
The logic missed a pair of brackets, leading to memory regions
being merged that shouldn't have been merged (anonymous regions
with access flags set getting merged into the previous mapping)
Differential Revision: https://phabricator.services.mozilla.com/D106772
This is another WebGPU API update, it picks up a lot of changes that were made recently:
- new bind group layout
- new render pipeline descriptor
- new vertex formats
- limits
- compressed texture formats
- index format
- query sets
- and more small ones!
It also brings in the updated `gfx/wgpu` to support these API changes.
Differential Revision: https://phabricator.services.mozilla.com/D107013
This is another WebGPU API update, it picks up a lot of changes that were made recently:
- new bind group layout
- new render pipeline descriptor
- new vertex formats
- limits
- compressed texture formats
- index format
- query sets
- and more small ones!
It also brings in the updated `gfx/wgpu` to support these API changes.
Differential Revision: https://phabricator.services.mozilla.com/D107013
The mozjs_sys crate is actually responsible for all the problems
encountered with the js crate we just removed, but the sm-mozjs-crate
task that builds and runs tests for it doesn't fail because... there is
actually no test to build and run, so all it builds is a static library,
which doesn't expose all the problems that exist.
The content of this crate in mozilla-central is also outdated compared
to servo upstream.
Differential Revision: https://phabricator.services.mozilla.com/D106390
The sm-rust-bindings task that builds and runs tests for it actually only
doesn't fail by three(!) distinct happenstances of chance:
- It somehow doesn't hit a race condition that can happen, but that
attempting to change the build process for jsglue.cpp did,
- The second call to `cargo test` without `--feature debugmozjs` only
works because nothing was cleaned up from the first and the second
build uses artifacts from the first that are otherwise not there if
only running the second.
- The addition of rust code to spidermonkey (the jsrust crate in
js/src/rust) somehow didsn't cause problems in the current
configuration, but in other configurations (which fixing the second
thing above unveils) the build fails because of the multiple
definition of rust_eh_personality between the jsrust staticlib and the
rust stdlib that rustc links to test programs.
On top of all the above, the content of the crate in mozilla-central
has not received updates from upstream servo in years, and doesn't
reflect what servo actually uses.
Differential Revision: https://phabricator.services.mozilla.com/D106389
Dzmitry Malyshau
M. Sirringhaus
Ryan Hunt
R. Martinho Fernandes
Gabriele Svelto
Henri Sivonen
Chris H-C
Henrik Skupin
Butkovits Atila
Jamie Nicol
Kershaw Chang
Jan-Erik Rediger
Narcis Beleuzu
Brindusan Cristian
Yury Delendik
Emilio Cobos Álvarez
Noemi Erli
Jon Bauman
Mike Hommey
Matthew Gregan
smolnar
Chun-Min Chang
Jeff Muizelaar