rust: fix false comment about mpsc::Sender We need Sync to share the Sender reference across threads.

resourceutil: fix location of line comments These comments slipped out of position when the sources where formatted with black in 2372284d9457.

rebase: avoid clobbering wdir() with --dry-run or --confirm (issue6291) See 56d3e0b499df for the source of adding originalwd to the list of things that cause wdir to be updated. That change didn't come with tests, and attempts to recreate the scenario described have thus far failed. Differential Revision: https://phab.mercurial-scm.org/D8489

tests: show that rebase --dry-run and --confirm wipeout uncommitted changes It looks like the carnage is limited to rebasing something that is not an ancestor of wdir(), as both of these abort in a preflight check for that case with a dirty working directory. Differential Revision: https://phab.mercurial-scm.org/D8488

Added signature for changeset 065704cbdbdb

Added tag 5.4.1 for changeset 065704cbdbdb

py3: update comment to account for Python 2 and Python 3 differences

py3: add warning about buffering behavior of pycompat.{stdout,stderr}

tests: fix indentation

merge with stable

graft: fix --base value to be saved in state file 'True' just works because it is treated as an integer revision '1' and only the truthiness of the basectx is important. If multiple source revisions were supported with --base, the resumed graft operation would go wrong.

flags: also test merge with executable bit removed This might catch more bug in the future. Differential Revision: https://phab.mercurial-scm.org/D8536

flags: also test the removal of the exec flag Differential Revision: https://phab.mercurial-scm.org/D8535

flags: read flag from dirstate/disk for workingcopyctx (issue5743) In 491855ea9d62, various piece of code are moved from committablectx to workingctx. The reason given is "These read from the dirstate, so they shouldn't be used in other subclasses." At least for `flags` this change introduce a bug, because the value flags end up being read from `_manifest` disregarding the actual state in the working copy (ie: on disk). When merging exec flag change with renames, this means a new files (the local content, renamed) is properly written on disk, with the right flags, but the flags part is later ignored when actually reading flags during merge. It is not clear to me why the `flags` function was moved, because the code does not actually hit the dirstate (the reason given in the changeset description). So I am moving it back to were it comes from and we use a simpler version of that code (that hit the dirstate everytime) in workingcopyctx. This fix the last know bug with merging rename and executable byte changes. Other similar bug might be lurking in 491855ea9d62, but I have not investigated them. Differential Revision: https://phab.mercurial-scm.org/D8534

flags: actually merge flags in simplemerge Since b86fc43e4b73, the local flag were blindly taken. This resulted in bug when rename are involved. exec flag change are now properly merged (when merged from the rename side). Another bug is affecting this when merging from the side without the rename. Differential Revision: https://phab.mercurial-scm.org/D8533

flags: add a test for merging exec flag change with rename and file change Changing the file activate other code path that also have bugs… There are two distinct bugs depending of which side of the merge you stand on. They both leading to exec flag loss. We add tests for both, the fix are coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D8532

flags: account for flag change when tracking rename relevant to merge There are some logic filtering rename to the one relevant to the merge. That logic was oblivious of flag change, leading to exec flag being dropped when merged with a renamed. There are two others bugs affecting this scenario. This patch fix the was where there is not modification involved except for the flag change. Fixes for the other bug are coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D8531

flags: also test merging a rename with and exec flag change This case is currently buggy and was not tested. This is probably a quite old regression. The next changeset fix this case. Move exec+rename related bug will gain a test later. To highlight the expected behavior the currently missing line are marked with (false !) and the bad one with (true !) note: we should probably gain explicit "test bool" for this usecases. Differential Revision: https://phab.mercurial-scm.org/D8530

flags: introduce explicit testing for merging change to exec flag It turns out that we do not seems to test the simple case for merging exec flag changes. More advanced case are test (merging exec flag without a common ancestors, merging with a symlink, etc…) but not the basic. We are about introduce various fixes to merging flag change across renames, having the most basic case tested first seems useful. note: We are only testing "adding" an exec flag here, not removing it. We introduce basic test on stable and will consolidate them on default. Differential Revision: https://phab.mercurial-scm.org/D8529

graft-state: save --base in graft's state, fixing bug with graft --continue Without this change, running graft --continue after grafting a merge commit using --base (and encountering conflicts) will output "skipping ungraftable merge revision" even though we specified a base in the initial graft command. Graft's improve behaviour is reflected in test-graft.t. Differential Revision: https://phab.mercurial-scm.org/D8578

relnotes: advertize the possibility to use rust I think the rust work may have been mentioned in the release notes, but if so only in passing, and not as an invitation to try it out. I think the next version is a decent time to do this, because the rust doesn't come with performance regressions AFAIK, speeds up status noticeably when it applies, which is the case for most invocations of status, and doesn't have the undesirable restriction of regex around empty patterns anymore. I am cheating a bit, because I'm giving numbers for `hg status` in mozilla-central, but they have one hgignore pattern that uses lookaround, ".vscode/(?!extensions\.json|tasks\.json", which I took out as it would cause a fallback to python when unknown files are requested. But it seems that they could express their hgignore differently if they were so inclined. Not sure if there are limitation other than linux-only that I am not thinking of but would be worth mentioning upfront, to avoid disappointing users? Differential Revision: https://phab.mercurial-scm.org/D8604

rust: add a pointer for profiling to the README As figuring out how to get useful profiles is not obvious. Differential Revision: https://phab.mercurial-scm.org/D8603

rust: update the mention of hgcli in rust/README.rst This may not be exactly right, but it's better than before. Differential Revision: https://phab.mercurial-scm.org/D8602

sslutil: fix comment to use inclusive or instead of exclusive or The incorrect "either" was introduced by one of my recent patches.

sslutil: propagate return value ssl.PROTOCOL_SSLv23 from protocolsettings() Also, protocolsettings() was renamed to commonssloptions() to reflect that only the options are returned.

sslutil: stop storing protocol and options for SSLContext in settings dict Call protocolsettings() where its return values are needed.

sslutil: rename 'minimumprotocolui' -> 'minimumprotocol' Before, both 'minimumprotocolui' and 'minimumprotocol' were used, but meaning the same.

sslutil: properly detect which TLS versions are supported by the ssl module For the record, I contacted the CPython developers to remark that unconditionally defining ssl.PROTOCOL_TLSv1_1 / ssl.PROTOCOL_TLSv1_2 is problematic: https://github.com/python/cpython/commit/6e8cda91d92da72800d891b2fc2073ecbc134d98#r39569316

sslutil: remove dead code (that failed if only TLS 1.0 is available) We ensure in setup.py that TLS 1.1 or TLS 1.2 is present.

config: remove unused hostsecurity.disabletls10warning config

sslutil: remove dead code (that downgraded default minimum TLS version) We ensure in setup.py that TLS 1.1 or TLS 1.2 is present.

sslutil: remove comment referring to unsupported legacy stacks

setup: require that Python has TLS 1.1 or TLS 1.2 This ensures that Mercurial never downgrades the minimum TLS version from TLS 1.1+ to TLS 1.0+ and enables us to remove that compatibility code. It is reasonable to expect that distributions having Python 2.7.9+ or having backported modern features to the ssl module (which we require) have a OpenSSL version supporting TLS 1.1 or TLS 1.2, as this is the main reason why distributions would want to backport these features. TLS 1.1 and TLS 1.2 are often either both enabled or both not enabled. However, both can be disabled independently, at least on current Python / OpenSSL versions. For the record, I contacted the CPython developers to remark that unconditionally defining ssl.PROTOCOL_TLSv1_1 / ssl.PROTOCOL_TLSv1_2 is problematic: https://github.com/python/cpython/commit/6e8cda91d92da72800d891b2fc2073ecbc134d98#r39569316

sslutil: check for OpenSSL without TLS 1.0 support in one case It can only happen if supportedprotocols gets fixed to contain only correct items (see the FIXME above in the file).

sslutil: don't set minimum TLS version to 1.0 if 1.2 but not 1.1 is available This case isn't very likely, but possible, especially if supportedprotocols gets fixed to contain only correct items (see the FIXME above in the file).

sslutil: add FIXME about supportedprotocols possibly containing too many items

sslutil: fix names of variables containing minimum protocol strings When working in this module, I found it very confusing that "protocol" as a variable name could mean either "minimum protocol string" or an exact version (as a string or ssl.PROTOCOL_* value). This patch prefixes variables of the former type with "minimum".

sslutil: stop returning argument as third return value of protocolsettings() The third return value was always the same as the argument.

relnotes: note that we now require modern SSL/TLS features in Python

tests: stop checking for optional, now impossible output In 7dd63a8cb1ee, the code that could output that line was removed.

rust: remove one more occurrence of re2 Differential Revision: https://phab.mercurial-scm.org/D8601

scmutil: clarify getuipathfn comment Differential Revision: https://phab.mercurial-scm.org/D8600

githelp: add some minimal help for pickaxe functionality Due to a conversation in work chat, I realized this is actually pretty well-hidden in Mercurial. Differential Revision: https://phab.mercurial-scm.org/D8590

rust: remove duplicate import Differential Revision: https://phab.mercurial-scm.org/D8456

tests: remove "sslcontext" check Now that we require the presence of ssl.SSLContext in setup.py, the check would always return `True`.

sslutil: eliminate `_canloaddefaultcerts` by constant-folding code using it

tests: remove "defaultcacerts" check `sslutil._canloaddefaultcerts` is always true (and will be removed).

sslutil: eliminate `modernssl` by constant-folding code using it

hgweb: avoid using `sslutil.modernssl` `sslutil.modernssl` is going to be removed. Since the point of using this attribute was to check the importability of the `sslutil`, a different attribute can be used. `sslutil.wrapserversocket` is used because it’s anyway used a few lines below.

sslutil: remove comments referring to removed SSLContext emulation class

sslutil: remove code checking for presence of ssl.SSLContext Now that we require the presence of ssl.SSLContext in setup.py, we can remove this code.

setup: require a Python version with modern SSL features This increases the minimum security baseline of Mercurial and enables us to remove compatibility code for supporting older, less secure Python versions.

sslutil: set `_canloaddefaultcerts` to `True` if `ssl.SSLContext` is present The `load_default_certs()` method was already present when `ssl.SSLContext` was backported to Python 2.7 (https://hg.python.org/cpython/rev/221a1f9155e2).

filemerge: add __bytes__ for absentfilectx This will at _least_ aid some upcoming debugging. Differential Revision: https://phab.mercurial-scm.org/D8592

mergestate: move staticmethod _filectxorabsent to module level I suspect this was a static method just because it made merge.py feel less messy, but now we have a mergestate package so we can do better. Differential Revision: https://phab.mercurial-scm.org/D8591

rust: remove support for `re2` With the performance issues with `regex` figured out and fixed in previous patches and `regex` newly gaining support for empty alternations, there is no reason to keep `re2` around anymore. It's only *marginally* faster at creating the regex which saves at most a couple of ms, but gets beaten by `regex` in every other aspect. This removes the Rust/C/C++ bridge (hooray!), the `with-re2` feature, the conditional code that goes with it, the documentation and relevant part of the debug/module output. Differential Revision: https://phab.mercurial-scm.org/D8594

rust-dependencies: update `regex` to 1.3.9 Version `1.3.8` introduces support for empty alternations, which makes previously disallowed patterns usable in `regex`. From a user's perspective, this means that glob patterns like `*.py{,c}` will no longer generate an "invalid" regex and will use the Rust path. `1.3.9` is a bugfix release, might as well update to the latest one. Differential Revision: https://phab.mercurial-scm.org/D8593

cleanup: remove compatibility code for Python < 2.7.4 The minimum supported Python version was recently raised to 2.7.4.

cleanup: eliminate procutil.quotecommand() After some compatibility code was removed, the function was the identity function on all platforms.

cleanup: remove compatibility code for Python < 2.7.1 The minimum supported Python version was recently raised to 2.7.4.