This adds a subcommand ./mach cargo udeps with the following
sub command arguments:
Sub Command Arguments:
--all-crates Check all of the crates in the tree.
crates The crate name(s) to check.
--jobs [jobs], -j [jobs]
Run the tests in parallel using multiple
processes.
-v, --verbose Verbose output.
--message-format-json
Emit error messages as JSON.
--expect-unused Do not return an error exit code if udeps
detects unused dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D159838
Steps performed:
- Add "microsecond" and "nanosecond" to "intl/icu/data_filter.json".
- Run "icu_sources_data.py" to update the ICU data file.
- Run "update-tzdata.sh" to reapply the tzdata 2022f changes.
- Add "microsecond" and "nanosecond" to "SanctionedSimpleUnitIdentifiers.yaml".
- Run "make_intl_data.py units" to regenerate additional SpiderMonkey files.
Spec PR: https://github.com/tc39/ecma402/pull/708
Differential Revision: https://phabricator.services.mozilla.com/D161676
- The bug that was constantly disabling `VIRTUAL_TERMINAL_PROCESSING` has been fixed upstream in CYGWIN (fdbd153932) and merged into MSYS2 (e4fdb0cb73)
- The upcoming MozillaBuild `4.0.2` release will have the updated MSYS2 that contains this fix, allowing us to enable colored output on Windows.
- We will enable `ENABLE_VIRTUAL_TERMINAL_PROCESSING` once (For each stdout and stderr) on initializing the formatter to ensure that `VIRTUAL_TERMINAL_PROCESSING` is enabled whenever Mach is called..
- These changes will only be active if the MozillaBuild version is greater than or equal to Release `4.0.2`
Differential Revision: https://phabricator.services.mozilla.com/D138256
- The bug that was constantly disabling `VIRTUAL_TERMINAL_PROCESSING` has been fixed upstream in CYGWIN (fdbd153932) and merged into MSYS2 (e4fdb0cb73)
- The upcoming MozillaBuild `4.0.2` release will have the updated MSYS2 that contains this fix, allowing us to enable colored output on Windows.
- We will enable `ENABLE_VIRTUAL_TERMINAL_PROCESSING` once (For each stdout and stderr) on initializing the formatter to ensure that `VIRTUAL_TERMINAL_PROCESSING` is enabled whenever Mach is called..
- These changes will only be active if the MozillaBuild version is greater than or equal to Release `4.0.2`
Differential Revision: https://phabricator.services.mozilla.com/D138256
`HAS_CONNECTX` is not used in `netwerk/protocol/http` as of bug 1689604.
In NSPR, it is used to enable the use of `connectx`, which is available
since macOS 10.11, and we target 10.12, which means it's always
available, so we don't need to check for it based on the target version
(and checking the host version was wrong, too).
Differential Revision: https://phabricator.services.mozilla.com/D156275
Considering builds with clang-cl now enable all the same warnings as those
with clang, and those flags are not given to clang-cl, that means
they're not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D154054
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 switches the code to instead use the generated source file, which is
discovered based on `OUT_DIR` so is easier for rust-analyzer to understand.
The configuration for rust-analyzer will be updated in the next part to
make sure that rust-analyzer is able to take advantage of these changes,
and produce better diagnostics.
Differential Revision: https://phabricator.services.mozilla.com/D153269
We are going to compile JS into WebAssembly! This is the first patch
in an upcoming queue. Here we introduce wasm32 architecture so that
SpiderMonkey can be compiled with enabled jit for wasi target.
Differential Revision: https://phabricator.services.mozilla.com/D145790
Change XUL and other dylibs to be built with an @rpath/<dylib> install name (LC_ID_DYLIB) instead of @executable_path/<dylib>.
Change executables to be built with an @rpath dyld search path set to @executable_path by default so that @rpath/<dylib> dylibs in the same directory can be resolved. For executables not in the same directory as @rpath dylibs, such as plugin-container, set a relative @rpath such as @executable_path/../../../.
Previously, dylib install names were set as @executable_path/<dylib> allowing them to be resolved by dyld for the loading executable if the executable resided in the same directory as the dylib. For executables not in the same directory as the dylibs, dyld resolved these dylibs using DYLD_LIBRARY_PATH set before launching the process by Firefox code. With this change, loading does not rely on DYLD environment variables. Instead, dylibs have an install name set as @rpath/<dylib> and each executable loading a dylib has its @rpath set at compile-time to refer to dylib directory.
Differential Revision: https://phabricator.services.mozilla.com/D147360
This addresses the original intent of the bug report which asks for allowing
sndio to be built on more than just OpenBSD. In addition of modifying the
existing --enable-sndio to support this request, the option
--enable-audio-backends was added which takes a list of possible backends to
support per discussion in the bug report.
For example specifying --enable-audio-backends=alsa,jack,pulseaudio,sndio
allows for runtime selection of those four cubeb backends. If all four backends
are available the user can specify `media.cubeb.backend` in `about:config` to
force a specific backend.
Removed superfluous set_define()s as libcubeb's moz.build does the necessary
`DEFINES['...']` assignments for each backend.
In addition logic for finer control of audio backend selection on Android was
added. One can now specify aaudio, opensl or both (which is the default).
Differential Revision: https://phabricator.services.mozilla.com/D141450
This addresses the original intent of the bug report which asks for allowing
sndio to be built on more than just OpenBSD. In addition of modifying the
existing --enable-sndio to support this request, the option
--enable-audio-backends was added which takes a list of possible backends to
support per discussion in the bug report.
For example specifying --enable-audio-backends=alsa,jack,pulseaudio,sndio
allows for runtime selection of those four cubeb backends. If all four backends
are available the user can specify `media.cubeb.backend` in `about:config` to
force a specific backend.
***
Bug 1351378 - Address linter error. r?mhentges,glandium
***
Bug 1351378 - Remove superfluous set_define(). r?mhentges,glandium
libcubeb's moz.build does the necessary `DEFINES['...']` assignments for each
backend. Remove superfluous set_define().
Differential Revision: https://phabricator.services.mozilla.com/D141450
Basically, argument types must allow for templated types and optional
args must recognize at least `mozilla::Nothing()`. It's a bit hacky but
it seems like a useful extension that won't destroy anything, and I
need this.
Differential Revision: https://phabricator.services.mozilla.com/D138526
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
Goal of this patch is to allow disabling all JIT codegen in certain Firefox processes
to let us enable more security mitigations. The JS VM uses the atomic operation stubs
we compile at runtime so this patch converts those to inline assembly instead.
This adds a Python script to generate a header file that has all the inline assembly code.
The inline assembly instructions are based on the JIT-compiled trampoline code.
The generated header is used for all x86/x64/arm32/arm64 builds, so this now includes
no-JIT builds as well.
Differential Revision: https://phabricator.services.mozilla.com/D135984
Goal of this patch is to allow disabling all JIT codegen in certain Firefox processes
to let us enable more security mitigations. The JS VM uses the atomic operation stubs
we compile at runtime so this patch converts those to inline assembly instead.
This adds a Python script to generate a header file that has all the inline assembly code.
The inline assembly instructions are based on the JIT-compiled trampoline code.
The generated header is used for all x86/x64/arm32/arm64 builds, so this now includes
no-JIT builds as well.
Differential Revision: https://phabricator.services.mozilla.com/D135984
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
Also update the table of Firefox requirements. It's worth noting that I
actually upgraded to 1.57 earlier than I should have (too close to
freeze), but what is done is done.
Differential Revision: https://phabricator.services.mozilla.com/D134124
It is the default. It has been the default since at least Xcode 2.2,
from 2005. ld64 doesn't say anything, but lld warns about it.
Differential Revision: https://phabricator.services.mozilla.com/D132447
The Linux desktop capture code now relies on these. The build will fail at the
link stage if these are not in system header wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D130090
On SDK versions older than 10.0.22000.x we defaulted to 128, but with
this update, Microsoft removed the default and created a compiler error
if the CPU architecture was not specified. This change explicitly
defines the CPU architecture, resolving the compiler error.
Differential Revision: https://phabricator.services.mozilla.com/D128509
The SandoxedWasmLibrary now represents the wasm static library, which
is automatically converted to C via wasm2c. The corresponding source
is handled like a normal source, and the rlbox library is generated
as a normal GeckoSharedLibrary with no xpcom linkage.
Differential Revision: https://phabricator.services.mozilla.com/D128329
We already require Xrandr 1.3 inderectly through GTK3 (`>=1.2.99`).
This bumps the requirement to 1.4, which got released in 2012 and
is thus part of RHEL 7 and Ubuntu 14.04.
Differential Revision: https://phabricator.services.mozilla.com/D126581
Historically, client.mk was not invoked with -jn because it would create
race conditions, but that was actually mostly solved by the addition of
`.NOTPARALLEL` in bug 422986, although the mechanism of adding -jn via
`MOZ_MAKE_FLAGS` or `MOZ_PARALLEL_BUILD` has continued well past that.
Nowadays, client.mk is only invoked by mach (it will even bail out if
that's not the case) and only has one target (`build`) and no
dependencies.
This means we don't need to rely on `MOZ_PARALLEL_BUILD` to pass `-jn` in
some cases, and can just always invoke `make -f client.mk` with `-jn`, even
when we just want no parallelism, in which case we can use `-j1`.
This, in turn, allows to remove the extra allow_parallel argument to
`_run_make`, and only rely on `num_jobs`, and to remove some of the
multiple ways the `n` in `-jn` could be set.
Differential Revision: https://phabricator.services.mozilla.com/D124729
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
MKCSHLIB, used to build WASM_LIBRARY, refers to DSO_LDOPTS, which refers
to IMPORT_LIBRARY on mingw builds, but for WASM_LIBRARY, IMPORT_LIBRARY
is never set by the build backend.
Differential Revision: https://phabricator.services.mozilla.com/D123540
The build system assumes the target compiler is of the same type as the
wasm compiler, but that's not true for wasm32-wasi, which we compile
with clang, while targeting windows, which we compile with clang-cl.
We handle the duality for host/target in a compiler-specific way, but
here, the wasm compiler is always going to be clang.
Differential Revision: https://phabricator.services.mozilla.com/D123041
The build system assumes the target compiler is of the same type as the
wasm compiler, but that's not true for wasm32-wasi, which we compile
with clang, while targeting windows, which we compile with clang-cl.
We handle the duality for host/target in a compiler-specific way, but
here, the wasm compiler is always going to be clang.
Differential Revision: https://phabricator.services.mozilla.com/D123041
The build system assumes the target compiler is of the same type as the
wasm compiler, but that's not true for wasm32-wasi, which we compile
with clang, while targeting windows, which we compile with clang-cl.
We handle the duality for host/target in a compiler-specific way, but
here, the wasm compiler is always going to be clang.
Differential Revision: https://phabricator.services.mozilla.com/D123041
Except for the following two files, no other header file is still including
"jsapi.h". Add a rule to "check_spidermonkey_style.py" to make sure we don't
regress this progress.
Exceptions:
- "vm/Compartment-inl.h" still needs to include "jsapi.h" for `JS::InformalValueTypeName()`.
- "jsapi-tests/tests.h" still needs to include "jsapi.h" for `JS_ValueToSource()`.
Differential Revision: https://phabricator.services.mozilla.com/D123209
They are equivalent, except for the fact that MACOSX_DEPLOYMENT_TARGET
may apply to more processes in a normal build. In practice, all the
processes that matter are covered through compiler flags.
On the opposite end, MACOSX_DEPLOYMENT_TARGET isn't necessary passed in
all cases (like clangd, mach static-analysis, etc.), while compiler
flags are.
Differential Revision: https://phabricator.services.mozilla.com/D122145
Sanitizers try to intercept __tls_get_addr to find DTLS blocks. In some
cases, they fail miserably with a crash. And in the cases they don't
crash, they don't seem to actually work properly anyways.
This affects both build time when running host programs compiled with
sanitizer flags (this only actually affects rust build
scripts/procedural macros on non-cross builds, not C/C++ host programs),
and execution time, e.g. when running tests.
Differential Revision: https://phabricator.services.mozilla.com/D120574
The `-/*` filter also removes the alias (`%%ALIAS`) and parent locale (`%%Parent`)
links, so we have to manually add them back when we're using `-/*`.
The ICU docs warn about this issue, but unfortunately that warning wasn't
present when we originally created our filter file, so this bug went unnoticed
for a long time.
Differential Revision: https://phabricator.services.mozilla.com/D116981
It's not practically make a difference (the flags we end up setting it
to don't do anything when linking all the wasm files into one).
Differential Revision: https://phabricator.services.mozilla.com/D116437
This last part to support "calendar" requires a bit more code.
`GetCalendarDisplayName()` performs the following steps:
1. Validate the input matches the `type` nonterminal, per
CanonicalCodeForDisplayNames, step 4.a.
2. Then convert it to lower case, because ICU expects lower case names and it
needs to be in lower case for `LanguageTag::replaceUnicodeExtensionType()`.
3. Replace calendar name aliases with the preferred name, e.g. use "ethioaa"
instead of "ethiopic-amete-alem".
4. Check the input isn't too large, just in case ICU somehow doesn't properly
handle large string inputs.
5. Retrieve the old-style value of the calendar name, for example "gregorian"
for the calendar name "gregory".
6. And finally call `uldn_keyValueDisplayName` to search for the localised name.
Our ICU data file doesn't yet include calendar names. To include calendar names
we need to enable them in "data_filter.json", rebuild the ICU data file, and
then reapply the update for tzdata 2021a. (Reapplying the tzdata changed
"intl/tzdata/GIT-INFO", but otherwise didn't change any time zone files.)
Adding the calendar names to the ICU data file results in a slight increase of
the overall data file size (79,184 bytes).
The existing "calendar.js" test file was renamed to "month-calendar.js", so
the test file for the new "calendar" type can be named "calendar.js".
Differential Revision: https://phabricator.services.mozilla.com/D116008
This adds a fallible factory method to create new NumberFormat instances. This
allows us to report initialization errors at time of initialization, rather than
when format is called, and remove internal checks in the implementation for
successful initialization.
The existing fluent code assumes that creating a NumberFormat instance always
succeeds. This patch updates that code to handle failures.
Differential Revision: https://phabricator.services.mozilla.com/D114593
This temporarily adds intl::NumberFormatterSkeleton to the public API so that
we can use it in PluralRules. This allows us to remove the SpiderMonkey
NumberFormatterSkeleton implementation when we convert SpiderMonkey to use
intl::NumberFormat.
We can remove intl::NumberFormatterSkeleton from the public API when we
implement intl::PluralRules in Bug 1704509.
Differential Revision: https://phabricator.services.mozilla.com/D111887
This adds a fallible factory method to create new NumberFormat instances. This
allows us to report initialization errors at time of initialization, rather than
when format is called, and remove internal checks in the implementation for
successful initialization.
The existing fluent code assumes that creating a NumberFormat instance always
succeeds. This patch updates that code to handle failures.
Differential Revision: https://phabricator.services.mozilla.com/D114593
This temporarily adds intl::NumberFormatterSkeleton to the public API so that
we can use it in PluralRules. This allows us to remove the SpiderMonkey
NumberFormatterSkeleton implementation when we convert SpiderMonkey to use
intl::NumberFormat.
We can remove intl::NumberFormatterSkeleton from the public API when we
implement intl::PluralRules in Bug 1704509.
Differential Revision: https://phabricator.services.mozilla.com/D111887
- We can and actually should remove the -fsanitize=% flags consistently
on all cargo targets, not only programs, but because of limitations in
cargo we can't really do that everywhere. We do need it for TSAN,
though.
- Because of the above, we actually don't need to single-out NATIVE_TSAN
builds anymore.
- The comment regarding the initial filtering of MOZ_CARGO_WRAP_LDFLAGS
somehow got separated from where it's happening, so we move it back to
where it belongs.
Differential Revision: https://phabricator.services.mozilla.com/D114579
Arthur Carcano
Mozilla Releng Treescript
ahochheiden
André Bargull
Butkovits Atila
Mike Hommey
Henri Sivonen
Stanca Serban
Nika Layzell
Joel Maher
Dmitry Bezhetskov
Emilio Cobos Álvarez
Haik Aftandilian
Jesse Schwartzentruber
Nordin Abouzahra
Iulian Moraru
Mitchell Hentges
Zhao Jiazhong
Lars T Hansen
criss
Jan de Mooij
Christian Holler
Yoshi Cheng-Hao Huang
shravanrn@gmail.com
Deian Stefan
Cristian Tuns
Sylvestre Ledru
Sandor Molnar
Alexandru Michis
june wilde
Greg Tatum
Andi-Bogdan Postelnicu
Dan Minor
Norisz Fay
Narcis Beleuzu
Robert Mader
Kagami Sascha Rosylight
Jeff Walden
Andreea Pavel
Dzmitry Malyshau
Yury Delendik
Andi-Bogdan Postelnicu
Cosmin Sabou
Csoregi Natalia
Caroline Cullen
Mike Hommey
Noemi Erli
Steve Fink
carolinecullen
Chris Fallin
Agi Sferro
Brindusan Cristian