Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 15:27:12 +0900] rev 43721
typing: fix argument type of encoding.tolocal() and .fromutf8b()
Fixes various pytype errors.
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 15:10:41 +0900] rev 43720
typing: fix forward reference in _Tlocalstr type bound
AFAIK, a quoted string in type position is translated to its ForwardRef.
https://github.com/python/typing/issues/34
This fixes the following error:
File "mercurial/encoding.py", line 38, in <module>: Name 'localstr' is not
defined [name-error]
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 15:43:21 +0900] rev 43719
encoding: make getcols() raise exception explicitly
This helps pytype.
File "mercurial/encoding.py", line 329, in getcols: bad option in return
type [bad-return-type]
Expected: bytes
Actually returned: None
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Nov 2019 12:19:43 -0500] rev 43718
setup: conditionalize access to `sys.dllhandle` when building extensions
This code is only run on Windows, and was crashing PyOxidizer when running in
`setup-py-install` mode. Now an oxidized binary can be built by simply pointing
to setup.py.
Something is slightly different now that it's not being built from a virtualenv.
Previously, `hg version` could print to the screen, but now it aborts saying
"Incorrect function". But I can see the output if redirected to a file, and
it's not complaining about missing C extensions, so I think those are loading
now (unlike from the virtualenv). The interesting this about this incorrect
function output is that it failed when initially built. I then went back and
did a `make clean` and `make local` with py3 and then py2 to ensure I didn't
break the existing code. At that point I ran the oxidized executable again and
it was able to print to the screen normally! So I ran `pyoxidizer build` again,
it only output the following, and then running the executable failed to output
again:
(pyO2_venv) C:\Users\Matt\hg3\hg_pyO2>pyoxidizer build
Finished dev [unoptimized + debuginfo] target(s) in 0.12s
packaging application into C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug
purging C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug
copying C:/Users/Matt/hg3/hg_pyO2\build\target\x86_64-pc-windows-msvc\debug\hg_pyO2.exe to
C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug\hg_pyO2.exe
resolving packaging state...
writing license for [...]
hg_pyO2 packaged into C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug
executable path: C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug\hg_pyO2.exe
Differential Revision: https://phab.mercurial-scm.org/D7444
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Nov 2019 11:48:47 -0500] rev 43717
setup: use bytes for assumed python version
Caught by PyOxidizer when hacking on Windows.
# skip-blame for b'' prefixing
Differential Revision: https://phab.mercurial-scm.org/D7443
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Nov 2019 11:42:27 -0500] rev 43716
setup: combine two contiguous string literals
Differential Revision: https://phab.mercurial-scm.org/D7442
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 13:18:22 -0800] rev 43715
util: remove datapath and swith users over to resourceutil
The util module no longer needs the datapath for injecting it into the
i18n module, so we can remove it from there and update other users.
Differential Revision: https://phab.mercurial-scm.org/D7436
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 12:41:33 -0800] rev 43714
i18n: get datapath directly from resourceutil
The new resourceutil module is lower in the dependency graph, so we
can depend directly on it and won't have to depend on the util module
to inject the datapath.
Differential Revision: https://phab.mercurial-scm.org/D7435
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 12:33:10 -0800] rev 43713
util: move definition of datapath to resourceutil
Since this means moving the function into a subdirectory, we have to
compensate by adding another layer of os.path.dirname().
Differential Revision: https://phab.mercurial-scm.org/D7434
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 11:52:22 -0800] rev 43712
procutil: move mainfrozen() to new resourceutil.py
The i18n module practically depends on procutil for mainfrozen() but
since procutil depends on i18n, it would be a circular dependency if
i18n depended directly on procutil. The cycle is currently resolved by
having the higher-level util module calculate the "datapath" and
inject it into i18n. Extracting mainfrozen() to a new module lets us
clean up the dependencies.
Differential Revision: https://phab.mercurial-scm.org/D7433
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 17:36:01 -0800] rev 43711
defaults: rename default.d to defaultrc to make it a valid package name
"default.d" is not a valid Python package name, and it needs to be a
valid package name if we want to be able to load the files from here
as resources.
Differential Revision: https://phab.mercurial-scm.org/D7426
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 17:30:52 -0800] rev 43710
help: remove references to default.d/ from user-facing docs
The user doesn't need to know what we call the internal directory and
I'm about to rename it.
Differential Revision: https://phab.mercurial-scm.org/D7425
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 14 Nov 2019 10:47:04 +0100] rev 43709
bisect: replace try:/finally: by a "restore_state" context manager
This should help pytype to not consider "bgood" variable as NameError.
See https://phab.mercurial-scm.org/D7384 for context.
Differential Revision: https://phab.mercurial-scm.org/D7430
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 30 Oct 2019 19:19:57 -0400] rev 43708
histedit: render a rolled up description using the proper roll colours
Users have rightfully complained that the old behaviour of completely
removing the description of a rolled commit makes it difficult to
remember what was in that commit. Instead, we now render the removed
description in red.
I couldn't think of a simpler way to do this. You can't just combine
existing curses colours into new effects; only secondary effects like
bold or underline can be logically OR'ed to generate a combined text
effect. It seems easier to just redundantly keep track of what the
roll colour should be.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 30 Oct 2019 19:34:57 -0400] rev 43707
histedit: define new colour pairs for roll action
Red seems like a good colour to indicate removal, since that's the
colour we use in diffs. We need three varieties with three different
backgrounds corresponding to the possible ways we can display a rule.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 30 Oct 2019 19:27:09 -0400] rev 43706
histeditrule: split __bytes__ property into prefix and desc
In order to be able to colourise the description of the rule, we need
to have it as a separate bytestring. Curses doesn't make it easy to
take existing text on the screen and give it different properties; we
can only add new text with new properties.
Yuya Nishihara <yuya@tcha.org> [Fri, 15 Nov 2019 22:22:55 +0900] rev 43705
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Nov 2019 20:40:54 -0800] rev 43704
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
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Nov 2019 20:35:11 -0800] rev 43703
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
Augie Fackler <augie@google.com> [Tue, 12 Nov 2019 10:17:59 -0500] rev 43702
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:14:11 -0800] rev 43701
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:07:36 -0800] rev 43700
py3: drop an unnecessary fsencode() before comparing with constant
Differential Revision: https://phab.mercurial-scm.org/D7413
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:03:02 -0800] rev 43699
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 13:38:17 -0500] rev 43698
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:29:27 -0500] rev 43697
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:28:44 -0500] rev 43696
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:28:34 -0500] rev 43695
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:28:08 -0500] rev 43694
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:58 -0500] rev 43693
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:50 -0500] rev 43692
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:40 -0500] rev 43691
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
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:32 -0500] rev 43690
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