This should make handling errors more reliable in this situation.
Unfortunately I was unable to test this change, as on my local machine,
`./mach vendor rust` fails with an error even on a fresh checkout of
mozilla-central due to what appears to be an issue with loading
jsparagus sources.
Differential Revision: https://phabricator.services.mozilla.com/D155090
This is regression by bug 1581971.
When using custom profile to run GVE via `./mach run --profile <directory>`,
we add "--profile" argument on `adb`. But, after landing bug 1581971, we
don't pass any profile arguments unfortunately.
So we should add it to use custom profile.
Also, This fixes that `./mach run --enable-fission` is broken. We don't need
`--profile` argument to run GVE with fission.
Differential Revision: https://phabricator.services.mozilla.com/D154772
While here, square off the situation wrt compiler flags:
- target compiler flags used to be set conditionally but have been made
unconditional in bug 1409276, while leaving a hack around that adds
them under some conditions for host directories. We remove the hack
but keep the corresponding comment that is still relevant and should
be taken into account if target compiler flags are made conditional
later on.
- host compiler flags were excluded for host rust libraries, but that
was an oversight of bug 1409276, which should have applied the same
logic for host compilations.
- host compiler flags are actually potentially necessary for target rust
compilations because rust build scripts may build host C/C++ code
(that's the case for GLSL). We have no idea when that may happen, so
we always propagate them. config/makefiles/rust.mk then further
propagates the flags to cargo, but they have to be set in the backend
in the first place for that to happen.
Differential Revision: https://phabricator.services.mozilla.com/D154326
In order to allow rust-analyzer to be able to use the build script in
the mozbuild crate to discover the configuration information, this patch
adds new flags to the vscode config to tell rust-analyzer to invoke
cargo through `./mach cargo check`, and use the correct target directory
within the objdir rather than `$(topsrcdir)/target`.
Due to the virtual filesystem used by rust-analyzer not including files
in the object directory, this is not sufficient to get suggestions for
symbols from the included files, however it will accurately fetch
diagnostics upon save and run things like proc macros.
A new feature will likely need to be added to rust-analyzer to allow us
to specify additional paths to add to the source root for packages to
fix that issue.
Due to this change using `./mach cargo check`, rather than running it
independently, we don't run into issues caused by running `check`
against crates in the workspace which aren't being used, making the
diagnostics more useful.
An additional feature needed to be added to `./mach cargo check` to
allow specifying `--message-format=json`. I am open to suggestions for a
more elegant way to communicate this flag into the makefile.
Depends on D153269
Differential Revision: https://phabricator.services.mozilla.com/D153270
This converges Windows native notification behavior across all installers to use the COM notification server.
This also fixes an issue where interacting with an MSIX notification opened a new window with new tabs correlated to the toast notification launch arguments. MSIX by default calls the application sending a notification with the provided launch arugments, which was an problem as we use launch arguments in the COM server to reconstruct the origin of a notification.
Differential Revision: https://phabricator.services.mozilla.com/D153538
The baldrdash integration of Cranelift is agreed between SM and CL
to be the wrong shape. Our import of the code base is also old and
causes difficulties for us when upgrading some crates (see bug
1774829). We should remove it for now to unblock bug 1774829.
Differential Revision: https://phabricator.services.mozilla.com/D152806
Test can be reenabled after the migration to Python 3.7+ (bug 1734402) because
the fixed Poetry version (1.2.0) has that as minimum requirement.
Differential Revision: https://phabricator.services.mozilla.com/D151913
This allows the profile service to handle `XRE_PROFILE_PATH`,
`--profile`, etc as normal before choosing a "default" background task
profile directory.
Differential Revision: https://phabricator.services.mozilla.com/D149918
Ideally, the code would handle things in a more general way that doesn't
require manually dealing with these lists, but this would require more
testing than there is time left before 102 releases.
While here, remove HOST_CPU_ARCH, which is always the same and thus
never appears in a condition.
This changes none of the generated moz.builds for the current
configuration (but changes the outcome when adding new configurations)
Differential Revision: https://phabricator.services.mozilla.com/D149850
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
