I likely regressed this as part of e9416a307987 (bug 1397406).
Before this change, '*' in filenames didn't work.
MozReview-Commit-ID: 33m83H6UTZ
--HG--
extra : rebase_source : 5732cd2b7f4851c6cd564c8dcbd7d303fbad570b
This fixes a regression from bug 1408365. Ideally these imports would
be defined at the top of the file, then the py2 linter would have caught
them. Even more ideally, mozboot would have some tests that hit these
code paths.
MozReview-Commit-ID: BWvIwAdUBF4
--HG--
extra : rebase_source : 6472f730a5cd12aa98af7a21f958d1ad2400f995
I think we're approaching an inflection point for the bootstrapper,
one where it no longer is possible to bootstrap without a source
checkout. For now, however, let's just do the simplest thing and
install the Proguard JAR along the happy path.
MozReview-Commit-ID: xUY37eE6oR
--HG--
extra : rebase_source : 31549ab3b6d662d84761c2a260cd236a5809c8ac
The goal is to use a newer Android-Gradle build plugin version (2.3.3
is latest stable). That requires a modern Gradle (anything 3.3+, but
3.4.1 is the default from my Android Studio), and also a newer
build-tools (25.0.3 is latest stable).
The locations of lint output changed, and we want to use the standard
output location because it's difficult to accommodate variant details
in custom names. We change the location of findbugs output to follow
suit.
This requires either:
- fixing lint errors
- adding to the lint whitelist
- using the new lint baseline
It's best to use the new lint baseline, which will happen in the next commit.
MozReview-Commit-ID: D19FzIDCJrE
--HG--
extra : rebase_source : 12d132c0c3e0dbe2b8873b31360ea96d612de44c
By default Eclipse CDT will scan the source tree for binaries so that it can
add those binaries to the list of things that it can run. This scanning is a
constant interuption and can last several seconds. Besides that, it's
currently useless for our setup since the only binaries that we're interested
in running are in the object directory (which it doesn't scan), and those are
set up during project generation. (The only binaries found in the source tree
are a couple of uninteresting bundled libraries.)
CLOSED TREE
MozReview-Commit-ID: 2WaH8qceALq
By default, scalability mode is activated for files with 5,000 lines or more.
There are quite a few C++ files with more than 5,000 lines, and Eclipse seems
to work fine with them with scalability mode turned off (even
nsCSSFrameConstructor.cpp which is over 13,000 lines long). Increasing the
number of lines before scalability mode is enabled allows Eclipse to handle
these files better.
MozReview-Commit-ID: 8mGYIHStHes
Without this setting, eclipse will refuse to open Objective-C files (it will
defer to an external editor). Adding *.mm to the file types that are treated
as C++ allows Eclipse to open them, and to provide some code assistance for
the bits of the files that it can understand.
MozReview-Commit-ID: ASeXesWxY4g
This setting allows Eclipse to notice when files it has open are changed
externally (such as by hg/git, for example). It can then update the contents
that it has for the open files, avoiding annoying issues such as saving changes
after an `hg pull -u` resulting in either "Resource is out of sync" errors or
else clobbering of the changes hg made to files.
MozReview-Commit-ID: 8WmewM7lbHe
The blocking Welcome screen is quite confusing for a new user. It is not clear
where to find the Mozilla stuff they expect to see when opening Eclipse, or
that the user needs to close the entire content area to get to it. Besides that
the screen isn't very useful for Mozilla people who will find more relevant
help from searching the online documentation, and who won't be creating new
projects in the generated workspace, etc.
MozReview-Commit-ID: 8YssnonAR1d
The setting to ensure that there is a newline at the end of files when they
are saved is very annoying. Besides adding unnecessary and unexpected cruft
to diffs, some parts of the codebase (some of the reftest directories for
example) have a policy of NOT having a newline at the end of their files.
MozReview-Commit-ID: IjIYxDsKS13
This makes us write the code formatter settings into the workspace settings
directory instead of the project settings directory. This is preferable
since when users make settings changes they are more likely to work with the
workspace settings, so we should put them there. Putting them there also
fixes a bug whereby the calls to _write_noindex/_remove_noindex would
overwrite the formatter settings file shortly after it had been created.
To get the formatter to show up in the UI we also need to set the formatter
settings as a one line pref value in the CDT UI settings. This duplication
is what Eclipse does when a new formatter is manually added, and it's
necessary to get the formatter working correctly.
MozReview-Commit-ID: KP4w0VbNCF7
We expect to start requiring rust 1.21 soon, so have
./mach bootstrap upgrade users to it to consolidate
churn between now and then.
MozReview-Commit-ID: HEnXm25duUr
--HG--
extra : rebase_source : d05071ee5c2852eb69da22e80623f21ca8c6f7cb
For some reason, Windows builders are setup in a way that prevents a
task from purging the toolchain cache of old files. Until that is
figured out and fixed, all the error message related to that achieves is
confuse people because the treeherder Failure Classification tab shows
them first. Practically speaking, the error doesn't prevent anything
from working properly. The worst that can happen is disk space running
out because of the toolchain cache being filled up, which would lead to
actual errors.
As the error happens on very many windows build, that leads to a lot of
errors being bucketed on bug 1391811, while they may well be varying
unrelated issues.
It also leads to people thinking their try builds fail because of that,
when they aren't (e.g. bug 1408212).
--HG--
extra : rebase_source : e25fc99db8e0920cfa238d0f78f15c78e140e3ec
The old system was simply in place because I couldn't figure out how
to pipe `yes | ...` in Python. This is good enough to replace it, and
much less fragile since the license hashes change frequently.
MozReview-Commit-ID: AhJJPqMKfUh
--HG--
extra : rebase_source : 86289e692d646181d545457fc953610e165ee2df
This is just one flavor of the "reftets" suite, so we need to add a distinct
scheduling component for it.
MozReview-Commit-ID: AtKuvuUCk1l
--HG--
extra : rebase_source : 3f316f0293e8d1245fc6e891bbcd044586ab6c06
This was simply oversight before. I ran into this using the
taskcluster-proxy /bewit interface, which returns a URL of the form
https://domain.net/short/path/to.file?bewit="several thousand
characters", which leads to an IOError due to the long path. Let's
assume that such query strings and fragments are transient; we should
drop these parts of the fetched URLs when writing to disk.
MozReview-Commit-ID: FMJHMp7a3rA
--HG--
extra : rebase_source : da701e7d5250f59f39e4b6262952a08d0068e9ac
This patch introduces a new report formatter for the mozlint
framework used by "./mach lint" that respects Unix output conventions,
popularised by grep(1), compilers, and preprocessors.
The output format looks like this:
testing/marionette/driver.js:1153:48: no-unused-vars error: 'resp' is defined but never used.
Many editors (ed, Emacs, vi, Acme) recognise this format, allowing
users to interact with the output like a hyperlink to jump to the
specified location in a file.
MozReview-Commit-ID: 3IyiFmNbtMY
--HG--
extra : rebase_source : a2628a999c187a1c43f3cc5d32e6db835028eca4
By using the PartialConfigEnvironment, the clients of buildconfig will
depend on config.statusd/ files instead of config.status directly.
Clients can access substs and defines using buildconfig.substs['FOO'] or
buildconfig.defines['BAR'], and then collect file-level dependencies for
make using buildconfig.get_dependencies(). All GENERATED_FILES rules
already make use of this because file_generate.py automatically includes
these dependencies (along with all python modules loaded).
As a result of this commit, re-running configure will no longer cause
the world to be rebuilt. Although config.status is updated, no build
steps use config.status directly and instead depend on values in
config.statusd/, which are written with FileAvoidWrite. Since those
files are not official targets according to the make backend, make won't
try to continually rebuild the backend when those files are out of date.
And since they are FileAvoidWrite, make will only re-run dependent steps
if the actual configure value has changed.
As a result of using JSON to load data from the config.statusd
directory, substs can be unicode (instead of a bare string type).
generate_certdata.py converts the subst manually to a string so the
value can be exported to the environment without issue on Windows.
Additionally, patching the buildconfig.substs dict no longer works, so
the unit-symbolstore.py test was modified to patch the underlying
buildconfig.substs._dict instead.
The other files that needed to be modified make use of all the defines
for the preprocessor. Those that are used during 'mach build' now use
buildconfig.defines['ALLDEFINES'], which maps to a special
FileAvoidWrite file generated for the PartialConfigEnvironment.
MozReview-Commit-ID: 2pJ4s3TVeS8
--HG--
extra : rebase_source : d6bb0208483f9f043e7be1b36907ca13243985f8
This removes the dependency on config.status for CONFIGURE_DEFINE_FILES.
Instead, each file depends on the specific configure values that it
uses.
MozReview-Commit-ID: H4oLmJei1KR
--HG--
extra : rebase_source : 287498e8c336d24b1c95d29caf97e5febb56063b
The config.statusd directory is created alongside config.status, which
contains the same information but is split across many files instead of
all in a single file. This allows the build system to track dependencies
on individual configure values.
MozReview-Commit-ID: 2DbwKCJuNSX
--HG--
extra : rebase_source : 8b6257fd9c75cff3e4b6513d69048c0e3fdda5f4
This also migrates the vcs.py test to mozversioncontrol and adds a new task for
it.
MozReview-Commit-ID: 9jTRkjNupVA
--HG--
extra : rebase_source : 400f27498e00ea45234ad7c951770b098e916b8e
Sometimes commands return non-zero even though everything is ok. For example,
'hg outgoing' returns 1 if there are no outgoing files. This adds a way for
specific function calls not to abort if something goes wrong. Instead, stderr
will be printed (if any) and an empty string is returned.
MozReview-Commit-ID: E089djeHrmr
--HG--
extra : rebase_source : be351f357705e09c3fe876cecefa7ddd9c48987e
This adds 'get_outgoing_files'. First it automatically attempts to find the
upstream remote the current change is based on, then returns all files changed
in the local branch.
If an upstream remote can't be detected, it raises MissingUpstreamRepo
MozReview-Commit-ID: 9zSB9EdwVU8
--HG--
extra : rebase_source : e352d6d471644ef9eda76b972b789d6b54449471
There's currently a function for getting added files (A) and modified files
(M). We'll also eventually need the ability to get deleted files (D) and any
combination of the above, e.g (AM). Rather than creating a new function for
each possible case, let's have a single function where you can pass in which
modifiers you are interested in. With this patch, if you want all modified and
added files, you can do:
get_changed_files('AM')
By default 'ADM' is used.
This also adds a 'mode' option for git. This allows consumers to return staged
files, unstaged files or both. The default ('unstaged') keeps the current
behaviour in tact.
MozReview-Commit-ID: 9IA1bxaJS80
--HG--
extra : rebase_source : 160f650220ca9a35b4b116bc9fa13f28d84419fa
Technically this turns on gnu++14. I encountered a few errors when using c++14:
1) _USE_MATH_DEFINES needed to be defined for MinGW
2) MinGW did not define _finite under c++14
3) MinGW's float.h did not define Microsoft specific float functions under c++14
All of these were because c++14 defines _STRICT_ANSI_ which MinGW obeys and
avoids defining certain functions. The first two could be patched around, but
the third was a blocker, so we switched to gnu++14
MozReview-Commit-ID: 6Y7gEQgApYp
--HG--
extra : rebase_source : dabbd40c049c36e780b585e0bef0a8e25887d089
Unfortunately this also needs to be kept in Makefile.in to handle
other consumers of INCLUDES while we transition them.
MozReview-Commit-ID: 9OYlu6Jv1XZ
--HG--
extra : rebase_source : 719200501a93e836a03a64b5e1cd950a8f2e696a
GCC isn't safe to use on architectures that switched to Clang because
libstdc++ and libc++ aren't very compatible. Newer LLVM and Clang are
often already installed as a dependency for Mesa packages. So, always
require llvm* package.
MozReview-Commit-ID: 8651mz5tiIp
--HG--
extra : rebase_source : 7713e167b34f14a18fd5bf9c5ec33e926b2b929c
Currently line linters (linters that open a file and process it line by line,
by applying a regex for example), don't handle directories. If a directory is
passed in, it will try to 'open' it, which fails. Directories can get hit if
the linter has a directory in its include directive or if the user passes in
--no-filter.
This patch modifies LineLinters so that if a directory is detected, we search
for all relevant files under that directory. If 'extensions' is used, we'll
look for only files with appropriate extensions. Otherwise we assume the
linter wants every file.
MozReview-Commit-ID: D9lzTNuQTob
--HG--
extra : rebase_source : 0b952c06eae28b67b687813ff7e75b231b2dd4d3
The MozillaBuildBootstrapper specific rust install code in not needed as
mozbase already includes genertic code to achieve the same outcome. The
mozilla-build specific code also leads to issues where it tries to add already
existing targets and fails the bootstrap. This changeset removes the
mozilla-build specific step.
MozReview-Commit-ID: G0BqKZrF40A
--HG--
extra : rebase_source : 60e9638afff744c937a9665d6fd5830187835ea4
Gregory Szorc
Sebastian Hengst
Gabriele Svelto
Jonathan Watt
Nathan Froyd
Zibi Braniecki
Xidorn Quan
Steve Armand
Andrew Halberstadt
Ryan VanderMeulen
Geoff Brown
Blake Kaplan
Nick Alexander
Ralph Giles
Mike Hommey
Dustin J. Mitchell
André Reinald
Joel Maher
Andi-Bogdan Postelnicu
Andreas Tolfsen
Wes Kocher
Mike Shal
Tom Ritter
Philip Jenvey
Phil Ringnalda
Chris Manchester
Jan Beich
SingingTree
Botond Ballo
Kris Maglione