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

localrepo: extract handling of some special value in __getitem__ The value "tip" should always be accessible, otherwise there is some problematic bug in the lower level. So we can access this outside of the general try/catch. If it fails some wider and actual big is in play. Differential Revision: https://phab.mercurial-scm.org/D7475

localrepo: extract handling of some special value in __getitem__ The value "null" will always be present in a repository. So this lookup should always succeed and do not need to be in the general try/catch. Differential Revision: https://phab.mercurial-scm.org/D7474

localrepo: add some basic comment for block in __getitem__ There are different early processing before getting to the core of the function. We highlight that fact. Differential Revision: https://phab.mercurial-scm.org/D7473

windows: further build fixes for the WiX installer With these fixes in place, the .msi actually builds for me again. Differential Revision: https://phab.mercurial-scm.org/D7509

cleanup: update references to /help/ that should now be /helptext/ I noticed this only because the WiX build was broken after 2e017696181f. I haven't tested this change with WiX, but it seems pretty obvious by inspection this should fix it. Differential Revision: https://phab.mercurial-scm.org/D7472

merge with stable

tests: byteify a few more things in simplestorerepo.py Differential Revision: https://phab.mercurial-scm.org/D7471

profiling: add a missing argument to the ProgrammingError constructor Differential Revision: https://phab.mercurial-scm.org/D7470

profiling: disable the import-error warning for the flamegraph module The module being missing is properly handled, but pytype was complaining. Differential Revision: https://phab.mercurial-scm.org/D7469

phases: make `allphases` a list on py3 also Pytype complained that `range` doesn't support slicing, so make this a list like it was on py2. Differential Revision: https://phab.mercurial-scm.org/D7468

wireprotov1server: capture Abort type before accessing the `hint` attribute Although the previous code worked, pytypes complained because `exc` is caught above as `BundleValueError, Abort, PushRaced`, and the other two don't have this attribute. Differential Revision: https://phab.mercurial-scm.org/D7463

tests: add more tests for "hg shelve --delete" It appears that the only tests for "hg shelve --delete" concern command errors (e.g. incompatible command options). Adding some more to check that non-existent names are handled and a success case. Differential Revision: https://phab.mercurial-scm.org/D7460

scmutil: add assertions to help pytype Differential Revision: https://phab.mercurial-scm.org/D7456

revset: add an assertion to help pytype Differential Revision: https://phab.mercurial-scm.org/D7455

import: add a --secret option Similarly to "hg commit", we add a --secret option to "hg import" for committing with the secret phase. The option has no short form since there already is a "-s" for "--similarity". .. feature:: ``hg import`` has a new --secret option for committing with the secret phase.

hgweb: add diffs to the json changeset template While it's possible to get the diff for each file individually via an obscure url that I'm not even sure is documented, (e.g. diff/{rev}/{filename}?style=json ), it is more convenient to provide the full diff from the changeset view. This is already normally computed for other non-JSON templates, so it seems like an oversight to omit it for the JSON one. The output format is a bit unwieldy but it's consistent with the existing format output by the aforementioned obscure url.

hgweb: add files to the json changeset template As far as I can tell, it's currently impossible via JSON to figure out what files are touched by a particular revision. Reusing the filenodelink and filenolink templates from the other hgweb templates should provide this information.

hgweb: add a status property to file list context The web templates merely indicate if files touched by this revision are in the commit or not, i.e. if they are removed. It would be helpful to have more context and also indicate whether the files are added, modified, or removed.

match: remove explicitdir attribute No one sets it or reads it anymore. Differential Revision: https://phab.mercurial-scm.org/D7441

dirstate: stop caring about match.explicitdir No one passes it in anymore. Differential Revision: https://phab.mercurial-scm.org/D7440

dirstate: include explicit matches in match.traversedir calls The caller should not have to register to get both explicit and non-explicit matches. Differential Revision: https://phab.mercurial-scm.org/D7439

commit: drop unused "vdirs" argument from repo.checkcommitpatterns() Differential Revision: https://phab.mercurial-scm.org/D7438

commit: rewrite check for `hg ci <path>` being a directory The matcher API is complicated by match.bad, match.explicitdir, and match.traversedir. We already have very few users of match.explicitdir. By rewriting this check we get close to being able to remove match.explicitdir. This may make the check slower, but I think that will be very marginal. Disclosure: I actually wrote this patch to solve a bug we've seen with an internal extension. The internal extension overrides the dirstate walk to only walk the files that our FUSE tells us are modified. That led to "vdirs" not getting populated as this code expected. I have wanted to get rid of match.explicitdir for a very long time, though. Differential Revision: https://phab.mercurial-scm.org/D7437

lock: fix race in lock-breaking code With low frequency, I see hg pulls fail with output like: abort: no such file or directory: .hg/store/lock I think what happens is, in lock.py, in: def _testlock(self, locker): if not self._lockshouldbebroken(locker): return locker # if locker dead, break lock. must do this with another lock # held, or can race and break valid lock. try: with lock(self.vfs, self.f + b'.break', timeout=0): self.vfs.unlink(self.f) except error.LockError: return locker if a lock is breakable on disk, and two hg processes concurrently get to the "if locker dead" comment, a possible interleaving is: process1 finishes executing the function and then process2 finishes executing the function. If that happens, process2 will either get ENOENT in self.vfs.unlink (resulting in the spurious failure above), or break a valid lock and potentially cause repository corruption. The fix is simple enough: make sure the lock is breakable _inside_ the critical section, because only then can we know that no other process can invalidate our knowledge on the lock on disk. I don't think there are tests for this. I've tested this manually with: diff --git a/mercurial/lock.py b/mercurial/lock.py --- a/mercurial/lock.py +++ b/mercurial/lock.py @@ -351,6 +351,8 @@ class lock(object): if not self._lockshouldbebroken(locker): return locker + import random + time.sleep(1. + random.random()) # if locker dead, break lock. must do this with another lock # held, or can race and break valid lock. try: @@ -358,6 +360,7 @@ class lock(object): self.vfs.unlink(self.f) except error.LockError: return locker + time.sleep(1) def testlock(self): """return id of locker if lock is valid, else None. and I see this change of behavior before/after this commit: $ $hg init repo $ cd repo $ ln -s $HOSTNAME/effffffc:987654321 .hg/wlock $ touch a $ $hg commit -Am_ & $hg commit -Am _; wait -abort: No such file or directory: '/tmp/repo/.hg/wlock' adding a +warning: ignoring unknown working parent 679a8959a8ca! +nothing changed Differential Revision: https://phab.mercurial-scm.org/D7199

lock: refactor in preparation for next commit Differential Revision: https://phab.mercurial-scm.org/D7198

extensions: suppress a pytype failure due to a typeshed bug Bug filed upstream, suppress the failure here so we can move on. Differential Revision: https://phab.mercurial-scm.org/D7410

dispatch: add some assertions to give pytype a helping hand Differential Revision: https://phab.mercurial-scm.org/D7409

extensions: hide two confusing import statements from pytype Differential Revision: https://phab.mercurial-scm.org/D7408

debugcommands: add assertions to convince pytype peer is not None This function is moderately annoyingly defined, and peer is set up iff we're not in raw-proto mode. That's fine, but it confuses pytype. Adding these assertions is a low-overhead way to convince pytype we're doing reasonable things. Differential Revision: https://phab.mercurial-scm.org/D7407

debugcommands: suppress import errors for pytype Differential Revision: https://phab.mercurial-scm.org/D7385

state: add a pytype annotation Differential Revision: https://phab.mercurial-scm.org/D7383

logcmdutil: add a type annotation This wasn't actually required in the end, as there was a real bug found by pytype, but the annotation helped me figure that out. We can drop this patch if that's the preference. Differential Revision: https://phab.mercurial-scm.org/D7382

cmdutil: add a pytype annotation to help out some callsites I think we could constrain the values here more than Any, but this lets us move forward with typechecking commands.py. Differential Revision: https://phab.mercurial-scm.org/D7381

hghave: add a check for the `xz` compression utility This isn't install by default on Mac, which causes a test failure. The logic for avoiding the command is a little goofy, but nested `#if` isn't supported, and it still seems worth running the hg command to see if anything explodes. With this, the py3 tests run (almost) cleanly on 10.14.6: # Ran 835 tests, 58 skipped, 1 failed. Alas, the mac-packaging test is skipped because it's slow. The failure here is in test-releasenotes-merging.t, complaining about not being able to import the `fuzzywuzzy` module. I have it installed on py3 (thus the test isn't skipped), but not on py2. So there must be some unintended cross pollination here when running `hg` commands. Differential Revision: https://phab.mercurial-scm.org/D7374

py3: use '%d' for formatting a revnum in `hg co --date` code Differential Revision: https://phab.mercurial-scm.org/D7429

py3: send bytes from Rust-created warning patterns Python code expects bytes in both Python 2 and Python 3, so we should send bytes. Differential Revision: https://phab.mercurial-scm.org/D7454

py3: pass bytes to `configint` and `configbool` Both functions require bytes, even in Python 3. Differential Revision: https://phab.mercurial-scm.org/D7453

templates: make {indent("", " ")} be empty indent() is documented to indent all non-empty lines, but it made an exception for the first line, which always got indented. I also made indent() not indent the first line even if an indent override was given for the first line. I think that is what one would usually want. Differential Revision: https://phab.mercurial-scm.org/D7432

tests: document behavior of indent() with empty first line indent() is documented to indent all non-empty lines, but it still indents the first line even if it's empty. Let's have tests for that. Differential Revision: https://phab.mercurial-scm.org/D7431

tests: check for Windows line endings We shouldn't generally be using Windows line endings in files under version control. I've accidentally committed a few files with Windows line endings recently. So let's add a test for this. Differential Revision: https://phab.mercurial-scm.org/D7448

tests: verify that Python scripts are blackened Scripts are Python too. They should be blackened. (As suggested by Pierre-Yves in D7420.) Differential Revision: https://phab.mercurial-scm.org/D7447

black: blacken scripts These scripts weren't blackened. I found these as part of adding script checking to test-check-format.t. # skip-blame black Differential Revision: https://phab.mercurial-scm.org/D7446

doc: don't use mutable default arguments It appears our mutable default arguments checker doesn't find arguments not on the first line of a function definition :( The arguments aren't used, so the default value is irrelevant. I found this when blackening this script in a future commit. Differential Revision: https://phab.mercurial-scm.org/D7445

tags: don't check for clean files when checking for dirty working copy We didn't request status for clean files so there should never be any entries in the list of clean files (at least not since dd773340a085), but it's misleading to check the list. Differential Revision: https://phab.mercurial-scm.org/D7428

branchmap: make "closed" a set from beginning instead of converting from list Differential Revision: https://phab.mercurial-scm.org/D7427

debugextensions: gracefully handle missing __file__ attributes This was crashing PyOxidizer. Differential Revision: https://phab.mercurial-scm.org/D7452

debuginstall: gracefully handle missing __file__ attributes This was crashing PyOxidizer. While here, point "Python lib" and "installed modules" to the oxidized binary when read from memory instead of pretending their location is unknown. Differential Revision: https://phab.mercurial-scm.org/D7451

typing: add pseudo localstr.__init__() to help pytype Apparently, pytype failed to parse localstr.__new__()? This fixes the following errors: line 126, in __hash__: No attribute '_utf8' on localstr [attribute-error] line 188, in tolocal: Function localstr.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, string: str, ...) Actually passed: (self, string: bytes, ...)

typing: fix argument type of encoding.localstr() It takes both utf-8 and local strings in bytes type.

typing: suppress error of py2 encoding.strtolocal() and .strfromlocal() I don't know how to conditionally get rid of these py2/py3 overloads from .pyi file. Instead, this patch makes pytype ignore the false-positives: line 271, in strtolocal: bad option in return type [bad-return-type] Expected: bytes Actually returned: str

typing: constrain argument/return types of encoding.toutf8b()

typing: fix argument type of encoding.tolocal() and .fromutf8b() Fixes various pytype errors.

typing: fix forward reference in _Tlocalstr type bound AFAIK, a quoted string in type position is translated to its ForwardRef. https://github.com/python/typing/issues/34 This fixes the following error: File "mercurial/encoding.py", line 38, in <module>: Name 'localstr' is not defined [name-error]

encoding: make getcols() raise exception explicitly This helps pytype. File "mercurial/encoding.py", line 329, in getcols: bad option in return type [bad-return-type] Expected: bytes Actually returned: None

setup: conditionalize access to `sys.dllhandle` when building extensions This code is only run on Windows, and was crashing PyOxidizer when running in `setup-py-install` mode. Now an oxidized binary can be built by simply pointing to setup.py. Something is slightly different now that it's not being built from a virtualenv. Previously, `hg version` could print to the screen, but now it aborts saying "Incorrect function". But I can see the output if redirected to a file, and it's not complaining about missing C extensions, so I think those are loading now (unlike from the virtualenv). The interesting this about this incorrect function output is that it failed when initially built. I then went back and did a `make clean` and `make local` with py3 and then py2 to ensure I didn't break the existing code. At that point I ran the oxidized executable again and it was able to print to the screen normally! So I ran `pyoxidizer build` again, it only output the following, and then running the executable failed to output again: (pyO2_venv) C:\Users\Matt\hg3\hg_pyO2>pyoxidizer build Finished dev [unoptimized + debuginfo] target(s) in 0.12s packaging application into C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug purging C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug copying C:/Users/Matt/hg3/hg_pyO2\build\target\x86_64-pc-windows-msvc\debug\hg_pyO2.exe to C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug\hg_pyO2.exe resolving packaging state... writing license for [...] hg_pyO2 packaged into C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug executable path: C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug\hg_pyO2.exe Differential Revision: https://phab.mercurial-scm.org/D7444

setup: use bytes for assumed python version Caught by PyOxidizer when hacking on Windows. # skip-blame for b'' prefixing Differential Revision: https://phab.mercurial-scm.org/D7443

setup: combine two contiguous string literals Differential Revision: https://phab.mercurial-scm.org/D7442

util: remove datapath and swith users over to resourceutil The util module no longer needs the datapath for injecting it into the i18n module, so we can remove it from there and update other users. Differential Revision: https://phab.mercurial-scm.org/D7436

i18n: get datapath directly from resourceutil The new resourceutil module is lower in the dependency graph, so we can depend directly on it and won't have to depend on the util module to inject the datapath. Differential Revision: https://phab.mercurial-scm.org/D7435

util: move definition of datapath to resourceutil Since this means moving the function into a subdirectory, we have to compensate by adding another layer of os.path.dirname(). Differential Revision: https://phab.mercurial-scm.org/D7434

procutil: move mainfrozen() to new resourceutil.py The i18n module practically depends on procutil for mainfrozen() but since procutil depends on i18n, it would be a circular dependency if i18n depended directly on procutil. The cycle is currently resolved by having the higher-level util module calculate the "datapath" and inject it into i18n. Extracting mainfrozen() to a new module lets us clean up the dependencies. Differential Revision: https://phab.mercurial-scm.org/D7433

defaults: rename default.d to defaultrc to make it a valid package name "default.d" is not a valid Python package name, and it needs to be a valid package name if we want to be able to load the files from here as resources. Differential Revision: https://phab.mercurial-scm.org/D7426

help: remove references to default.d/ from user-facing docs The user doesn't need to know what we call the internal directory and I'm about to rename it. Differential Revision: https://phab.mercurial-scm.org/D7425

bisect: replace try:/finally: by a "restore_state" context manager This should help pytype to not consider "bgood" variable as NameError. See https://phab.mercurial-scm.org/D7384 for context. Differential Revision: https://phab.mercurial-scm.org/D7430

histedit: render a rolled up description using the proper roll colours Users have rightfully complained that the old behaviour of completely removing the description of a rolled commit makes it difficult to remember what was in that commit. Instead, we now render the removed description in red. I couldn't think of a simpler way to do this. You can't just combine existing curses colours into new effects; only secondary effects like bold or underline can be logically OR'ed to generate a combined text effect. It seems easier to just redundantly keep track of what the roll colour should be.

histedit: define new colour pairs for roll action Red seems like a good colour to indicate removal, since that's the colour we use in diffs. We need three varieties with three different backgrounds corresponding to the possible ways we can display a rule.

histeditrule: split __bytes__ property into prefix and desc In order to be able to colourise the description of the rule, we need to have it as a separate bytestring. Curses doesn't make it easy to take existing text on the screen and give it different properties; we can only add new text with new properties.

merge with stable

packaging: convert to UNIX line endings I must have my editor on Windows configured incorrectly because I submitted patches with Windows line endings :( # skip-blame whitespace only line ending changes Differential Revision: https://phab.mercurial-scm.org/D7421

black: blacken scripts test-check-format.t doesn't appear to detect Python scripts with shebangs. But my editor which is configured to auto run black on Python files does and it appears some files are not blackened. This commit blackens scripts that need it. # skip-blame reformatting Differential Revision: https://phab.mercurial-scm.org/D7420

dirs: resolve fuzzer OOM situation by disallowing deep directory hierarchies It seems like 2048 directories ought to be enough for any reasonable use of Mercurial? A previous version of this patch scanned for slashes before any allocations occurred. That approach is slower than this in the happy path, but much faster than this in the case that too many slashes are encountered. We may want to revisit it in the future using memchr() so it'll be well-optimized by the libc we're using. .. bc: Mercurial will now defend against OOMs by refusing to operate on paths with 2048 or more components. This means that _extremely_ deep path hierarchies will be rejected, but we anticipate nobody is using hierarchies this deep. Differential Revision: https://phab.mercurial-scm.org/D7411

py3: use native string for 'macosx_app' I couldn't find any definitive information on this, but all examples (except for ours) seem to use a native string. Differential Revision: https://phab.mercurial-scm.org/D7414

py3: drop an unnecessary fsencode() before comparing with constant Differential Revision: https://phab.mercurial-scm.org/D7413

py3: use native string as fallback value for __file__ for consistency This is not a bugfix (pycommpat.fsencode(b'') is a no-op on py3), but the b'' value was inconsistent and confusing. Differential Revision: https://phab.mercurial-scm.org/D7412

scmutil: convert status data object from a tuple to an attrs (API) We've been pushing towards the property names for a while, and the subclassing of the tuple confuses pytype. Rather than bend over backwards to try and annotate the tuple subclass, let's just use attrs here. Differential Revision: https://phab.mercurial-scm.org/D7406

perf: bool() elements of dirstate.status return instead of len() I'm about to make scmutil.status no longer have a len(), so we need to do something else to "use" the results in this perf method. Differential Revision: https://phab.mercurial-scm.org/D7405

tags: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7404

subrepo: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7403

revset: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7402

patch: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7401

logcmdutil: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7400

context: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7399

commands: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7398

cmdutil: convert terse status result back to an scmutil.status This is also part of detupling scmutil.status. Differential Revision: https://phab.mercurial-scm.org/D7397

cmdutil: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7396

uncommit: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7395

transplant: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7394

split: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7393

mq: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7392

hgk: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7391

extdiff: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7390

encoding: fix bad type annotation This function returns utf-8 in a bytes, not a unicode. Differential Revision: https://phab.mercurial-scm.org/D7379

branchmap: annotate constructor type for branchcache This type signature is...big. But it's correct as far as I can tell, and it detected a bug. Differential Revision: https://phab.mercurial-scm.org/D7389

debugcommands: don't shadow the error module Caught by pytype. Differential Revision: https://phab.mercurial-scm.org/D7378

branchmap: correctly set()-ify list argument Caught with pytype. I'm more than a little curious how this never caused problems. Differential Revision: https://phab.mercurial-scm.org/D7289

utils: move finddirs() to pathutil This is a follow-up to c21aca51b392 (utils: move the `dirs` definition in pathutil (API), 2019-11-06). finddirs() is closely related to dirs and used by it. Differential Revision: https://phab.mercurial-scm.org/D7388

help: create packages for the help text These files need to be loaded as resources with PyOxidizer, instead of using filesystem representations. AFAICT, the resource loading mechanisms only work for the named package given to it, and can't reach into a subdirectory. While here, the `help` directory is renamed to `helptext`. Without this, trying to load external help text crashed in mercurial/help.py when importing `.i18n`, saying there's no `mercurial.help.i18n` module. Differential Revision: https://phab.mercurial-scm.org/D7376

tests: test "hg log" with --line-range and --copies This now works (does not crash), due to previous changeset. Since --line-range implies --follow, --copies option is redundant.

logcmdutil: let getlinerangerevs() return "revs" as a smartset This makes it consistent in "hg log" command where 'revs' can come from logcmdutil.getrevs() as a smartset or from getlinerangerevs(), previously as a list. This will help type hinting as noticed in https://phab.mercurial-scm.org/D7377.

patchbomb: fix wrong argument type when calling mail generator.flatten()

mail: move strtolocal call in _addressencode()

mail: use a native string for "subtype" value This is somehow similar to previous changeset and avoids one str conversion.

mail: let all charset values be native strings Charset values will typically be used to build email.header.Header instances, which takes str (though it tolerates bytes) or passed to decode()/encode() methods of string values (which want str). It seems that using native str involves less conversions than before and this also helps type hinting (as illustrates removal of pytype disabling instructions).

mail: add type hints for pytype We essentially annotate functions in which handling of bytes/str is not obvious in order to hopefully clear things out. See also changeset 2ade00f3b03b introducing typing hints in Mercurial. Most types are straightforward but a few is wrong, and we need to either disable pytype on respective instructions or use wrong annotations. These will be fixed in next changesets. Notice the type Union[bytes, str] of "s" parameter of headencode(), this reflects how email.header.Header.append() behaves.

mail: fix a bad return type in _encode() This particular instruction returned only a string and omitted the charset value.

packaging: stage files and dynamically generate WiX installer Like we did for Inno, we want to make the WiX installer "dumb" and simply consume source files from a directory tree rather than have to define every single file in installer files. This will greatly decrease the amount of effort required to maintain the WiX installer since we don't have to think that much about keeping files in sync. This commit changes the WiX packager to populate a staging directory as part of packaging. After it does so, it scans that directory and dynamically generates WiX XML defining the content within. The IDs and GUIDs being generated are deterministic. So, upgrades should work as expected in Windows Installer land. (WiX has a "heat" tool that can generate XML by walking the filesystem but it doesn't have this deterministic property, sadly.) As part of this change, GUIDs are now effectively reset. So the next upgrade should be a complete wipe and replace. This could potentially cause issues. But in my local testing, I was able to upgrade an existing 5.1.2 install without issue. Compared to the previous commit, the installed files differ in the following: * A ReleaseNotes.txt file is now included * A hgrc.d/editor.rc file is now generated (mercurial.rc has been updated to reflect this logical change to the content source) * All files are marked as read-only. Previously, only a subset of files were. This should help prevent unwanted tampering. Although we may want to consider use cases like modifying template files... This change also means that Inno and WiX are now using very similar code for managing the install layout. This means that on disk both packages are nearly identical. The differences in install layout are as follows: * Inno has a Copying.txt vs a COPYING.rtf for WiX. (The WiX installer wants to use RTF.) * Inno has a Mercurial.url file that is an internet shortcut to www.mercurial-scm.org. (This could potentially be removed.) * Inno includes msvc[mpr]90.dll files and WiX does not. (WiX installs the MSVC runtime via merge modules.) * Inno includes unins000.{dat,exe} files. (WiX's state is managed by Windows Installer, which places things elsewhere.) Because file lists are dynamically generated now, the test ensuring things remain in sync has been deleted. Good riddance. While this is a huge step towards unifying the Windows installers, there's still some improvements that can be made. But I think it is worth celebrating the milestone of getting both Inno and WiX to essentially share core packaging code and workflows. That should make it much easier to change the installers going forward. This will aid support of Python 3. Differential Revision: https://phab.mercurial-scm.org/D7173

tests: add optional output when wheel is missing If the `wheel` package isn't installed, pip will emit a warning on stderr complaining about that. Alternatively, we could redirect stderr to stdout and swallow the warning. But I like tests having visibility of warnings, as it helps keep us honest regarding edge cases. Differential Revision: https://phab.mercurial-scm.org/D7371

py3: replace "%r" by"'%s'% for py3-compatible (and clearer) quoting in chg Differential Revision: https://phab.mercurial-scm.org/D7375

dirstate: respect request to not list unknown/ignored/clean files (API) Unknown files that are explicitly mentioned by the matcher are returned even if the caller said unknown=False (and it seems the same is done for ignored files). That seems pretty surprising. Let's make the interface less surprising by respecting the caller's request. Differential Revision: https://phab.mercurial-scm.org/D7150

py3: pass a bytes value for "msg" to nouideprecwarn() That function formats "msg" with the "version" value. On Python 3, this leads to "TypeError: can only concatenate str (not "bytes") to str". Also eliminate spurious strings concatenation in single-line declarations. Differential Revision: https://phab.mercurial-scm.org/D7373