Georges Racinet <georges.racinet@octobus.net> [Thu, 05 Dec 2019 20:41:23 +0100] rev 43847
cext-revlog: fixed __delitem__ for uninitialized nodetree
This is a bug in a code path that's seldom used, because in practice
(at least in the whole test suite), calls to `del index[i:j]` currently
just don't happen before the nodetree has been initialized.
However, in our current work to replace the nodetree by a Rust implementation,
this is of course systematic.
In `index_slice_del()`, if the slice start is smaller than `self->length`,
the whole of `self->added` has to be cleared.
Before this change, the clearing was done only by the call to
`index_invalidate_added(self, 0)`, that happens only for initialized
nodetrees. Hence the removal was effective only from `start` to `self->length`.
The consequence is index corruption, with bogus results in subsequent calls,
and in particular errors such as `ValueError("parent out of range")`, due to
the fact that parents of entries in `self->added` are now just invalid.
This is detected by the rebase tests, under conditions that the nodetree
of revlog.c is never initialized. The provided specific test is more direct.
Differential Revision: https://phab.mercurial-scm.org/D7603
Matt Harbison <matt_harbison@yahoo.com> [Wed, 20 Nov 2019 13:03:22 -0500] rev 43846
filemerge: fix a missing attribute usage
Flagged by both pytype and VSCode.
Differential Revision: https://phab.mercurial-scm.org/D7465
Matt Harbison <matt_harbison@yahoo.com> [Wed, 20 Nov 2019 13:01:56 -0500] rev 43845
filemerge: drop a default argument to appease pytype
The function slices and takes the length of this argument without internally
setting it if not provided. There was no bug here because both callers passed
the argument.
Differential Revision: https://phab.mercurial-scm.org/D7464
Augie Fackler <augie@google.com> [Tue, 10 Dec 2019 19:04:53 -0500] rev 43844
fuzz: add a seed corpus for the dirs fuzzer
I was hoping to trigger an asan violation under Python 3 that some internal
tests at Google found, but for some reason that's beyond me I can't seem to
manage.
Differential Revision: https://phab.mercurial-scm.org/D7600
Augie Fackler <augie@google.com> [Tue, 10 Dec 2019 19:04:08 -0500] rev 43843
fuzz: clean up production of seed corpora
This was getting out of hand.
Differential Revision: https://phab.mercurial-scm.org/D7599
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Mon, 09 Dec 2019 22:06:55 -0800] rev 43842
status: add template/json data about whether a file has unresolved conflicts
Differential Revision: https://phab.mercurial-scm.org/D7594
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Mon, 09 Dec 2019 18:15:38 -0800] rev 43841
status: split morestatus data loading from display
This is a small refactoring in preparation for adding more morestatus
functionality (notably for templated/JSON output) - the goal is to
use the data inside the status display loop, as well as output the
overall state in a templatable/structured way.
Differential Revision: https://phab.mercurial-scm.org/D7593
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 21 Nov 2019 16:54:00 +0100] rev 43840
phabricator: add a "phabstatus" template keyword
We add a "phabstatus" template keyword, returning an object with "url"
and "status" keys. This is quite similar to "phabreview" template
keyword, but it queries phabricator for each specified revision so it's
going to be slow (as compared to the "phabstatus" show view from
previous changeset).
Differential Revision: https://phab.mercurial-scm.org/D7507
Denis Laxalde <denis@laxalde.org> [Sat, 23 Nov 2019 11:04:19 +0100] rev 43839
phabricator: add a "phabstatus" show view
We add a "phabstatus" show view (called as "hg show phabstatus") which
renders a dag with underway revisions associated with a differential
revision and displays their status.
The revisions shown is a subset of that shown by "work" view, only
including revisions with known by Phabricator.
Differential Revision: https://phab.mercurial-scm.org/D7506
Martin von Zweigbergk <martinvonz@google.com> [Tue, 10 Dec 2019 14:40:44 -0800] rev 43838
dirs: fix out-of-bounds access in Py3
The hack for mutating Python's variable-length integers that was
ported to py3 in
cb3048746dae (dirs: port PyInt code to work on Python
3, 2016-10-08) was reading from ob_digit[1] instead of ob_digit[0] for
some reason. Space for ob_digit[1] would only be allocated for
integers larger than 30 bits, so we ended up writing to unallocated
memory. Also, we would write an integer that's 2^30 times too large,
so we would never free these integers.
Found by AddressSanitizer.
Differential Revision: https://phab.mercurial-scm.org/D7597