rust-blackbox: use `is_extension_enabled` config helper It's there, may as well use it to make the code clearer and less bug-prone.

configitems: move blackbox's config items to the new configitems.toml In order for the Rust code to gain access to default values of in-core extensions that have a Rust implementation, we need to centralize them alongside the core items declarations. This is the first and so far only one of the extensions that have gained Rust support, I don't think it's worth the churn to move the rest of the extension's configitems yet.

rust-config: add config getters that don't fall back to defaults This is useful in cases where we access config items that are more... lenient with their types than a fresh new system would allow. For now there is only a single use of this, but we might get more later.

rust-config: add support for default config items Now that configitems.toml exists, we can read from it the default values for all core config items. We will add the devel-warning for use of undeclared config items in a later patch when we're done adding the missing entries for `rhg`.

configitems: declare items in a TOML file Mercurial ships with Rust code that also needs to read from the config. Having a way of presenting `configitems` to both Python and Rust is needed to prevent duplication, drift, and have the appropriate devel warnings. Abstracting away from Python means choosing a config format. No single format is perfect, and I have yet to come across a developer that doesn't hate all of them in some way. Since we have a strict no-dependencies policy for Mercurial, we either need to use whatever comes with Python, vendor a library, or implement a custom format ourselves. Python stdlib means using JSON, which doesn't support comments and isn't great for humans, or `configparser` which is an obscure, untyped format that nobody uses and doesn't have a commonplace Rust parser. Implementing a custom format is error-prone, tedious and subject to the same issues as picking an existing format. Vendoring opens us to the vast array of common config formats. The ones being picked for most modern software are YAML and TOML. YAML is older and common in the Python community, but TOML is much simpler and less error-prone. I would much rather be responsible for the <1000 lines of `tomli`, on top of TOML being the choice of the Rust community, with robust crates for reading it. The structure of `configitems.toml` is explained inline.

thirdparty: vendor tomli The next commit will introduce a .toml file to abstract configitems away from Python. Python 3.11 has a toml read-only library (`tomllib`), which gives us a way out of vendoring eventually. For now, we vendor the backport, specifically version 1.2.3 which is still compatible with Python 3.6.

configitems: add `documentation` field It may be useful to expose documentation information in the help in some form. This will be populated in a future changeset by using the current comments that are relevant for users.

configitems: use standard "dynamicdefault" approach in edge case This makes for fewer edge cases, which will help a future patch.

configitems: fix typo in devel warning about extension overrides

extensions: imp module is removed in Python 3.12 - use importlib to load files imp has been deprecated for a long time, and has finally been removed in Python 3.12 . imp was only used for loading extensions that has been specified with direct .py path or path to a package directory. The same use cases can be achieved quite simple with importlib, , possiby with small changes in corner cases with undefined behaviour, such as extensions without .py source. There might also be corner cases and undefined behaviour around use of sys.modules and reloading.

utils: imp module is removed in Python 3.12 - get is_frozen() from _imp imp has been deprecated for a long time, and has finally been removed in Python 3.12 . The successor importlib is using the same internal _imp module as imp, but doesn't expose it's is_frozen. Using the internal function directly seems like the cleanest solution. Another alternative to imp.is_frozen("__main__") is sys.modules['__main__'].__spec__.origin == 'frozen' but that seems even more internal and fragile.

extensions: address ast deprecations introduced in Python 3.12 Tests would fail with: .../mercurial/extensions.py:910: DeprecationWarning: ast.Str is deprecated and will be removed in Python 3.14; use ast.Constant instead if isinstance(a, ast.Str): .../mercurial/extensions.py:912: DeprecationWarning: ast.Bytes is deprecated and will be removed in Python 3.14; use ast.Constant instead elif isinstance(a, ast.Bytes): .../mercurial/extensions.py:913: DeprecationWarning: Attribute s is deprecated and will be removed in Python 3.14; use value instead name = a.s

vfs: handle shutil.rmtree deprecation of onerror in Python 3.12 Tests would fail with warnings: .../mercurial/vfs.py:289: DeprecationWarning: onerror argument is deprecated, use onexc instead The excinfo changed slightly, but we don't use it anyway.

tests: fix sortdict doctest with Python 3.12 The output of OrderedDict changed to use plain dict syntax: $ python3.11 -c "import collections;print(collections.OrderedDict([('a', 0), ('b', 1)]))" OrderedDict([('a', 0), ('b', 1)]) $ python3.12 -c "import collections;print(collections.OrderedDict([('a', 0), ('b', 1)]))" OrderedDict({'a': 0, 'b': 1})

utils: stop using datetime.utcfromtimestamp() deprecated in Python 3.12 Python3.12 made tests fail with warnings: DeprecationWarning: datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.fromtimestamp(timestamp, datetime.UTC). Computing the diff while in timestamp seconds seems to preserve to the original intent from ae04af1ce78d. It would be nice to have some doctest coverage of this, with the problematic corner cases that has popped up over time...

branching: merge stable into default

Added signature for changeset 3ffc7209bbae

Added tag 6.5 for changeset 3ffc7209bbae

relnotes: add 6.5 final

rust-changelog: removed now useless early conditional for NULL_REVISION Now that the underlying `RevlogEntry` returned for `NULL_REVISION` is viable, it has become pointless to check NULL_REVISION several times, even for performance: the check will be far more frequent than the benefit of bailing earlier in the rare case where the requested revision is `NULL_REVISION`. This case is covered explicitly by the first assertion of `test_data_from_rev_null`.

rust-revlog: fix RevlogEntry.data() for NULL_REVISION Before this change, the pseudo-entry returned by `Revlog.get_entry` for `NULL_REVISION` would trigger errors in application code using it. For example, this fixes a crash spotted with changelog data while implementing RHGitaly: `Changelog.data_for_rev(-1)` was already returning the pseudo content as expected, e.g., for `hg log`, but `Changelog.entry_for_rev(-1).data()` would still crash with "corrupted revlog, hash check failed for revision -1". There is an added test for this scenario.

rust-revlog: using constant in test Always better

rust-revlog: fix incorrect results with NULL_NODE prefixes In case a short hash is a prefix of `NULL_NODE`, the correct revision number lookup is `NULL_REVISION` only if there is no match in the nodemap. Indeed, if there is a single nodemap match, then it is an ambiguity with the always matching `NULL_NODE`. Before this change, using the Mercurial development repository as a testbed (it has public changesets with node ID starting with `0005` and `0009`), this is what `rhg` did (plain `hg` provided for reference) ``` $ rust/target/debug/rhg cat -r 000 README README: no such file in rev 000000000000 $ hg cat -r 000 README abort: ambiguous revision identifier: 000 ``` Here is the expected output for `rhg` on ambiguous prefixes (again, before this change): ``` $ rust/target/debug/rhg cat -r 0001 README abort: ambiguous revision identifier: 0001 ``` The test provided by 8c29af0f6d6e in `test-rhg.t` could become flaky with this change, unless all hashes are fixed. We expect reviewers to be more sure about that than we are.

rust-revlog: split out method for `rev_from_node` without persistent nodemap This will make easier for the bug fix that is about to come.

win32mbcs: unbyteify some strings for py3 support A crash was reported on the TortoiseHg bug tracker for this[1]. [1] https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5905

heptapod-ci: turn off pipelines for merge request events These are always duplicated by the external (from the user) push, or internal (from Heptapod itself) push pipeline, so they're entirely redundant.

heptapod-ci: always make the default run condition explicit This has no effect on behavior, it's just to make everything obvious.

heptapod-ci: remove push exception for named branches The internal workings of Heptapod cause even fast-forward merges to look like pushes to Gitlab. The only way to run a pipeline on topic-less named branches is not through the web interface. I am probably the only person affected by this, so it's not really a problem. This was confirmed with Georges, the maintainer of Heptapod, though the only way to be *actually* sure, is to merge this and see.

heptapod-ci: (hopefully) fix the pipeline savings system There is no easy way for me to test this outside of the actual repo since it would require setting up `heptapod-runner` locally, making a Git repo with the right changes, etc. It's not worth my time at this point. If this fails, I'll try to ask for help from Georges, the maintainer of Heptapod.

heptapod-ci: don't run pipelines for topic-less branches See inline comment for more details.

clonebundles: add warning if auto-generate is enabled without formats

clonebundles: fix display of auto-generate.on-change lines