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.