All but one of the current uses of DEFFILE use `SRCDIR + '/file.def'` to
get a srcdir-relative path anyway, and the other one wants an
objdir-relative path, so using Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
MSVC 15.8 linker dislikes forward slashes in the /OUT: parameter when it is generating a profile
--HG--
extra : rebase_source : 6980e212ea5a7ae21513805c22ec0e8ddeaa5dc1
Currently mozconfig.cache overrides a few build options for sccache.
This patch moves them into toolchain.configure so that the build system
will set them properly when sccache is in use. Additionally,
{CC,CXX}_WRAPPER are set in config.mk, so just avoid setting them when
sccache is in use.
Apparently the assembler was willing to accept the previous version, but
was unwilling to find the necessary symbols to link some JS code. This
version correctly quotes the data symbol and adds a little extra quoting
based on examining compiler-generated output.
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
This is tracked upstream at https://github.com/mozilla/libprio/issues/15
MozReview-Commit-ID: L5VWKdEitfB
--HG--
extra : rebase_source : c19472a8658c01a2edc69904e36a2c5409af1396
Previously we weren't passing the variables if we were compiling for Windows
when really we only want to do it if we're compiling with MSVC/clang-cl.
The MinGW-Clang build needs this.
Differential Revision: https://phabricator.services.mozilla.com/D3470
--HG--
extra : moz-landing-system : lando
This setup seems to work well enough to enable me to link
HOST_SIMPLE_PROGRAMS with an AArch64-cross setup. Necessary library
paths are passed to the linker via -LIBPATH and HOST_LDFLAGS rather than
letting MSVC fish them out of the environment. The change to
HOST_SIMPLE_PROGRAMS to pass HOST_LDFLAGS was necessary for this to
work, in addition to the HOST_LINKER changes.
yasm doesn't support aarch64, and trying to use GNU as with an MSVC
build seems like sadness waiting to happen. Instead, we'll generate our
own assembly file that armasm64 will accept.
For "real" Windows-to-Windows cross compiles, the setting of
HOST_OUTOPTION is incorrect: it assumes that if we are cross-compiling,
we'll be using `-o ` (GNU-style) rather than `-Fo` (MSVC-style). Our
normal x86 Windows automation builds are technically not
cross-compiles (host and target are both x86 Windows), so this case has
never bothered us before. But when compiling for AArch64 Windows, we
are really doing a cross-compile, and so we need to be more careful
about how we set this option; otherwise, host compilations will
mysteriously fail because they won't produce any output.
Summary:
This patch ports xptcodegen.py over to the new perfecthash.py system, removing
some special-case code generators, and taking advantage of the easier-to-use
interface.
In addition, the code was changed to take advantage of the endianness
information from Part 2, allowing us to avoid having to perform endianness swaps
at runtime when hashing nsIDs.
Depends On D2616
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2618
The file is added both unconditionally and conditionally to no effect.
MozReview-Commit-ID: 4t57o0bTF9P
--HG--
extra : rebase_source : c5f7bbb20e094cd4f7a9fcd1e143da90069b73b6
The file is added both unconditionally and conditionally to no effect.
MozReview-Commit-ID: JBZKN2qRf73
--HG--
extra : rebase_source : 74b601ae1d64f8ed7a47b02f79cbef66ac606abc
This implements an API in `nsIOSKeyStore.idl` and `OSKeyStore.cpp` to encrypt and decrypt bytes with a key that is stored in the OS key store.
There are two OS adapters in this patch.
Libsecret is used on Linux if available.
The NSS key store is used as fallback if no OS specific key store is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D1858
--HG--
extra : rebase_source : 99d7d646968a46a13ffa61885bb246f6d3e443e4
The deletions in xptcall are when we don't even have support for the CPU
in moz.configure, so I assume that people haven't been compiling on
those architectures for quite some time.
Use wl_keyboard_listener and keymap event to get key mapping on Wayland. Weston simple-im.c example
is used as a reference implementation and actual key modifiers are derived from Wayland/GDK code from
gdkkeys-wayland.c.
MozReview-Commit-ID: 9fMwCvxkYy0
--HG--
extra : rebase_source : 21212cadfa7b1e8bacec2d6fb6970d2aaba7b3f6
For clang-cl, we want to add code to libxul that only exists during the
PGO generation phase, so we can collect data. The most expedient way to
do that is to enable certain files in SOURCES to be marked as to only be
compiled during the PGO generation step.
This adds just enough host shared library support for this one use case,
but also takes shortcuts, because fully supporting host shared library
is a deep rabbit hole I'm not ready to take just to fix --enable-lto
--enable-clang-plugin on mac builds.
One downside is that one my machine the plugin now takes > 80s to build,
instead of 15s before, thanks to the lack of unified sources.
--HG--
extra : rebase_source : bf52a72a01d4e3eb77cf52b646b19734b9273075
Many Rust build scripts compile C/C++ source files with the cc crate, but
cargo doesn't print the output of build scripts unless you pass `-vv`, so
pass that instead of just `--verbose` to get that output in automation and
builds where verbose output was requested.
MozReview-Commit-ID: EUazlKWFsDw
--HG--
extra : rebase_source : 137882c4e970bb0e7b28cc36d7f8e436b59a8011
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
We perform, on the binaries we build, a series of check, that are
implemented as half-baked make commands, invoked after linking them.
- check libstdc++ symbol versions to ensure binary compatibility with
a baseline.
- check glibc symbol versions to ensure binary compatibility with a
baseline.
- check that target binaries don't contain text relocations.
- check that libmozglue is linked before libc on android.
- on libxul, check that NSModules are laid out correctly.
- on libxul, check that there is more than one PT_LOAD segment.
Those checks happen to work where they matter, but their setup is
unreliable. For example, the checks for symbol versions are supposed to
work for libclang-plugin on cross osx builds, but in fact, don't,
because the readelf path doesn't exist, and the command doesn't fail in
that case.
So move them all to a standalone script, performing the checks more
thoroughly (especially the NSModules one, where we now also check that
they are all adjacent), and more verbosely.
--HG--
extra : rebase_source : 7072e622e95f363d4a6c3a8e272d3445d998b592
This changes two config options:
pytest_classes = PyTest # only classes that start with 'PyTest' will be considered tests (previously this was Test)
xfail_strict = true # tests marked as xfail will cause pytest to return non-zero if they unexpectedly pass
MozReview-Commit-ID: DCWoDFbe6Mk
--HG--
extra : rebase_source : 9aa806e035d62d51bb338708396851c40f55ee00
The crash reporter symbol files are the easiest cross-platform way to
find static initializers. While some types of static initializers (e.g.
__attribute__(constructor) functions) don't appear there in a notable
way, the static initializers we do care the most about for tracking do
(static initializers from C++ globals). As a matter of fact, there is
only a difference of 2 compared to the currently reported count of 125
on a linux64 build, so this is a good enough approximation. And allows
us to easily track the count on Android, OSX and Windows builds, which
we currently don't do.
The tricky part is that the symbol files are in
dist/crashreporter-symbols/$lib/$fileid/$lib.sym, and $fileid is hard to
figure out. There is a `fileid` tool in testing/tools, but it is a
target binary, meaning it's not available on cross builds (OSX,
Android).
So the simplest is just to gather the data while creating the symbol
files, which unfortunately requires to go through some hoops to make it
happen for just the files we care about.
--HG--
extra : rebase_source : 458fed1ffd6f9294eefef61f10ff7a284af0d986
This one looks to be pretty straight-forward. It irritates me that
the jar.mn entry doesn't explicitly say that the result is coming from
the object directory, like
locale/browser/bookmarks.html (!bookmarks.html)
but that's for another day.
MozReview-Commit-ID: Cw8E0VJhSxv
--HG--
extra : rebase_source : a1045a5b564b0094b562729bc7234e69ec7a786d
Our bundled Hunspell now significantly differs from upstream Hunspell. Most
importantly, it supports loading dictionaries from jar: URIs, which is now a
requirement for loading bundled and extension dictionaries. This means that
system Hunspell libraries are no longer compatible with our spell checker
code. We should remove the option to use them so that users don't fall into
the trap of trying to use them.
MozReview-Commit-ID: 2ihJe6YOnGf
--HG--
extra : rebase_source : ceb091b9475a2b101156405a02a60015fc36da17
Original patch author is Takuro Ashie <ashie@clear-code.com>
Provide ability to create native EGL window and provide it under NS_NATIVE_EGL_WINDOW
to GL code. The native EGL window is owned/managed by mozcontainer.
MozReview-Commit-ID: 4d0Kk6DRSaD
--HG--
extra : rebase_source : e4677ce51fbf918eb1b0257c66ca4b7220174bbb
The build system knows at build-backend time where to find each IDL
file; making xpidl-process.py rediscover this by requiring
xpidl-process.py to search through directories to find input IDL files
is silly. To rememdy this, we're going to modify things so full paths
are passed into the script. Those paths can then be used directly, with
no searching.
The tail end of the xpidl Makefile.in contains a line, generated for
every xpt file:
$(1): $(addsuffix .idl,$(addprefix $(dist_idl_dir)/,$($(basename $(notdir $(1)))_deps)))
This line, in context, is saying that the xpt file depends on all of its
input IDL files. But xpidl-process.py already generates this
information when we pass it --depsdir, which we do. So this code is
redundant with what we already generate, and it can be removed.
The previous patch required us to pass a single -I argument pointing at
$(DIST)/idl so IDL include statements would work correctly. This patch
lifts that limitation and explicitly points xpidl-process.py at the
locations of all the IDL source directories to search for included IDL
files. Invocations of xpidl-process.py no longer depend on IDL files
being copied to the objdir.
Building on the last patch, we can change the build process to pass in
the directories where the input IDL files can be found. It is
convenient to pass in just the relative source directory paths, to
encourage people to not look in the object directory and to make the
command lines slightly shorter.
xpidl-process.py still assumes that included IDL files can be found by
looking in a single directory. We add a single -I argument to the
invocation of xpidl-process.py to accommodate this short-sightedness.
The current IDL build setup assumes that all IDL files can be found in a
single directory. This setup requires that all IDL files be copied to a
single directory, which is suboptimal in terms of disk I/O and also
complicates things like generating IDL files at build time.
As a first step in moving away from this state of affairs,
xpidl-process.py needs to be taught that the input IDL files could
potentially be found in multiple directories. The current setup can
just specify $(DIST)/idl as the lone directory to examine. Future
patches will change this to examine multiple directories.
The make backend was treating the first output of a GENERATED_FILES rule
specially, since it was the target of the rule containing the script
invocation. We want the outputs of GENERATED_FILES rules to be
FileAvoidWrite so that we avoid triggering downstream rules if the
outputs are unchanged, but if the target of the script invocation is
FileAvoidWrite, then make may continually re-run the script during a
no-op build.
The solution here is to use a stub file as the target of the script
invocation which will always be touched when the script runs. Since
nothing else in the build depends on the stub, we don't need to
FileAvoidWrite it. All actual outputs of the script can be
FileAvoidWrite, and make can properly avoid work for files that haven't
changed.
MozReview-Commit-ID: 3GejZw2tpqu
--HG--
extra : rebase_source : 2b9be82f893e89a4c2f254f05b1e8b9a0f9c631b
I don't understand how this will interact with the parts of the build
where we try to avoid installing the dist/bin manifest, but this makes
sense to me and it works locally for mobile/android and for browser/.
MozReview-Commit-ID: L7RtA4K3WrX
--HG--
extra : rebase_source : 3c08a5aab5398eb3b5685b18e5fe06e926db5f85
We want annotationProcessors to be compiled and archived into a JAR at
build time, ready to generate JNI wrappers. (That is, until we turn
the whole thing into a real annotation processor.) But even if we do
use a real annotation processor, we still need to generate SDK
bindings, which is less clearly expressed as an annotation processor.
(It's more of a build step.)
Gradle provides a huge number of ways to organize build logic to
achieve this: see
https://docs.gradle.org/current/userguide/organizing_build_logic.html.
Unfortunately, the best such way -- putting the code into
$topsrcdir/buildSrc -- has key disadvantages:
1) it pollutes the top-level $topsrcdir, and there's no way to change the
location of buildSrc (https://github.com/gradle/gradle/issues/2472);
2) it's complicated to have a dependent project
(mobile/android/annotations) expose its code via a buildSrc project;
3) using buildSrc at all appears to conflict with the Android-Gradle
plugin version that we are using.
Therefore, this commit does something much simpler: it adds a
Java-only project and uses the resulting Gradle "Jar" task and archive
output as input to the existing Gradle "generate JNI wrappers" task.
MozReview-Commit-ID: 2OyYLPneE1M
--HG--
extra : rebase_source : d99b74a0a1e0bb3e8f4d4540978328388e5c2e42
Some content in Makefile.in is removed because after this change, the
scripts no longer invoke the preprocessor and thus don't have unknown
dependencies anymore outside what is provided in their inputs array.
The order of exports.PREFERENCES in properties-db changes because the
data file has shorthands placed after longhands. The only usage of it
is in test_css-properties-db.js which doesn't care about the order.
MozReview-Commit-ID: AMjzTRf2HYN
--HG--
extra : rebase_source : 7976e48e7c7bba467d77a34ab0d7709cde1ecdf4
We add a minimal Python script to run a process and prefix all its
output with a string. We change the automation tiers to evaluate all
make targets using this script.
MozReview-Commit-ID: 79g5KUd5ked
--HG--
extra : rebase_source : 63388a71b51e5abc05ca8bd48e180af72bf799e6
Some content in Makefile.in is removed because after this change, the
scripts no longer invoke the preprocessor and thus don't have unknown
dependencies anymore outside what is provided in their inputs array.
The order of exports.PREFERENCES in properties-db changes because the
data file has shorthands placed after longhands. The only usage of it
is in test_css-properties-db.js which doesn't care about the order.
MozReview-Commit-ID: AMjzTRf2HYN
--HG--
extra : rebase_source : f9db0659a81bea28b335806ac70e23dc0d36e493
This patch contains the meat of the changes here. The following summarize the changes:
1. xptinfo.h is rewritten to expose the new interface for reading the XPT data,
The nsXPTInterfaceInfo object exposes methods with the same signatures as
the methods on nsIInterfaceInfo, to make converting code which used
nsIInterfaceInfo as easy as possible, even when those methods don't have
signatures which make a ton of sense anymore. There are also a few methods
which are unnecessary (they return `true` or similar), which should be
removed over time.
Members of the data structures are made private in order to prevent reading
them directly. Code should instead call the getter methods. This should make
it easier to change their memory representation in the future. Constructing
these structs is made possible by making the structs `friend class` with the
XPTConstruct class, which is implemented by the code generator, and is able
to access the private fields.
In addition, rather than using integers with flag constants, I opted for
using C++ bitfields to store individual flags, as I found it made it easier
to both write the code generator, and reason about the layouts of the types.
I was able to shave a byte off of each nsXPTParamInfo (4 bytes -> 3 bytes)
by shoving the flags into spare bits in the nsXPTType. Unfortunately there
was not enough room for the retval flag. Fortunately, we already depend in
our code on the retval parameter being the last parameter, so I worked
around this by removing the retval flag and instead having a `hasretval`
flag on the method itself.
2. An xptinfo.cpp file is added for out-of-line definitions of more complex
methods, and the internal implementation details of the perfect hash.
Notable is the handling of xptshim interfaces. As the type is uniform, a
flag is checked when trying to read constant information, and a different
table with pointers into webidl data structures is checked when the type is
determined to be a shim.
Ideally we could remove this once we remove the remaining consumers of the
existing shim interfaces.
3. A python code generator which takes in the json XPT files generated in the
previous part, and emits a xptdata.cpp file with the data structures. I did
my best to heavily comment the code.
This code uses the friend class trick to construct the private fields of the
structs, and avoid a dependency on the ordering of fields in xptinfo.h.
The sInterfaces array's order is determined by a generated perfect hash
which is also written into the binary. This should allow for fast lookups by
IID or name of interfaces in memory. The hash function used for the perfect
hash is a simple FNV hash, as they're pretty fast.
For perfect hashing of names, another table is created which contains
indexes into the sInterfaces table. Lookup by name is less common, and this
form of lookup should still be very fast.
4. The necessary Makefiles are updated to use the new code generator, and
generate the file correctly.
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 05fe935c1d2a9fbfeef786819bfe5913ed8ef862
extra : source : d6bf22099e2195dcb64c3c3d7700d3edd0850a3a
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 2b28b9ff7196d12f4a188c8dddf750b9a5efac5b
extra : histedit_source : 9bc28891950ae8c226cfdefef6f8121ce0b51f58
This patch is a nearly complete reimplementation of BinASTReader, with the following changes:
- Files BinToken.h, BinSource-auto.h (new), BinSource-auto.cpp (new) are now autogenerated by the generator in js/src/frontend/binsouce from the webidl specifications of BinAST and a small
configuration file.
- Optional fields have been removed. Rather, some specific fields may, if so marked in the specifications, contain a Null constant.
- `hasDirectEval` is now checked for consistency (NOT completeness).
- `varDeclaredNames` is now checked for consistency (NOT completeness).
- `lexicallyDeclaredNames` is now checked for consistency (NOT completeness).
- `parameterNames` is now checked for consistency (NOT completeness).
- `capturedNames` is NOT checked.
- Atoms read are now properly expected to be UTF8.
This patch does not implement the entire specifications, but should implement most of ES5. In particular, it is sufficient to parse the source code of:
- Facebook;
- jQuery;
- mootools;
- Underscore;
- Backbone;
- Angular.
MozReview-Commit-ID: HwkVB5dliZv
--HG--
extra : rebase_source : fd7e068343e2af8926c5185e7199ea110a5149bc
This patch handles the actual generation of the static data structures
used to represent XPT information. XPT files are generated in the same
way as they are now, but they are used only as an intermediate
representation to speed up incremental compilation rather than
something used by Firefox itself. Instead of linking XPTs into a
single big XPT file at packaging time, they are linked into a single
big C++ file at build time, that defines the various static consts in
XPTHeader.
In xpt.py, every data structure that can get written to disk gets an
additional code_gen() method that returns a representation of that
data structure as C++ source code. CodeGenData aggregates this
information together, handling deduplication and the final source code
generation.
The ctors are needed for XPTConstValue to statically initialize the
different union cases without resorting to designated initializers,
which are part of C99, not C++. Designated initializers appear to be
supported in C++ code by Clang and GCC, but not MSVC. The ctors must
be constexpr to ensure they are actually statically initialized so
they can be shared between Firefox processes.
I also removed an unnecessary "union" in XPTConstDescriptor.
Together, these patches reduce the amount of memory reported by
xpti-working-set from about 860,000 bytes to about 200,000 bytes. The
remaining memory is used for xptiInterface and xptiTypelibGuts (which
are thin wrappers around the XPT interfaces and header) and hash
tables to speed up looking up interfaces by name or IID. That could
potentially be eliminated from dynamic allocations in follow up
work. These patches did not affect memory reporting because XPT arenas
are still used by the remaining XPTI data structures.
MozReview-Commit-ID: Jvi9ByCPa6H
--HG--
extra : rebase_source : a9e48e7026aab4ad1b7f97e50424adf4e3f4142f
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 65bac47c2cd1a20b3c675a01b44a25a1d2d3ab7a
This patch handles the actual generation of the static data structures
used to represent XPT information. XPT files are generated in the same
way as they are now, but they are used only as an intermediate
representation to speed up incremental compilation rather than
something used by Firefox itself. Instead of linking XPTs into a
single big XPT file at packaging time, they are linked into a single
big C++ file at build time, that defines the various static consts in
XPTHeader.
In xpt.py, every data structure that can get written to disk gets an
additional code_gen() method that returns a representation of that
data structure as C++ source code. CodeGenData aggregates this
information together, handling deduplication and the final source code
generation.
The ctors are needed for XPTConstValue to statically initialize the
different union cases without resorting to designated initializers,
which are part of C99, not C++. Designated initializers appear to be
supported in C++ code by Clang and GCC, but not MSVC. The ctors must
be constexpr to ensure they are actually statically initialized so
they can be shared between Firefox processes.
I also removed an unnecessary "union" in XPTConstDescriptor.
Together, these patches reduce the amount of memory reported by
xpti-working-set from about 860,000 bytes to about 200,000 bytes. The
remaining memory is used for xptiInterface and xptiTypelibGuts (which
are thin wrappers around the XPT interfaces and header) and hash
tables to speed up looking up interfaces by name or IID. That could
potentially be eliminated from dynamic allocations in follow up
work. These patches did not affect memory reporting because XPT arenas
are still used by the remaining XPTI data structures.
MozReview-Commit-ID: Jvi9ByCPa6H
--HG--
extra : rebase_source : 719dfbcb9f83235c0f1f0766270b7f127f9ab04e
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 6f7d4fd1d6cdea2c14866705a2dc972eb5f43382
