We now store HG or GIT in substs. We don't need to search for
binary paths.
MozReview-Commit-ID: 8sSgPNLok9M
--HG--
extra : rebase_source : bc51087bcb9f2a723e27f240dd06a88540f6d8a8
We now have a variable in config.status for recording the checkout
type. These helper functions for determining if we're Mercurial or Git
can now be one-liners.
As a bonus, we no longer do I/O as part of this function.
MozReview-Commit-ID: HT9sbOhDEkf
--HG--
extra : rebase_source : 8b53b5f50d14c0bdd4ef3dc7b190314af80a76f0
We now store HG or GIT in substs. We don't need to search for
binary paths.
MozReview-Commit-ID: 8sSgPNLok9M
--HG--
extra : rebase_source : bc51087bcb9f2a723e27f240dd06a88540f6d8a8
We now have a variable in config.status for recording the checkout
type. These helper functions for determining if we're Mercurial or Git
can now be one-liners.
As a bonus, we no longer do I/O as part of this function.
MozReview-Commit-ID: HT9sbOhDEkf
--HG--
extra : rebase_source : 8b53b5f50d14c0bdd4ef3dc7b190314af80a76f0
Having Rust dump a stack on panic seems like a useful on-by-default
feature.
MozReview-Commit-ID: ABYTArsMTFh
--HG--
extra : rebase_source : 7d15f44a9ffd14db475db9e5c2964aca31bf0f70
This patch changes the name of the keys that are in the 'linked-files-map.json' that is produced in the code coverage build and are used to map symbolic links to their source files. The new key names (which are the paths to the symbolic links) are now the entire absolute path to each of the files.
MozReview-Commit-ID: 4x1dfk9h2Ov
--HG--
extra : rebase_source : 7d424bbbf1d026ea67c66b743c8c43ea75185733
This is similar to bug 1301751, where something in rust seems to trigger errors
running dsymutil to generate debug symbols in OSX. We can set debuginfo=1 for
these builds as a temporary workaround for now, while we work on a more
permanent solution in rust and/or dsymutil. debuginfo=1 still gives us enough
info for stack traces, although without line info. debuginfo=2 would be useful
for debugging, but is irrelevant to crash reports.
MozReview-Commit-ID: DdA00GzVfWg
--HG--
extra : amend_source : 47d3573042098194a07f9b473e4a02c86a1eba7c
The rigid type comparison added in 51a92a22d6d1 (bug 1375231) was
too rigid. This broke at least one consumer that was comparing an
empty PositiveOptionValue/NegativeOptionValue against a string.
Since comparisons against empty OptionValue are convenient and
don't violate the spirit of the type checking previously added,
this commit relaxes the type equivalence check in cases where the
OptionValue is empty.
MozReview-Commit-ID: UllTrzCjj
--HG--
extra : rebase_source : 2c41428d1be667edecdab0947d006a1a6a533569
OptionValue and its derived classes are exposed to moz.configure
files. As the previous bug fix showed, it is really easy to
accidentally assume the type is a simple string value and do a
string compare against it.
To prevent this class of bugs, this commit adds additional type
awareness to OptionValue.__eq__.
We first check that the argument is a tuple (including any OptionValue
types). If not, we raise a TypeError because the comparison is
invalid. This is arguably a violation of __eq__. But since OptionValue
is exposed to the moz.configure sandbox and typing '==' will invoke
__eq__, we have to do something to prevent this foot gun.
The change also changes the comparison logic.
If we compare against a non-derived tuple instance, we do a tuple
compare. Otherwise, we fall back to the previous logic of
requiring an identical type then doing a tuple compare.
MozReview-Commit-ID: 7IVSL2Asg9j
--HG--
extra : rebase_source : edab573834da240df9ad7c2fc78c85d6159a6ef9
Leaving off this argument makes `mach vendor rust` with large files fall
over with a Python error. While the user still gets a semi-useful error
message prior to this failing, it would be better to not fail here at all.
Cargo recently introduced the `cargo check` command for shortening the
edit-compile cycle when working on large programs. Since we don't
really support invoking `cargo` directly, let's wire up this command to
`mach`. Gecko developers can then `mach cargo check` to ensure their
changes typecheck.
We have a flag set on all Linkables, cxx_link, denoting whether there's
anything being linked into them that requires C++. We do this even when
we link against shared libraries that required C++. But if these
libraries don't export C++ interfaces, there's no reason that the things
linking against them should require C++. Therefore, ignore shared
libraries when making the determination of whether an object requires
C++ or not.
This patch renames the mozinfo flag 'coverage' to 'ccov' to avoid ambiguity in whether a test is being skipped for linux64-ccov or for linux64-jsdcov. It also removes the 'runtests.py' mozinfo hack and renames all occurrences of 'coverage' that are used for skipping tests in linux64-ccov.
MozReview-Commit-ID: IF2640bDQP7
--HG--
extra : rebase_source : 614020325e30d1ca9e01aaf08479b8a4ffaec888
This patch adds a flag to the 'mozinfo.json' that can be used to disable tests when they are running on linux64-ccov. Then, this flag is used to prevent the marionnette test 'test_crash.py' from running on linux64-ccov.
MozReview-Commit-ID: 9IHMiZHxcMK
--HG--
extra : rebase_source : ec690cb3ffa27d3e88d2c0b8c5d510e72a5c5079
The -fsanitize=integer analysis from UBSan can be helpful to detect signed and unsigned integer overflows in the codebase. Unfortunately, those occur very frequently, making it impossible to test anything with it without the use of a huge blacklist. This patch includes a blacklist that is broad enough to silence everything that would drain performance too much. But even with this blacklist, neither tests nor fuzzing is "clean". We can however in the future combine this with static analysis to limit ourselves to interesting places to look at, or improve the dynamic analysis to omit typical benign overflows.
It also adds another attribute that can be used on functions. It is not used right now because it was initially easier to add things to the compile-time blacklist to get started.
Finally, it includes a runtime suppression list and patches various parts in the test harnesses to support that. It is currently empty and it should not be used on frequent overflows because it is expensive. However, it has the advantage that it can be used to differentiate between signed and unsigned overflows while the compile-time blacklist cannot do that. So it can be used to e.g. silence unsigned integer overflows on a file or function while still reporting signed issues. We can also use this suppression list for any other UBSan related suppressions, should we ever want to use other features from that sanitizer.
MozReview-Commit-ID: C5ofhfJdpCS
--HG--
extra : rebase_source : 952043a441b41b2f58ec4abc51ac15fa71fc142f
Support OSX Signed nightlies (in the complete.mar too)
MozReview-Commit-ID: HXiFGE14wYJ
--HG--
extra : rebase_source : 1d02b4714c8fafe6cdcd74e6d9b5612c44dcb3b4
- Set the extensions.legacy.enabled pref for mochitests etc
- Skip a plugin-inside-xpi test for now if legacy extensions
are force-disabled. That test can just be removed once we
get to 57.
MozReview-Commit-ID: As9LtkQTcTS
--HG--
extra : rebase_source : fcc84daef95c453e893cc3b98498fdb87f54b1bb
Gregory Szorc
Ryan VanderMeulen
Rok Garbas
Haik Aftandilian
Greg Mierzwinski
Mike Shal
Rail Aliiev
Sebastian Hengst
Swapnesh Kumar Sahoo
Marco Castelluccio
Carsten "Tomcat" Book
Andi-Bogdan Postelnicu
Nathan Froyd
Wes Kocher
Phil Ringnalda
Kartikaya Gupta
Sylvestre Ledru
Christian Holler
Gabriele Svelto
Justin Wood
Andrew Swan
Mike Hommey
Bryce Van Dyk