The wizard has been ported to the version-control-tools repository
and in-tree consumers have been switched to consume it from there. This
code is now dead. Kill it.
References to the now-defunct code have been removed/updated.
MozReview-Commit-ID: 5fpCXdNIp8L
--HG--
extra : rebase_source : 6c1e2363793fe2cd3a506ce5d962788657871203
extra : histedit_source : c40d2203aaa54bbd48e4e2b46178e277dcdc2e3f
This begins the consolidation of `mach mercurial-setup` into
`mach bootstrap`. The first step is to move the content of the
mach_commands.py file into the bootstrapper's.
I'm not crazy about adding the sys.path entry for tools/mercurial.
I intend to clean this up later.
MozReview-Commit-ID: Cq56wPG8sO1
--HG--
extra : rebase_source : 48d6d2631760c9333bf99285673430948085630e
extra : histedit_source : e062f6fbc0ae9678347801b4a1f1c9b6912afd52
I never really liked this. Other people had even more visceral
reactions. Let's get rid of it.
The code for touching a file when it runs has also been removed because
the only thing it was used for was the nagging feature.
MozReview-Commit-ID: ERUVkEYgkzx
--HG--
extra : rebase_source : 1c1ed9c00eb2164d19e4405f2b8becf59680d1ed
extra : histedit_source : 9f2ebc64443140c0bc853ee5a3418f4e0f03db7b
This is a crude workaround to get subdirectory .flake8 files working. Hopefully
this is temporary until flake8 3.0 is released with support for multiple config
files.
Note that .flake8 files that live outside of a directory that is explicitly
listed in the 'include' directive, will not be considered.
MozReview-Commit-ID: GtpUZHJKq52
--HG--
extra : rebase_source : 0294e135673a3b580316a46ec13e37749422edba
Enables flake8 linting! To start, only these directories are actually linted:
- python/mozlint
- tools/lint
To enable new directories, add them to the 'include' directive at the bottom of:
tools/lint/flake8.lint
Edit topsrcdir/.flake8 to modify global configuration. Add a new .flake8 to a
subdirectory to override the global. The current configuration is more or less
just the default and we should tweak it to our needs.
MozReview-Commit-ID: iXbToRhm3b
--HG--
extra : transplant_source : %E7i%04%07%1C%B3%E4%FD%FF%BB%A6w%CF%27t%FFz%CD%5EE
This is a really simple and ugly formatter that is compatible with
treeherder's error highlighting mechanism. It is designed to be identical
to the current eslint output on treeherder:
https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/tools/lint/eslint-formatter.js
Eventually eslint will also use this and we can remove that file. Once
bug 1276486 is fixed, we can make this look a little nicer. But for now
it gets the job done.
MozReview-Commit-ID: CwfWPcwWFxF
--HG--
extra : transplant_source : %F3PJ%CB%27%A5%82U%D2%CF%B3%9E%A7%9F%0F%A4%F4%E9%5D%BB
The hgwatchman project has been renamed to fsmonitor and has been moved
into Mercurial core, as of version 3.8.
Accordingly, for Mercurial >= 3.8, we shall skip installing hgwatchman
but just set fsmonitor in hgrc file instead.
DONTBUILD (NPOTB)
MozReview-Commit-ID: 426rla5riCM
--HG--
extra : rebase_source : 359eb135a2c16361125da6f1fe97eedf9434032e
Enables flake8 linting! To start, only these directories are actually linted:
- python/mozlint
- tools/lint
To enable new directories, add them to the 'include' directive at the bottom of:
tools/lint/flake8.lint
Edit topsrcdir/.flake8 to modify global configuration. Add a new .flake8 to a
subdirectory to override the global. The current configuration is more or less
just the default and we should tweak it to our needs.
MozReview-Commit-ID: iXbToRhm3b
--HG--
extra : rebase_source : 78c4491261ba36421110b0d9fca73c1f6d1f85c3
This is a really simple and ugly formatter that is compatible with
treeherder's error highlighting mechanism. It is designed to be identical
to the current eslint output on treeherder:
https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/tools/lint/eslint-formatter.js
Eventually eslint will also use this and we can remove that file. Once
bug 1276486 is fixed, we can make this look a little nicer. But for now
it gets the job done.
MozReview-Commit-ID: CwfWPcwWFxF
--HG--
extra : rebase_source : 8dd39aefec1064e0836c847c6d223db43df4755b
Our policy is to support the last 4 releases of Mercurial. 3.8 is out.
So we bump the minimum version to 3.5.
MozReview-Commit-ID: 9cftV7CscRL
--HG--
extra : rebase_source : c1875946afc0b8a586d3ec474adece7321812be7
extra : amend_source : 0fa318cd26de3dc0b73033713818f371e43ddd9c
These variables specify a version of Mercurial that is considered
modern and won't trigger giant warnings about being out of date.
We bump to 3.7.3 because 3.7.3 contains security fixes and it is
important for as many users as possible to get these security fixes.
We also update the messaging to indicate security issues with older
releases.
MozReview-Commit-ID: H4utKINrW0V
--HG--
extra : rebase_source : 5247fec94d7df351ef3c7bb2aa60396bb19a6196
extra : amend_source : 70b9aa52cde71d11e2b6d65a1a83567b8a0c7965
MQ isn't recommended for modern Mercurial development. Stop advertising
it.
MozReview-Commit-ID: IOx3A5ZeJnJ
--HG--
extra : rebase_source : a6b49ebdba3fbdb0b0bab13fd59aae3fcdcf167c
This makes the child process write its memory map to a different file
name, just like it does for the jprof log. It tries to share the
variables between the two so that they're both connected in the code and
consistent with each other.
Note that I haven't yet written the patch to make jprof.cpp *read* the
map from that file, so this currently requires manually renaming the
generated map with the numeric suffix to jprof-map in order to run
jprof. I should probably write that patch eventually, but I haven't
actually needed to.
This at least prevents the child process's map file from being
overwritten by the parent's a fraction of a second later.
MozReview-Commit-ID: 7L4wT9BdQYI
Currently a bug in python (https://bugs.python.org/issue8296) is preventing a KeyboardInterrupt from
reaching the parent process, meaning we can't kill the process with SIGINT. There is a workaround to
this bug, but instead I decided to ignore SIGINT in the parent process completely. Now, each child
process is responsible for handling SIGINT on its own. Since child processes should all shutdown
relatively quickly anyway, this effectively also ends the parent process.
The benefit of doing it this way is that each child process can return the results they have collected
to date. So when a developer hits Ctrl-C, they'll still see some (but not all) formatted lint output.
The downside is that a poorly implemented external linter could block the parent process from exiting
quickly, but if this happens we should just fix the linter.
MozReview-Commit-ID: 2tRJgtmoPYP
--HG--
extra : rebase_source : e72282bcc29c9b22690168dc973a817236cdf8ca
For now, only the following two directories will be linted:
python/mozlint
tools/lint
New directories can be added by adding them to the 'include'
directive in tools/lint/flake8.lint. They all default to the
configuration specified in topsrcdir/.flake8. Subdirectories
can override this configuration by creating their own .flake8
file.
MozReview-Commit-ID: Eag48Lnkp3l
--HG--
extra : rebase_source : 6d98c9fef80055a48cc2622848aa04c3045b747e
If the symbols file doesn't give a function name, substitute
'unnamed_function'. A more complete fix would be to catch
all ValueError exceptions and continue sensibly, but this
addresses the immediate issue with the output from `rustc -g`.
MozReview-Commit-ID: 666ruvLlJ5t
operator< for EHTable compares the LHS start PC with the RHS *end* PC.
Because the ranges are non-overlapping, this works fine for two distinct
EHTables. However, the comparison doesn't work if LHS and RHS refer to
the same EHTable; in that case operator< returns true, even though it
should return false because the two operands are identical.
The operator is used to sort a std::vector using std::sort [1]. I think
the libc++ std::sort implementation has a quirk where, if the comparison
function has the above bug, sort will sometimes get confused, and start
sorting "values" outside of the memory range that it's given. This
results in memory corruption and subsequent unpredictable behavior.
The fix is simply to compare only the start PCs in EHTable, so that
std::sort can work on it correctly.
[1] http://mxr.mozilla.org/mozilla-central/source/tools/profiler/core/EHABIStackWalk.cpp?rev=86730d0a8209#485
Per
https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-April/083649.html
the hgwatchman repo has been blanked. We should pin to the last
changeset before the blanking so people can still run hgwatchman.
We'll also need to teach `mach mercurial-setup` to install the
fsnotifier extension. That's for a different patch and bug.
DONTBUILD (NPOTB)
MozReview-Commit-ID: GyuDMTwARqo
--HG--
extra : rebase_source : be782f0262006a29f5b48add98fddda9dd2cdbd7
mozbuild Python changes to test manifest processing introduced these
dependencies.
DONTBUILD (NPOTB)
MozReview-Commit-ID: 9nT3G7qt988
--HG--
extra : rebase_source : d7d560477249a8e20a162d49faea85d4a49fe113
Before, we didn't update host fingerprints if old values were present
and we were running a modern Mercurial and Python.
Now, we unconditionally update existing fingerprints.
DONTBUILD (NPOTB)
MozReview-Commit-ID: 1yjNGkJ6FAk
--HG--
extra : rebase_source : 12a2c6a3615b3ad4449171bcfb6f3c41cda670ed
RTD is complaining that it can't find concurrent.futures. We solve this
problem on RTD by adjusting sys.path in the Sphinx config file to add
paths to the vendored packages.
Sadly, there isn't really an easy way to test this before landing. But
it should work.
MozReview-Commit-ID: FrsLrbbOQWt
--HG--
extra : rebase_source : 4debf9b1902e26babe7e9ddaee8142a14674d393
This patch introduces a small utility program to extract a guid from a shared library
or executable on windows to identify the correct symbol file to read in fix_stack_using_bpsyms.py.
In order for this to work correctly on windows, the library name provided by
MozDescribeCodeAddress needs to be a full path, so the LoadedImageName field
from the IMAGEHLP_MODULE64 structure is used here instead of the ModuleName
field.
MozReview-Commit-ID: 8zkfLWjKVs2