This is a minor cleanup around finding and importing subcommand parser in |mach try|.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 6b05b6f3fafed607992b9427225fd43165c4102f
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
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
Use MOZ_CRASH, MOZ_CRASH_UNSAFE_OOL, or MOZ_CRASH_UNSAFE_PRINTF instead.
MozReview-Commit-ID: 1kCCHMlgbGP
--HG--
extra : rebase_source : 2f07ced16bccebf30cd3b2b5fea35e9868d32dad
extra : source : 0bf2c8425b828e71de55dd175fd0dad635b4e67d
For example, this is addressing the issue:
./mach clang-format -p ./mfbt/
MozReview-Commit-ID: Le8mPTOEfA7
--HG--
extra : rebase_source : ed196a2a86793d6601f590ce04744ebc7f3cd303