The API version detection functionality was broken in SDKProcessor
because we were passing in "Lpackage/Class;" as the class name rather
than just "package/Class". Also, some classes have a weird situation
where some methods were moved around in later API versions. For example,
some put* and get* methods in Bundle were moved to BaseBundle in API 21.
If we only checked BaseBundle.put*, we would think they are API 21+
only. The workaround is to check both the top-level class and the
declaring class for a member, and choose the lower API level as the
minimal API level for that member.
This patch also fixes bugs in including the right class members.
For SDKProcessor we want to include all public members of a class,
including inherited members, because the private/protected members are
not part of the public API. For AnnotationProcessor, we want to include
all the members declared in that class, including private and
protected members, because we may want to access private/protected
members of our own Java classes from C++.
Trying to decipher MOZ_SUBCONFIGURE_ICU given its lack of indentation is
difficult at best. It looks like some lines have tabs, and those tabs
make everything line up right...convert everything to spaces to make
sure things line up correctly.
Some mozconfigs don't include mozconfig.linux*, and don't get gtk-related
definitions, so move them in a separate mozconfig. To avoid having two
files, one for 32-bit builds and one for 64-bit builds, rely on the
includer to set PKG_CONFIG_LIBDIR appropriately.
At the same time, move all the --enable-default-toolkit=cairo-gtk2 in that
new file in the case the gtk3 package wasn't pulled from tooltool.
There are a variety of ways that the parent and child process ensure that
the child process exits quickly in opt builds, but for AddressSanitizer
builds we want to let the child process to run to completion, so that we
can get a LeakSanitizer report.
This requires adding some addition LSan suppressions, because running
LSan in child processes detects some new leaks.
This will add more verbosity, with the intent of having the triggered
suppressions be displayed in the form:
"--23983-- used_suppression: 3 Bug 794372 /builds/slave/try-l64-valgrind-0000000000000/src/build/valgrind/cross-architecture.sup:90 suppressed: 20,736 bytes in 648 blocks"
It's been clear from user feedback that people don't realize that `mach
mercurial-setup` doesn't make any changes unless they tell it to.
Reinforce this message in the prompts printed by mach_boostrap.py.
--HG--
extra : commitid : DmE2U8DHQ3M
extra : rebase_source : 20e5c4d6ff7610bdceef7817c5ea2854d271ccdf
Add a mozconfig fragment enabling rust on mac builds.
Include it in the official integration mozconfig files only.
Developer checkouts don't require rust.
This command is used by tab completion handlers. A user reported that
hitting tab in his shell resulted in the mercurial-setup out of date
check spewing output.
--HG--
extra : commitid : 5DE199lHcn2
extra : rebase_source : 7f2ef1c325b3f0deb091798a5d21820257d6c1f6
extra : amend_source : 016428cf3d2442cc2ced24d328aec53a752619ab
Having not configured or out-of-date tools benefits nobody. It slows
people down.
Version control tools are an integral part of working on Firefox. It is
important for version control tools to be configured optimally and to be
continuously updated so they stay optimal.
The `mach mercurial-setup` command exists to optimally configure
Mercurial for working on Firefox and other Mozilla projects.
This commit adds a pre-dispatch handler to mach that will verify
Mercurial is in a happy state. If `mach mercurial-setup` has never
executed, it will complain. If `mach mercurial-setup` hasn't been
executed in the past 31 days, it will complain.
Yes, aborting command execution and forcing people to context switch to
run `mach mercurial-setup` is annoying. First, we have carved out
several exceptions to this behavior, including detection for running in
automation, on the machines of curmudgeons, when Mercurial isn't being
used, and from non-interactive processes. Second, I argue that people
ignore optional notifications and that having persistently
poorly-configured tools is worse than a single context switch at most
every month. Therefore, the heavyhanded approach is justified.
In addition, if we did support a non-fatal notification, we would
introduce the problem of extra output from commands. If anyone was e.g.
parsing mach output, we could very likely break those systems. These
cases should be caught by the isatty() check or be running in a context
with MOZ_AUTOMATION set. But you never know.
--HG--
extra : commitid : 7f7JQpa953u
extra : rebase_source : 47b6304b6ac2c9d8136f2023a7d03df7d1f45e4f
extra : source : f06616ee7b2b54d63d20ee4795539514d1df8c7b
Having not configured or out-of-date tools benefits nobody. It slows
people down.
Version control tools are an integral part of working on Firefox. It is
important for version control tools to be configured optimally and to be
continuously updated so they stay optimal.
The `mach mercurial-setup` command exists to optimally configure
Mercurial for working on Firefox and other Mozilla projects.
This commit adds a pre-dispatch handler to mach that will verify
Mercurial is in a happy state. If `mach mercurial-setup` has never
executed, it will complain. If `mach mercurial-setup` hasn't been
executed in the past 2 weeks, it will complain.
Yes, aborting command execution and forcing people to context switch to
run `mach mercurial-setup` is annoying. First, we have carved out
several exceptions to this behavior, including detection for running in
automation, on the machines of curmudgeons, when Mercurial isn't being
used, and from non-interactive processes. Second, I argue that people
ignore optional notifications and that having persistently
poorly-configured tools is worse than a single context switch at most
every 2 weeks. Therefore, the heavyhanded approach is justified.
In addition, if we did support a non-fatal notification, we would
introduce the problem of extra output from commands. If anyone was e.g.
parsing mach output, we could very likely break those systems. These
cases should be caught by the isatty() check or be running in a context
with MOZ_AUTOMATION set. But you never know.
--HG--
extra : commitid : AWLag0bpQOY
extra : rebase_source : fba19b918e9eadc6d5976c10d82974fb7e835e9d
A subsequent commit will want to access the state directory path without
possibly creating it. Make that possible by extracting path resolution
to its own function.
--HG--
extra : commitid : 60aMbblXNF9
extra : rebase_source : 5e83e36d32ff1f581e91b442005139c89f3bc3f3
- Removed old robotium jar in replace for the newer one.
- Newer robotium has packaging changes which were updated in all tests.
- Updated in build.gradle and makefile.
--HG--
extra : transplant_source : %949%F2%F6%10v%9A%CA%8B%FD%EE%05%28%D8%1E%0D%09_%BE%D3
isatty() raises ValueError if the file descriptor is closed. Detect
closed file descriptors.
--HG--
extra : commitid : 3wH6lYWoPHZ
extra : rebase_source : df0f657a3b2afa6dbc710e98c0b3c31f3b8be486
extra : amend_source : 7a153ea95c7b77cf0d53116d70c7a840fbbdb92e
We were de-referencing the checker variable after having moved it into
the array, which was causing a null pointer crash.
With this fixed, the plugin can be built with more recent versions of
clang.
Backed out changeset 58331e57de1c (bug 917999)
Backed out changeset 50f9123412c7 (bug 917999)
Backed out changeset 3b19643ec039 (bug 917999)
CLOSED TREE
Write a mozconfig fragment which makes the rust toolchain
provided by tooltool available for linux builds.
Use linux64 mozconfigs to enable rust for official builds of
that target. These aren't used outside of automation builds,
so including rust there will verify code on check-in without
requiring developers to install rust.
This removes ambiguity as to which modules are being imported, making
import slightly faster as Python doesn't need to test so many
directories for file presence.
All files should already be using absolute imports because mach command
modules aren't imported to the package they belong to: they instead
belong to the "mach" package. So relative imports shouldn't have been
used.
--HG--
extra : commitid : 6tFME1KKfTD
extra : rebase_source : 78728f82f5487281620e00c2a8004cd5e1968087
This adds a flag to |mach robocop| that does everything to run a
Robocop test except launch the actual test. Instead of launching the
test, it starts the mochi.test server and launches Fennec with a test
profile; then it sits and waits forever.
This allows regular Java IDEs (IntelliJ, but previously Eclipse) to
run Robocop tests like regular instrumentation tests, "injecting" them
into the prepared testing environment. It's quite nice!
--HG--
extra : rebase_source : a5ab08222110a20291aebe70ef1fda0d340dbe7d
extra : source : e91ac9a35f86928fcd519911476ee7d68d06f921
When a method returns type D derived from RefCounted type B, there is an
ImplicitCastExpr (or an ExplicitCastExpr, if there is an explicit cast
to the base type in the code) in the AST between the CallExpr and
MemberExpr, which we didn't take into account before. This caused the
analysis to not work on common patterns such as
nsCOMPtr<nsIXPCOMInterface>.
We require ndk-r8e, so we don't need to support paths for all the other
NDKs prior to that now. Also took the opportunity to clean the paths up
so things fit on a reasonable screen.
This will ensure we properly parse class names containing spaces.
Note that if a class name somehow ends up containing operator| then this will end up again silently failing.
When a method returns type D derived from RefCounted type B, there is an
ImplicitCastExpr (or an ExplicitCastExpr, if there is an explicit cast
to the base type in the code) in the AST between the CallExpr and
MemberExpr, which we didn't take into account before. This caused the
analysis to not work on common patterns such as
nsCOMPtr<nsIXPCOMInterface>.
LTO changes in GCC5 make it break the assumptions made in the test-ctors
source. The simplest and more correct thing to do is to just force the
test files never to be built with LTO. They are meant to have a particular
layout that LTO might break at any time anyways.
We need to use _impl variants within mozalloc.h when they are defined because
of how mozglue.dll is linked on Windows, where using malloc/free would use
the symbols from the MSVCRT instead of ours.
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
We're using as many defaults from the configure step as we can. We're also opinionated upon the defaults, but obviously allow most compare-locales options to be specified.
There are two exceptions:
Reference language is specified to be en-US, without optional argument. This is our in-tree command, and the reference language is known.
We always clobber the merge dir, and don't give an option not to. We default to a merge dir in the objdir, so we don't need to be that paranoid as in the standalone version.
Also, compare-locales clobbers merge-dir/browser etc, so you're not going to get / removed.
--HG--
extra : rebase_source : c0f63e566779e83201708d05966f3583ae82e4ee
JS_STANDALONE builds don't need everything in mozglue; have mozglue omit the
unneeded code for such builds.
Since the SpiderMonkey binaries are now more like the other Gecko binaries, we
can remove some special cases for JS_STANDALONE in GeckoSharedLibrary,
GeckoProgram, etc. All Gecko binaries now use mozglue, which contains mfbt, so
we no longer need mention mfbt explicitly.
Add a property to the getBuildConfiguration testing function's result that
indicates whether we're using jemalloc or not.
Include the newly necessary source directories in the SpiderMonkey source
package.
I tested locally that both checks give the expected error if I
temporarily change the != to an =.
--HG--
extra : transplant_source : %01N%B9%8B%BC%1E%07%D6%AE%BA2%7B%87%FB%25Y%19%B6%A9%D3
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
--HG--
extra : transplant_source : D%D3%FE%169%05%D0X%F3KK%17%9EW%88%BCs%9B%86%5D
Sphinx has been complaining about a number of reStructuredText warnings
for a while. Fix all the ones in .rst files.
Not asking for review because this is docs only and changing .rst files
can't break anything important.
DONTBUILD (NPOTB)
This patch defines bug components for code that I have historically
touched.
--HG--
extra : rebase_source : 738916cf41ac11c094f5c15667925a7221e6446e
extra : histedit_source : 0f7d5cd869a7b239def58877a8858159219cdf59
The Files sub-context allows us to attach metadata to files based on
pattern matching rules.
Patterns are matched against files in a last-write-wins fashion.
The sub-context defines the BUG_COMPONENT variable, which is a 2-tuple
(actually a named tuple) defining the Bugzilla product and component for
files. There are no consumers yet. But an eventual use case will be to
suggest a bug component for a patch/commit. Another will be to
automatically suggest a bug component for a failing test.
--HG--
extra : rebase_source : 0f4004d364f6c2fe2b7f306823cb94313f4ebfe5
extra : histedit_source : 2beea807a122e08ba152a37beec2fcbe80981b64
We want the ability to read data from any moz.build file without needing
a full build configuration (running configure). This will enable tools
to consume metadata by merely having a copy of the source code and
nothing more.
This commit creates the EmptyConfig object. It is a config object that -
as its name implies - is empty. It will be used for reading moz.build
files in "no config" mode.
Many moz.build files make assumptions that variables in CONFIG are
defined and that they are strings. We create the EmptyValue type that
behaves like an empty unicode string. Since moz.build files also do some
type checking, we carve an exemption for EmptyValue, just like we do for
None.
We add a test to verify that reading moz.build files in "no config" mode
works. This required some minor changes to existing moz.build files to
make them work in the new execution mode.
--HG--
extra : rebase_source : 2f39e19c2eb11f937da85d41b9a514ca810d6be0
extra : source : af07351bf2d6e85293ae3edf0fe4ae6cbc0ce246
The Files sub-context allows us to attach metadata to files based on
pattern matching rules.
Patterns are matched against files in a last-write-wins fashion.
The sub-context defines the BUG_COMPONENT variable, which is a 2-tuple
(actually a named tuple) defining the Bugzilla product and component for
files. There are no consumers yet. But an eventual use case will be to
suggest a bug component for a patch/commit. Another will be to
automatically suggest a bug component for a failing test.
--HG--
extra : rebase_source : 9489738136d929a53db7f54bbe6acf3186e0a47c
We want the ability to read data from any moz.build file without needing
a full build configuration (running configure). This will enable tools
to consume metadata by merely having a copy of the source code and
nothing more.
This commit creates the EmptyConfig object. It is a config object that -
as its name implies - is empty. It will be used for reading moz.build
files in "no config" mode.
Many moz.build files make assumptions that variables in CONFIG are
defined and that they are strings. We create the EmptyValue type that
behaves like an empty unicode string. Since moz.build files also do some
type checking, we carve an exemption for EmptyValue, just like we do for
None.
We add a test to verify that reading moz.build files in "no config" mode
works. This required some minor changes to existing moz.build files to
make them work in the new execution mode.
--HG--
extra : rebase_source : f701417f83dfa4e196e39182f8d0a6fea46c6fbb
extra : source : af07351bf2d6e85293ae3edf0fe4ae6cbc0ce246
This reworks how the Mochitest DOMWINDOW and DOCSHELL leak detector works. Rather than
collecting immediately in the top-level script, it sends a message to all processes
telling them to carry out collections. Each process prints out a message when it has
finished the collections. This message is used by the test harness to decide when windows
and docshells for that process should be have been destroyed.
In non-e10s mode, the shutdown leak detector is only run in the parent process, to work
around various issues with leak detection in the thumbnail process tests.
This reworks how the Mochitest DOMWINDOW and DOCSHELL leak detector works. Rather than
collecting immediately in the top-level script, it sends a message to all processes
telling them to carry out collections. Each process prints out a message when it has
finished the collections. This message is used by the test harness to decide when windows
and docshells for that process should be have been destroyed.
It looks like overwriting AS here is not intentional. Before this patch,
it is impossible to override AS through mozconfig for anything that runs
past this stage in configure.
