copies: return consistent type from revinfo The return is expected to be a list, so we should return a list. This make the use of this function from type-checked language (eg: rust) much simpler.

dateutil: correct default for Ymd in parsedate The code uses `0` for the default value of Ymd (year, month, and day), which seems suboptimal. For example, these will fail to parse: dateutil.parsedate('2000', formats=dateutil.extendeddateformats) dateutil.parsedate('Jan 2000', formats=dateutil.extendeddateformats) Fix it by providing sane defaults (1 instead of 0) for year, month, and day. The suboptimal behavior was introduced by 91bc001a592 (2010-12-29, "date: fix matching of underspecified date ranges"), which does not seem to justify the current behavior. Note end-users should not notice the subtle issue, because there are no formats in `defaultdateformats` that allow an explicit year with omitted month, or an explicit month with omitted day. Differential Revision: https://phab.mercurial-scm.org/D7520

test-doctest: include dateutil `mercurial.utils.dateutil` has dostrings that contain doctests. Include them. Differential Revision: https://phab.mercurial-scm.org/D7519

revlog: fix revset in reachableroots docstring `reachableroots` will only return a subset of `roots` when `includepath` is False. For example, given the following linear DAG: 2 | 1 | 0 Using roots=0+2, heads=1, the definition in the docstring does not match what `reachableroots` actually does: ipdb> repo.changelog.reachableroots(0, roots=[0,2],heads=[1]) [0] ipdb> repo.revs('heads(::(0+2) & (0+2)::1)') <baseset+ [1]> The fix is to do `heads & ::roots` (or `heads & heads::roots`) first, then select their ancestors: ipdb> repo.revs('heads(::((0+2) & (0+2)::1))') <baseset+ [0]> The docstring was introduced by fd92bfbbe02d9 (2015-06-19 "revset: rename revsbetween to reachableroots and add an argument"), which introduced the `includepath=False` behavior for graphlog grandparents use-case. I believe the docstring instead of the code should be changed because changing the code to match the docstring can result in suboptimal graphlog like: o :\ : o : : :/ o As opposite to the current "linearized" graphlog: o | o : o Differential Revision: https://phab.mercurial-scm.org/D7518

lock: pass "success" boolean to _afterlock callbacks This lets the callback decide if it should actually run or not. I suspect that most callbacks (and hooks) *should not* run in this scenario, but I'm trying to not break any existing behavior. `persistmanifestcache`, however, seems actively dangerous to run: we just encountered an exception and the repo is in an unknown state (hopefully a consistent one due to transactions, but this is not 100% guaranteed), and the data we cache may be based on this unknown state. This was observed by our users since we wrap some of the functions that persistmanifestcache calls and it expects that the repo object is in a certain state that we'd set up earlier. If the user hits ctrl-c before we establish that state, we end up crashing there. I'm going to make that extension resilient to this issue, but figured it might be a common issue and should be handled here as well instead of just working around the issue. Differential Revision: https://phab.mercurial-scm.org/D7459

relnotes: add note about changes to match.{explicit,reverse}dir Differential Revision: https://phab.mercurial-scm.org/D7508

graphlog: change state dict to attr struct This should help static analysis.

status: fix default value of status struct The default argument isn't overloaded. Before, the default constructor would create a struct having 7 list type objects.

typing: fix return type of logcmdutil.getrevs() Fixes the following errors: Invalid type annotation "'Tuple[smartset.BaseSet, changesetdiffer]'" [invalid-annotation] No attribute 'BaseSet' on module 'mercurial.smartset' getrevs: bad option in return type [bad-return-type] Expected: Tuple[mercurial.smartset.abstractsmartset, changesetdiffer] Actually returned: Tuple[mercurial.smartset.baseset, None]

typing: consolidate "if not globals():" trick Removes redundant inline comments. I think pycompat is good place to host this kind of constants.

rust-cpython: do not convert warning pattern to utf-8 bytes On Unix, both Rust Path and Mercurial expect a locale-dependent bytes, and we don't support Windows yet.

rust-cpython: import utils::files::* function at module level IIRC, it's common in Rust to call functions with the module prefix.

exchange: guard against method invocation on `b2caps=None` args I couldn't figure out how these are called, but the value is pretty obviously set at least for the cases that have tests. Differential Revision: https://phab.mercurial-scm.org/D7512

exchange: eliminate some bytes.format() calls Differential Revision: https://phab.mercurial-scm.org/D7511

windows: suppress pytype warnings for Windows imports and functions This should allow the modules to not be excluded, and not generate complaints on non Windows platforms. Differential Revision: https://phab.mercurial-scm.org/D7510

changectx: mark the parents of the working copy as non filtered If we successfully accessed the working copy, its parents are not filtered. Differential Revision: https://phab.mercurial-scm.org/D7491

repoview: add an explicit set of all filter that show the wc parents The `visible` set will always show the working copy parents. We record this in a specific set. This will allow to fast path some access. Differential Revision: https://phab.mercurial-scm.org/D7490

localrepo: introduce a `_quick_access_changeid` property Having faster access to `null` is cute… but limited. We want to speedup access to more useful revision, like `.`. We start with turning the fast path for `null` into something more generic. Differential Revision: https://phab.mercurial-scm.org/D7488

changectx: use unfiltered changelog to access parents of unfiltered revs If a revision is not filtered, we know that its parents are not either. So we can take a shortcut. This shortcut avoid the computation of all filtered revs in some cases. Differential Revision: https://phab.mercurial-scm.org/D7487

locarepo: also fastpath `nullid` lookup in __getitem__ We already use that fastpath for `"null"` and `nullrev`, using it for `nullid` is similar. Differential Revision: https://phab.mercurial-scm.org/D7486

repoview: add more tests to track operation not supposed to trigger filtering This test is useful to confirm we removed filtering trigger and to prevent it to come back without us noticing. The commands tested in the test were initially introduced one by one. However, on Martin von Zweigbergk request, we are adding them all at once. Differential Revision: https://phab.mercurial-scm.org/D7514

localrepo: mark nullrev has never filtered All repository have a null, and it cannot be filtered. Differential Revision: https://phab.mercurial-scm.org/D7484

changectx: add a "maybe filtered" filtered attribute There are changeset that we know not to be filtered (eg: `null`). In this case, we could access some information without triggering changelog filtering. We add an attribute to changectx that track this property. Differential Revision: https://phab.mercurial-scm.org/D7483

repoview: add a test that access actual changeset data of `null` Ideally, we would not trigger filtering here. However some work needs to happens first. Differential Revision: https://phab.mercurial-scm.org/D7482

localrepo: recognize trivial "null" queries in `anyrev` Bypassing the revset logic for trivial "null" queries means we can avoid to trigger the filtering logic in some cases. Differential Revision: https://phab.mercurial-scm.org/D7481

localrepo: also fastpath `nullrev` in __getitem__ As explained earlier, nullrev will exist in all repository, we do not need any special checking. Differential Revision: https://phab.mercurial-scm.org/D7480

repoview: add a test to track operation not supposed to trigger filtering This test will be useful to confirm we removed filtering trigger and to prevent it to come back without us noticing. Differential Revision: https://phab.mercurial-scm.org/D7479

repoview: display stack trace along side the debug message When a filter computation is triggered, If --traceback is provided, we will display a traceback in addition to the debug message. Differential Revision: https://phab.mercurial-scm.org/D7478

util: add an optional `prefix` argument to debugstacktrace This is useful when using it in a specific context. Differential Revision: https://phab.mercurial-scm.org/D7477

repoview: add a 'devel.debug.repo-filter' option If set, there will be debug message when a filter computation is triggered. This is going to be useful to remove various filtering trigger and to test they do not get reintroduced. Differential Revision: https://phab.mercurial-scm.org/D7476