`mach try` pushes the repository containing the current directory. When this is
a comm-central checkout, the taskcluster configuration should also come from that
repository.
MozReview-Commit-ID: KWbNAe4jrHT
--HG--
extra : rebase_source : e40f5038bdd190fb4cb801ba817c31a3e4031354
extra : source : 7164b051c965280aeb3083e47a93c6d4ac44e2ed
This enables sphinx to parse both the google and numpy style docstring
formats which tend to be more human readable than the default sphinx
format.
See:
http://www.sphinx-doc.org/en/stable/ext/napoleon.html
MozReview-Commit-ID: REmZ4IoUG8
--HG--
extra : rebase_source : 4e3e788d09a7fcc3d3e84bb94744019583e1ee5e
Fixes the LUL unwind test cases (viz, gtest LulIntegration.unwind_consistency)
when built with Clang 5.
* Increases the test stack size, LUL_UNIT_TEST_STACK_SIZE, from 16KB to
32KB, since 16KB is gives inadequate margin for the test cases used, and
is actually too small when with building with ASan enabled.
* In the generated test functions, uses write() calls that do nothing to
ensure that Clang cannot optimise away the space[] array that is used to
give different frame sizes to the different test functions. Without
these, Clang 5 optimises out this array and that causes all the unwind
tests to fail.
--HG--
extra : rebase_source : 9d91ea9b08e6771facf7a788163d67f1871f5948
Adds minimal support for reading DWARF CFI pertaining to version 4 of the
standard. Dwarf 4 CFI appears to have become the default used by Clang
version 5. There are two changes:
* Accepts cie->version == 4.
* For version 4 CIEs, skips over the two new fields address_size and
segment_size, but ensures that segment_size is zero. Adds comments in
ReadFDEFields about what to do if we ever find a case where segment_size
is nonzero.
This is in no way full or complete Dwarf 4 support, but it is enough to get
LUL working again with Clang 5 compiled code.
--HG--
extra : rebase_source : f4e21ae5b8d0f219a360d14cc242b2aa812056a0
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
This is a minor cleanup around finding and importing subcommand parser in |mach try|.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 6b05b6f3fafed607992b9427225fd43165c4102f
For regular builds, we build the mar from an unpackaged exe on windows.
For repacks, we just built that from our l10n-stage directory,
don't unpack again.
MozReview-Commit-ID: 8gQ9G23RgzB
--HG--
extra : rebase_source : b3eb944a0cf423a4b0e22d8884fc90780a3bb109
extra : source : 84091f931dff9e1253b0cfa96b4197255a94ddb2
The args passed in from the git pre-push hook aren't necessarily a valid ref,
so can result in failure. By default, the git implementation should be smart
enough to automatically determine which ref to compare against, so passing this
in from the hook shouldn't be necessary.
MozReview-Commit-ID: ESMQqbeGOHd
--HG--
extra : rebase_source : 3c363b6c531f278d7c5b3ddf41fb0f16e79966dc
This is intended to help with ensuring that developer's profiles cleanup and upgrade correctly, as we've seen issues in the past.
MozReview-Commit-ID: CqCRDN0y64I
--HG--
extra : rebase_source : a4668cd40bfaf1dc031e02713de78767305d4728
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : b885ee784704819e181430200af5ef762e269d14
This allows rebuilding all selected tasks. This defines an upper limit of
20 rebuilds per push. If more are needed, developers can either change it
in code or push multiple times.
MozReview-Commit-ID: I0XtMP5yEEq
--HG--
extra : rebase_source : 2583bed5dd33df72a4d7f1cd0ce012e412418c5e
The code in |mach test| for test resolving, should get merged with the TestResolver
class in moztest.resolve. This way it can be shared with other modules and we'll
have a single canonical place for all our test resolving logic.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 6f96d06412ab8fa152ac5d9bdd15acbcdc9695c4
The TestMetadata and TestResolver classes aren't technically part of the build
system. The only connection is that they consume some build system output.
The next patch in this series is going to be merging in a bunch of other test
resolving logic from other parts of the tree. Moving this out first allows us
to keep that extra logic out of mozbuild.
MozReview-Commit-ID: 1eq4SjFVCyW
--HG--
rename : python/mozbuild/mozbuild/test/test_testing.py => testing/mozbase/moztest/tests/test_resolve.py
extra : rebase_source : 7ff11f9ec455547533082d20cb5371845f7a4f21
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : fb7af066adfa0491a79fae6282a62b08661553c8
Currently the prompts don't make it clear enough that running fzf will mess with your
shell settings. This means users could install it without realizing, forget and get
confused later on.
Rather than try to address this, it's simpler to always skip the shell extensions as
|mach try fuzzy| doesn't need them anyway. The extensions are useful, but are better
installed via something like |mach bootstrap| which can be tackled in a separate bug.
MozReview-Commit-ID: 2kx7UGO5LJ0
--HG--
extra : rebase_source : 64474626aeab9f2f04f491afc65ca7cadd717296