Many proposals have been merged into the wasm-3.0 branch of the
WebAssembly spec repo. It currently represents the state of the art of
wasm, which we keep up with - proposals that are officially standardized
but not yet super widely implemented.
Basing our spec tests on this reduces duplication across proposal repos
and should help us catch spec problems earlier.
This patch reworks the spec test generator slightly to handle some new
module definition syntax, and removes proposals which have already been
merged into wasm-3.0.
Differential Revision: https://phabricator.services.mozilla.com/D227573
The change is preparation for Bug 1927658.
Add io-surface and dependent crates. io-surface is already audited at supply-chain/audits.toml.
Differential Revision: https://phabricator.services.mozilla.com/D227235
There were trivial failures in some urlbar tests due to the weather suggestions
changes that are the reason for this vendor, plus some ingest metrics changes in
this revision:
7e71b6a672
Differential Revision: https://phabricator.services.mozilla.com/D227271
Allocate dmabuf in VKImage, since direct dmabuf creation by gbm_bo_* is not reliable and comes with various issue.
Texture of swap chain uses vk::ImageCreateFlags::ALIAS(VK_IMAGE_CREATE_ALIAS_BIT).
wgpu_server_adapter_request_device() allocates vulkan device for enabling the following extensions that is necessary for dmabuf support.
- khr::external_memory_fd
- ext::external_memory_dma_buf
- ext::image_drm_format_modifier
- khr::external_semaphore_fd
Differential Revision: https://phabricator.services.mozilla.com/D223910
to_shmem and to_shmem_derive need a description, and selectors needs a
version bump.
Tweak supply-chain audits / config to deal with now published crates.
Differential Revision: https://phabricator.services.mozilla.com/D226468
This passes the profile directory as a crash annotation (which is not
sent in the crash report). The profile directory is already indirectly
passed to the crash reporter through
`MOZ_CRASHREPORTER_EVENTS_DIRECTORY`, however I don't think that's
something to rely upon.
The pref parsing and langpack extension search are done on a best-effort
basis; there may be some odd configurations for which it does not
account. However, it should cover the vast majority of cases. While we
don't want to underserve niche populations that may have an odd
configuration, we do always have fallback behaviors that are likely
still reasonable for most (like using the installation locale). We also
first try the `useragent_locale` annotation before getting locales from
the prefs.
This only looks in the profile and the installation for langpack
extensions. There are a few other system-wide locations that Firefox
looks in. However, the assumptions are:
1) overwhelmingly users install langpacks using the UI rather than
manually downloading the file, and
2) if installed with a package manager (mostly applicable to linux),
langpacks are put in the installation. This is the case for the few
major linux distros I checked.
If we think this is not enough, I can also add the system-wide
directories.
Differential Revision: https://phabricator.services.mozilla.com/D222356
I thought we needed to write some code to implement trait interfaces,
but they actually already work. So, let's just add a simple test for
them.
Differential Revision: https://phabricator.services.mozilla.com/D222025
I thought we needed to write some code to implement trait interfaces,
but they actually already work. So, let's just add a simple test for
them.
Differential Revision: https://phabricator.services.mozilla.com/D222025
This brought in a breaking change: `Suggestion.icon` is now the `bytes`
type. To accomidate that, added UniFFI support for bytes and updated
the SuggestBackendRust code since that field is now a Uint8Array on the
JS side.
Differential Revision: https://phabricator.services.mozilla.com/D223774
