rust-config: fix incorrect coercion of null values to false As explained in the previous changeset: Probably being too trigger happy about boolean values, I incorrectly set the transform for a `None` to a `Some(false)`. It would cause for example the `ui.formatted` value to be set to `Some(false)`, which turns off the colors among other things, when `None` would trigger the automatic behavior.

rust-config: show default `null` is coerced incorrectly to `false` Probably being too trigger happy about boolean values, I incorrectly set the transform for a `None` to a `Some(false)`. It would cause for example the `ui.formatted` value to be set to `Some(false)`, which turns off the colors among other things, when `None` would trigger the automatic behavior. This is fixed in the next commit.

rust-config: fix fallback to default not parsing the default value When a config item's default is a string, it sometimes needs to be parsed into another type, like in the case of `cmdserver.max-log-size`, that returns a number of bytes from a human-readable amount like `25MB`. The logic for the fix is explained inline.

rust-config: demonstrate a bug when falling back to non-trivial default values The default value (when the user hasn't configured anything) is not run through the value parser, causing a programming error to happen because of type mismatch. This will be fixed in the next commit.

rust: make `Revision` a newtype This change is the one we've been building towards during this series. The aim is to make `Revision` mean more than a simple integer, holding the information that it is valid for a given revlog index. While this still allows for programmer error, since creating a revision directly and querying a different index with a "checked" revision are still possible, the friction created by the newtype will hopefully make us think twice about which type to use. Enough of the Rust ecosystem relies on the newtype pattern to be efficiently optimized away (even compiler in codegen tests¹), so I'm not worried about this being a fundamental problem. [1] https://github.com/rust-lang/rust/blob/7a70647f195f6b0a0f1ebd72b1542ba91a32f43a/tests/codegen/vec-in-place.rs#L47

rust: implement the `Graph` trait for all revlogs This is trivial and makes all the algorithms relying on the trait usable for more use cases.

rust: use the new `UncheckedRevision` everywhere applicable This step converts all revisions that shouldn't be considered "valid" in any context to `UncheckedRevison`, allowing `Revision` to be changed for a stronger type in a later changeset. Note that the conversion from unchecked to checked is manual and requires at least some thought from the programmer, although directly using `Revision` is still possible. A later changeset will make this mistake harder to make.

rust-revlog: split logic for `rawdata` to prepare for `UncheckedRevision` use In the next changeset, we will change the logic to use `UncheckedRevision` in the non-general delta case. The general delta case will use the "checked" path since `base_rev_or_base_of_delta_chain` will be checked.

rust: remove unused error variant All paths check that the working directory revision is not used.

rust: add `UncheckedRevision` type This is the start of a series whose aim is to separate "checked" and "unchecked" revision numbers. A "checked" revision number is valid for a given index, allowing us to have faster algorithms that don't do redundant checks all the time and have a clearer view of the kinds of revisions we're working with.

debugwireproto: migrate `opts` to native kwargs

debugwireargs: migrate `opts` to native kwargs

debugwalk: migrate `opts` to native kwargs

debug_revlog_stats: migrate `opts` to native kwargs

debugbackupbundle: migrate `opts` to native kwargs

debugsidedata: migrate `opts` to native kwargs

debugserve: migrate `opts` to native kwargs

debugrevspec: migrate `opts` to native kwargs

debugrevlogindex: migrate `opts` to native kwargs

debugrevlog: migrate `opts` to native kwargs

debugrename: migrate `opts` to native kwargs

debugrebuildfncache: migrate `opts` to native kwargs

debugpickmergetool: migrate `opts` to native kwargs

debugp2copies: migrate `opts` to native kwargs

debugp1copies: migrate `opts` to native kwargs

debugobsolete: migrate `opts` to native kwargs

debugmergestate: migrate `opts` to native kwargs

debugknown: migrate `opts` to native kwargs

debuginstall: migrate `opts` to native kwargs

debugindexdot: migrate `opts` to native kwargs

debuggetbundle: migrate `opts` to native kwargs

debugformat: migrate `opts` to native kwargs

debugfileset: migrate `opts` to native kwargs

debugextensions: migrate `opts` to native kwargs

debugdiscovery: migrate `opts` to native kwargs

debugdeltafind: migrate `opts` to native kwargs

debugdeltachain: migrate `opts` to native kwargs

debugdata: migrate `opts` to native kwargs

debugcapabilities: migrate `opts` to native kwargs

debugbundle: migrate `opts` to native kwargs This is a utility function that's only called by `debugbundle()`. The rest of the command was previously ported.

branching: merge with stable

tags: avoid expensive access to repo.changelog in a loop repo.changelog needs some cache invalidation when run on filtered repository. Accessing it in that loop can be expensive when there is many heads (e.g. mozilla try and it 25 000 heads). Note that the loop itself seems useless, but after this patch it no longer take about ⅛ of the time we spend computing cache for mozilla try. before : ! wall 0.350994 comb 0.350000 user 0.330000 sys 0.020000 (median of 28) after : ! wall 0.319520 comb 0.310000 user 0.290000 sys 0.020000 (median of 30)

blackbox: add a option to duplicate output to stderr too This is useful when debugging some performance operation.

perf: add a --update-last flag to perf::tags See inline documentation for details.

perf: add a `--clear-fnode-cache-rev` argument to perf::tags This will help us test this in situation closer to an update after a commit or a push.

perf: introduce more cache invalidation option in perf::tags This will help us to assert the performance of different versions in more diverse situations. We introduce helper function in the tags module in case invalidating such cache becomes different in the future.

hgweb: pass strings in WSGI environment correctly from wsgicgi According to PEP 3333, the strings in the WSGI environment must be translatable to bytes using the ISO-8859-1 codec.

branching: merge stable into default

Added signature for changeset 5a8b54201039

Added tag 6.5.2 for changeset 5a8b54201039

relnotes: add 6.5.2

run-tests: detect HGWITHRUSTEXT value Without this, some manual check in tests/test-dirstate.t could get confused by the lack of `rust` in module policy and break the test.

tests: avoid test environment affecting setup.py In particular [RHG_FALLBACK_EXECUTABLE] is being set prematurely, before rhg is built, but probably the rest of the env changes don't help, either.

setup: make the error "Unable to find a working hg binary" more informative The error message now shows the attempted hg commands and their stderr, to make it easier to investigate why things are not working. Here's an example output /!\ /!\ Unable to find a working hg binary /!\ Version cannot be extracted from the repository /!\ Re-run the setup once a first version is built /!\ Attempts: /!\ attempt #0: /!\ cmd: ['hg-missing', 'log', '-r.', '-Ttest'] /!\ exception: [Errno 2] No such file or directory: 'hg-missing': 'hg-missing' /!\ attempt #1: /!\ cmd: ['/usr/bin/python3', 'hg', 'log', '-r.', '-Ttest'] /!\ return code: 255 /!\ std output: /!\ std error: *** failed to import extension "topic": No module named 'topic' *** failed to import extension "evolve": No module named 'evolve' abort: accessing `dirstate-v2` repository without associated fast implementation. (check `hg help config.format.use-dirstate-v2` for details) /!\ /!\ Could not determine the Mercurial version /!\ You need to build a local version first /!\ Run `make local` and try again /!\

pycompat: drop usage of hasattr/getattr/setattr/delatt proxy The function remains to ease extensions transition, but we no longer use them in core.

safehasattr: drop usage in favor of hasattr The two functions should now be equivalent at least in their usage in core.