exewrapper: avoid directly linking against python3X.dll Subsequent code calls `LoadLibrary()` to attempt to load the DLL, but because of this symbol reference, there is an attempt to load the DLL used during the build prior to `_main()` running. This causes the whole process to fail if the DLL isn't in the standard search path. That also means it will never load the DLL for HackableMercurial. (Maybe we should get rid of that for py3, since you can install python for a user without admin rights?) This could also be resolved by calling `GetProcAddress()` on the symbol and dereferencing it, but using the environment variable is consistent with the *.bat file since fc8a5c9ecee0. (The environment variable persists after the interpreter is initialized.) Far more concerning is somehow I've gotten my system into a state where setting the flag causes any output to the pager to be lost (as if it wasn't set at all) in MSYS, cmd.exe, WSL, and PowerShell using py3.9.0, but the environment variable works properly. I'm sure this flag worked on some versions of py3, so I'm not sure what's going on here. This is might be related to init config related changes in 3.8[1], since it works with 3.7.8, but fails with 3.8.1. Somebody who understands encoding issues better than I do should give some thought to if we need to make some changes to our encoding strategy on Windows with py3. With or without the flag/envvar, there is proper output if the command is directly paged by piping to `more.com` (in any environment) or `less` (in MSYS and WSL), or if paging is disabled with `--pager=no`. Legacy mode is required though when Mercurial decides to spin up a pager. [1] https://bugs.python.org/issue41941 Differential Revision: https://phab.mercurial-scm.org/D10756

tests: partially fix test-transaction-rollback-on-revlog-split.t on Windows For whatever reason, the extra space causes different output on Windows: $ printf '% 20d' '1' | xxd - 0000000: 2020 2020 2020 2020 2020 2020 2020 2020 0000010: 2020 2020 31 1 vs WSL: /mnt/c/Users/Matt/hg/tests$ printf '% 20d' '1' | xxd - 00000000: 2020 2020 2020 2020 2020 2020 2020 2020 00000010: 2020 2031 Without the space, they both agree the last word is 2031. There are other failures on Windows that I don't understand that are introduced by 46b828b85eb7 and 18415fc918a1. Differential Revision: https://phab.mercurial-scm.org/D10763

tests: fix test-transaction-safety.t on Windows Mostly this is about `C:\dir\sub` style paths being turned into `C:dirsub` by MSYS, and not being about to execute shell scripts in hooks directly. See also a12819559ccb::9e3979a25bfe. Differential Revision: https://phab.mercurial-scm.org/D10762

docket: move the uid logic in the `revlogutils.docket` module We want to use it for revlog-v2 (& Co), it seems more logical to have the logic lives inside the `docket` file than the `nodemap` file. Differential Revision: https://phab.mercurial-scm.org/D10755

persistent-nodemap: use the intended uuid size I overlooked this in the initial implementation. The format already supporting any uuid size so, nothing horrible should happens. Differential Revision: https://phab.mercurial-scm.org/D10754

persistent-nodemap: add a way to make the picked uid predictable This will make the test less volatile and therefore easier to maintain. I am setting this is for the persistent nodemap docket first, but my target is to use similar logic for the revlogv2 (and co) test. For persisent nodemap, they are too many different in how each test variants (with rust, without rust, etc) needs new uid for this be really useful (right now). However it will be directly useful for the revlogv2 logic. Differential Revision: https://phab.mercurial-scm.org/D10753

run-tests: disable color in 'auto' mode on Windows if stdout is redirected Differential Revision: https://phab.mercurial-scm.org/D10761

run-tests: enable color on Windows In setting up the CI for Windows on heptapod, I noticed it was complaining about color not being enabled because pygments wasn't installed- even though it was. I had initially disabled color on Windows when using Windows 7, because that didn't understand ANSI color codes and made a mess of the output. But now that it's been unsupported for over a year, I don't think we should care about it either. It's admittedly a hack to depend on Mercurial proper to enable color support in the terminal, but I didn't feel like duplicating that code. I'm under the impression that 3rd party stuff is supposed to use this runner in the Mercurial repo instead of using their own copy, so I think it's safe to assume the Mercurial code is available. If it's not, it won't break anything. Differential Revision: https://phab.mercurial-scm.org/D10760

transaction: trivial refactoring Differential Revision: https://phab.mercurial-scm.org/D10714

test: remove some unnecessary dependency on repo format Differential Revision: https://phab.mercurial-scm.org/D10757

hg-cpython: fix new occuring TypeError dd339191f2dc introduced a minor refactoring of error types that highlighted a fragile error creation mechanism that was in place in the Rust `MixedIndex`. `PyErr::from_instance` also accepts a Python class, as long as it's an `Exception` class. Before the aforementioned commit, we never ran into a case where this duck-typing mechanism failed. We rectify this behavior by doing the instantiation ourselves. Differential Revision: https://phab.mercurial-scm.org/D10764

errors: make exit codes class variables instead Kyle pointed out to me that we can simply make the exit codes class variables. Python provides some magic for making them accessible as instance variables. This also makes it easier to let subclasses of existing errors override the exit codes by letting them simply define their own values as class variables. That means that there's no need to pass them into the superclass's constructor arguments, so the superclass doesn't need to expose the them as arguments. (Making a subclass set a different exit code for a subclass of `StorageError` was actually the goal with my recent series.) Differential Revision: https://phab.mercurial-scm.org/D10758

narrow: widen when files are excluded by sparse and not included by narrow In a repo where some directories are included by narrow and the complement are excluded by sparse, it was previously impossible to widen either because trying to widen narrow would complain that the requested files are outside the sparse checkout and trying to widen sparse would complain that the requested files are outside the narrow checkout. This changes the `hg tracked --addinclude` command to only actually update any newly accessible files in the dirstate if they are also accessible via sparse. Differential Revision: https://phab.mercurial-scm.org/D10734

hghave: make error output easier to diagnose I had a typo that meant the new bash check was throwing an exception (due to a missing argument), but it was very hard to diagnose without this change. Differential Revision: https://phab.mercurial-scm.org/D10733

tests: add req on bash for test-transaction-rollback-on-sigpipe (issue6429) I think we could work around this by rewriting the helper scripts in Python, but I don't want to deal with that now and this should prevent failures due to a lack of bash. Differential Revision: https://phab.mercurial-scm.org/D10732

updatecaches: deprecate the `full` argument Now that all users were migrated, we can use deprecate the old way. This would give potential extensions code a heads up on the API change. Differential Revision: https://phab.mercurial-scm.org/D10731

updatecaches: use the `caches` argument instead of a special `full` value After a clone we want to update most cachem, but not exactly all of them. We can now cleanly express this. Differential Revision: https://phab.mercurial-scm.org/D10730

updatecaches: use the caches argument in `hg debugupdatecaches` This is the new way. Differential Revision: https://phab.mercurial-scm.org/D10729

updatecaches: adds a `caches` parameters to `repo.updatecaches` It will superseed the `full` parameters (and its `post-clone` variant from stable). Various caller will be updated in the rest of this series. Differential Revision: https://phab.mercurial-scm.org/D10728

updatecaches: introduce a set of constants to control which are updated Passing around a set of constant to select what need warming will be cleaner and more flexible. We did not changed the API yet, as this changes is already large enough. In the rest of the rest we will change more code to actually use this constants (or more realistically pre-defined set of constant directly) Differential Revision: https://phab.mercurial-scm.org/D10727

errors: make StorageError subclass Error, attaching an exit code to it Differential Revision: https://phab.mercurial-scm.org/D10741

revlog: avoid raising no-arg RevlogError for internal flow control I'm about to make RevlogError require a `message` argument and this code was failing. This patch refactors it to not raise an exception for intra-function flow control. Differential Revision: https://phab.mercurial-scm.org/D10740

errors: catch the new Error class in scmutil and chgserver Differential Revision: https://phab.mercurial-scm.org/D10739

errors: create superclass for Abort exception I'd like to let extensions subclass `StorageError` to define a custom exit code. However, `StorageError` does not extend `Abort` (which is where the exit code currently lives), and it seems that it's not supposed to either (`StorageError` seems to be for lower-level errors and `Abort` is for command-level errors). This patch therefore extracts all the code from `Abort` into a new `Error` class, which I'll soon make `StorageError` also extend. Differential Revision: https://phab.mercurial-scm.org/D10738

errors: make InterventionRequired subclass Abort The docstring for `Abort` says that it's for errors raised by commands and `InterventionRequired` is definitely something raised by commands, so it seems that it should be an `Abort`. This patch makes it so. It adds a `coarse_exit_code` (in addition to the already existing `detailed_exit_code`) to `Abort` to achieve that, since `InterventionRequired` should result in a special exit code even when the `ui.detailed-exit-code` config is not set. Differential Revision: https://phab.mercurial-scm.org/D10737

errors: move Abort earlier, so more exceptions can subclass it I'd like to make at least `InterventionRequired` subclass `Abort` and Python requires the superclass to be defined before the subtype. Differential Revision: https://phab.mercurial-scm.org/D10736

errors: let each Abort subclass define its error code It's more flexible to have the error codes defined on the error types themselves. That way extensions can easily set their own exit code. It also means that we can reduce a bit of duplication betwen `scmutil.callcatch()` and `chgserver.chgcmdserver.validate()`. Differential Revision: https://phab.mercurial-scm.org/D10735

rust: Fix "panic message is not a string literal" warnings These deprecation warnings would not become errors until we actively port crates to the (not yet released) Rust 2021 edition, but fixing them anyway reduces console output noise. Differential Revision: https://phab.mercurial-scm.org/D10743

rust: Add type annotation to fix inference on Rust Nightly When compiling with Rust Nightly, the im-rs crate silently makes use of the experimental language feature for trait impl specialization. This apperently changes public its APIs in subtle ways such that type inference of some user code can fail where it succeeds when specialization is disabled. This made Mercurial’s Rust unit tests have compilation errors on Nightly. I have not managed to find the exactl root cause, but I wrote down my findings so far at https://github.com/bodil/im-rs/issues/188 This adds type annotation to make unit tests rely less on type inference and work around the issue. Differential Revision: https://phab.mercurial-scm.org/D10742

recover: only apply last journal record per file (issue6423) This got broken in 2019 when the size check was introduced. It is most noticable when dealing with transactions that involve an inline to non-inline revlog storage transaction. It wasn't seen as much at the time because the in-memory journal actually de-duplicated the entry implicity, but since 63edc384d3b7 the on-disk journal is used for rollback as well as recover. Differential Revision: https://phab.mercurial-scm.org/D10726