Summary:
Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK **/*.py`.
Then run `arc lint` again so some other autofixers like spellchecker etc. looked
at the code base. Manually accept the changes whenever they make sense, or use
a workaround (ex. changing "dict()" to "dict constructor") where autofix is false
positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less
interesting to fix (hgsubversion tests), or cannot be fixed without breaking
OSS build (FBPYTHON4).
Conflicted linters (test-check-module-imports.t, part of test-check-code.t,
test-check-pyflakes.t) are removed or disabled.
Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed.
An issue of the auto-formatter is lines are no longer guarnateed to be <= 80
chars. But that seems less important comparing with the benefit auto-formatter
provides.
As we're here, also remove test-check-py3-compat.t, as it is currently broken
if `PYTHON3=/bin/python3` is set.
Reviewed By: wez, phillco, simpkins, pkaush, singhsrb
Differential Revision: D8173629
fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b
The error return is not 0 for this method, so _check() was doing nothing when an
error occurred. This forces the error path, much like the check for
OpenProcess().
The only unhandled return is now WAIT_ABANDONED, but I don't see how that could
happen in this case.
With #serve enabled on Windows, I was getting occasional stacktraces like this:
Errored test-hgweb-json.t: Traceback (most recent call last):
File "./run-tests.py", line 724, in run
self.tearDown()
File "./run-tests.py", line 805, in tearDown
killdaemons(entry)
File "./run-tests.py", line 540, in killdaemons
logfn=vlog)
File "...\tests\killdaemons.py", line 94, in killdaemons
os.unlink(pidfile)
WindowsError: [Error 32] The process cannot access the file because it is
being used by another process: '...\\hgtests.zmpqj3\\child80\\daemon.pids'
Adrian suggested using util.posixfile, which works. However, the 'mercurial'
package isn't in sys.path when invoking run-tests.py, and it isn't clear that
hacking[1] it in is a good thing (especially for test-run-tests.t, which uses an
installation in a temp folder).
I tried using ProcessMonitor to figure out what the other process is, but that
monitoring slows things down to such a degree that the issue doesn't occur. I
was ready to blame the virus scanner, but it happens without that too.
Looking at the code, I don't see anything that would have the pid file open.
But I was able to get through about 20 full test runs without an issue with this
minor change, whereas before it was pretty certain to hit this at least once in
two or three runs.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097907.html
When I was fixing the test-gpg issue, I noticed gpg-connect-agent could print
"-1" as a server pid if command was wrong. I'm not pretty sure but nobody
would want to kill their running applications by mistake.
test-run-tests.t still passes fine on Python 2.6. run-tests.py --local
no longer fails with syntax errors, and now fails looking for xrange.
Most changes done with
2to3 -w -f numliterals -f except -f print tests/run-tests.py tests/killdaemons.py
after which one import was fixed in run-tests and a __future__ import
was added.
As far as I'm aware PEP 237[0] means this suffix is superfluous even
on Python 2.4, and we can just drop it, which makes this code happy on
Python 3.
0: http://legacy.python.org/dev/peps/pep-0237/
To distinguish between access violaition (process belonging to another user)
and a terminated process, PROCESS_QUERY_INFORMATION must be enabled. But
TerminateProcess still raises error 5 in both cases. Therefore check before if
the process has already terminated.
After kill, wait for the process to terminate. When it does not in time,
write a debug message similar as in other os. But no 2nd forceful attempt
is done.