Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 12 Jun 2019 13:10:52 -0400] rev 42471
worker: support parallelization of functions with return values
Currently worker supports running functions that return a progress
iterator. Generalize it to handle function that return a progress
iterator then a return value.
It's unused in this commit, but will be used in the next one.
Differential Revision: https://phab.mercurial-scm.org/D6515
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 19 May 2019 16:06:06 -0400] rev 42470
tests: show how the dirstate can end up containing wrong information
which can result in bad status output.
Concretely, this seems to be easily triggered by having a build system
watching the filesystem for changes, and rebuilding files that are
both tracked and generated while an update is happening.
Differential Revision: https://phab.mercurial-scm.org/D6474
Georges Racinet <georges.racinet@octobus.net> [Thu, 23 May 2019 02:05:32 +0200] rev 42469
rust: new rust options in setup.py
The --rust global option turns on usage (and by default compilation)
of the rust-cpython based mercurial.rustext.
Similarly to what's previously done for zstd, there is a --no-rust
option for the build_ext subcommand in order not to build
mercurial.rustext, allowing for an OS distribution to prebuild it.
The HGWITHRUSTEXT environment variable is still honored, and has
the same effect as before, but now it works mostly by making
the --rust global option defaulting to True, with some special
cases for the direct-ffi case (see more about that below)
Coincidentally, the --rust flag can also be passed from the make
commands, like actually all global options, in the PURE variable
make local PURE=--rust
This feels inappropriate, though, and we should follow up with
a proper make variable for that case.
Although the direct-ffi bindings aren't directly useful any more, we
keep them at this stage because
- they provide a short prototyping path for experiments in which a C extension
module has to call into a Rust extension. The proper way of doing that would
be to use capsules, and it's best to wait for our pull request onto
rust-cpython for that: https://github.com/dgrunwald/rust-cpython/pull/169
- Build support for capsules defined in Rust will probably need to reuse
some of what's currently in use for direct-ffi.
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 May 2019 09:14:41 +0200] rev 42468
rust: using policy.importrust from Python callers
This commit converts all current Python callers of
mercurial.rustext to the new policy.importrust system.
After this point, going through policy.importrust
or policy.importmod (in some more distant future)
is mandatory for callers of Rust code outside of
Python tests.
We felt it to be appropriate to keep Rust-specific tests
run inconditionally if the Rust extensions are present.
Georges Racinet <georges.racinet@octobus.net> [Wed, 29 May 2019 13:27:56 +0200] rev 42467
rust: module policy with importrust
We introduce two rust+c module policies and a new
`policy.importrust()` that makes use of them.
This simple approach provides runtime switching of
implementations, which is crucial for the performance
measurements such as those Octobus does with ASV.
It can also be useful for bug analysis.
It also has the advantage of making conditionals in
Rust callers more uniform, in particular
abstracting over specifics like `demandimport`
At this point, the build stays unchanged, with the rust-cpython based
`rustext` module being built if HGWITHRUSTEXT=cpython.
More transparency for the callers, i.e., just using
`policy.importmod` would be a much longer term and riskier
effort for the following reasons:
1. It would require to define common module boundaries
for the three or four cases (pure, c, rust+ext, cffi) and that
is premature with the Rust extension currently under heavy
development in areas that are outside the scope of the C extensions.
2. It would imply internal API changes that are not currently wished,
as the case of ancestors demonstrates.
3. The lack of data or property-like attributes (tp_member
and tp_getset) in current `rust-cpython` makes it impossible to
achieve direct transparent replacement of pure Python classes by
Rust extension code, meaning that the caller sometimes has to be able
to make adjustments or provide additional wrapping.
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 13 Jun 2019 23:28:31 +0300] rev 42466
help: add help entry for internals.mergestate
This patch adds an entry for `internals.mergestate` as suggested
by @marmoute. Most of the help text is taken from `merge.mergestate`.
Differential Revision: https://phab.mercurial-scm.org/D6448
Differential Revision: https://phab.mercurial-scm.org/D6528
Ian Moody <moz-ian@perix.co.uk> [Wed, 12 Jun 2019 17:22:37 +0100] rev 42465
phabricator: use parents.set to always set dependencies
Now that Mercurial's Phabricator instance has been updated to a version that
supports the parents.set transaction on revision.edit we can use that to set
dependency relationships in patch stacks instead of abusing the summary.
This has the advantage that we can use it on every `phabsend` so commit
reordering is picked up without spamming changes like abusing the summary would,
and using parents.set will clear previous parents unlike parents.add.
Differential Revision: https://phab.mercurial-scm.org/D6514
amalloy [Fri, 31 May 2019 10:12:56 -0700] rev 42464
help: remove repeated word in 'hg help rebase'
Specifically, the second 'with' in 'with which to merge with'.
Differential Revision: https://phab.mercurial-scm.org/D6483
Kyle Lippincott <spectral@google.com> [Mon, 10 Jun 2019 15:35:06 -0700] rev 42463
rebase: tweak description of inmemory working even w/ dirty working dir
One of our users was confused because they read this, and then attempted to run
`hg rebase` with a dirty working directory, and it still complained. The reason
was that they were attempting to rebase the commit they currently had checked
out, which (at least with evolve workflows enabled) involves updating the
working directory to be based on the newly rebased commit.
Differential Revision: https://phab.mercurial-scm.org/D6507
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 10 Jun 2019 13:23:14 -0400] rev 42462
revlog: speed up isancestor
Currently, it is implemented on top of commonancestorsheads.
Implement it on top of reachableroots instead, as reachableroots could
stop walking the graph much sooner than commonancestorsheads.
Measuring repo.changelog.isancestorrev on two revisions in a private repository:
before: ! wall 0.005175 comb 0.010000 user 0.010000 sys 0.000000 (best of 550)
after : ! wall 0.000072 comb 0.000000 user 0.000000 sys 0.000000 (best of 36199)
When hg does this kind of operations 1500 times in pull ->
bookmarks.comparebookmarks -> bookmarks.validdest, that's 11s that
drop from the --profile output.
Differential Revision: https://phab.mercurial-scm.org/D6506
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 10 Jun 2019 11:40:43 -0400] rev 42461
dagop: fix documentation of reachableroots
The previous revset couldn't be correct as it is symmetric in <roots>
and <heads>, but reachableroots has no such symmetry. It makes a
difference with for instance reachableroots(2, 3) where 2 and 3 are
both children of 1.
Differential Revision: https://phab.mercurial-scm.org/D6505
Ian Moody <moz-ian@perix.co.uk> [Tue, 11 Jun 2019 19:52:16 +0100] rev 42460
phabricator: add --blocker argument to phabsend to specify blocking reviewers
The way to signal to Conduit that a reviewer is considered blocking is just to
wrap their PHID in "blocking()" when including it in the list of PHIDs passed
to `reviewers.add`.
arc doesn't have a --blocker, instead one is supposed to append a '!' to the
end of reviewer names (I think reviewers are usually added in an editor rather
than the command line, where '!'s can be more hazardous).
moz-phab (Mozilla's arcanist wrapper) does have a --blocker argument, and being
explicit like this is also more discoverable. Even `arc diff`'s help doesn't
seem to mention the reviewer! syntax.
Differential Revision: https://phab.mercurial-scm.org/D6512
Ian Moody <moz-ian@perix.co.uk> [Tue, 11 Jun 2019 19:37:19 +0100] rev 42459
phabricator: auto-sanitise API tokens and HTTP cookies from VCR recordings
Currently when making VCR recordings one needs to manually sanitise sensitive
credentials before committing and submitting them as part of tests. It is easy
to imagine this being accidentally missed one time by a fallible human and said
credentials being leaked. It is also possible that it wouldn't be noticed to
alert the user to the leak since the recording files are so large and
practically unreviewable. Thus do so automatically, so the only place that needs
checking is in the test-phabricator.t file.
Differential Revision: https://phab.mercurial-scm.org/D6513
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 11 Jun 2019 15:46:07 +0300] rev 42458
py3: use .startswith() instead of bytes[0]
Doing bytes[0] will return the ascii value of that position which breaks
comparison with a bytechar.
This makes test-absorb.t work again on py3.
Differential Revision: https://phab.mercurial-scm.org/D6508
Yuya Nishihara <yuya@tcha.org> [Sun, 09 Jun 2019 22:23:41 +0900] rev 42457
revset: fix merge() to fall back to changectx API if wdir specified
I have a code which basically runs "0:wdir() & <user-revset>", and it crashed
if merge() were passed in.
Yuya Nishihara <yuya@tcha.org> [Sun, 09 Jun 2019 22:18:22 +0900] rev 42456
revset: use nullrev constant in merge()