tests: conditionalize the progress timestamp for Windows It looks like for py2 on Windows, the start date is 1970. It matches the other platforms for py3, so I'm just going to match the tests and move on, given that py2 is on the way out. Differential Revision: https://phab.mercurial-scm.org/D9541

tests: conditionalize a few Windows specific error messages Differential Revision: https://phab.mercurial-scm.org/D9540

tests: correct the output order about starting a background thread for Windows I didn't track down where this change occurred. I assume it's related to some buffering changes, and/or an explicit flush somewhere. Differential Revision: https://phab.mercurial-scm.org/D9539

tests: update the exit status codes for Windows specific tests This corresponds to 527ce85c2e60, ebee234d952a, and 568c05d8f3d2. Differential Revision: https://phab.mercurial-scm.org/D9538

tests: drop the trailing exclamation point from some Windows abort messages This likely goes with 95c4cca641f6. Differential Revision: https://phab.mercurial-scm.org/D9537

tests: update output for test-check-pylint.t The py3 version on Windows appends "(previous run: 10.00/10, +0.00)" with py39. I didn't see that for the exact same version on Linux (with py3.6.9). Differential Revision: https://phab.mercurial-scm.org/D9536

run-tests: extend PATH on Windows to include user installed scripts This allows the test environment to see pylint.exe when installed with `pip install --user`, since it isn't normally on PATH. Differential Revision: https://phab.mercurial-scm.org/D9535

run-tests: stuff a `python3.exe` into the test bin directory on Windows Windows doesn't have `python3.exe` as part of the python.org distribution, and that broke every script with a shebang after c102b704edb5. Windows itself provides a `python3.exe` app execution alias[1], but it is some sort of reparse point that MSYS is incapable of handling[2]. When run by MSYS, it simply prints $ python3 -V - Cannot open That in turn caused every `hghave` check, and test that invokes shebang scripts directly, to fail. Rather than try to patch up every script call to be invoked with `$PYTHON` (and regress when non Windows developers forget), copying the executable into the test binary directory with the new name just works. Since this directory is prepended to the system PATH value, it also overrides the broken execution alias. (The `_tmpbindir` is used instead of `_bindir` because the latter causes python3.exe to be copied into the repo next to hg.exe when `test-run-tests.t` runs. Something runs with this version of the executable and subsequent runs of `run-tests.py` inside `test-run-tests.t` try to copy over it while it is in use, and fail. This avoids the failures and the clutter.) I didn't conditionalize this on py3 because `python3.exe` needs to be present (for the shebangs) even when running py2 tests. It shouldn't matter to these simple scripts, and I think the intention is to make the test runner use py3 always, even if testing a py2 build. For now, still supporting py2 is helping to clean up the mess that is py3 tests. [1] https://stackoverflow.com/a/57168165 [2] https://stackoverflow.com/questions/59148628/solved-unable-to-run-python-3-7-on-windows-10-permission-denied#comment104524397_59148666 Differential Revision: https://phab.mercurial-scm.org/D9543

run-tests: fix a typo in an attribute name At least, I assume it's a typo. Nothing else uses it, but `_tmpbindir` is used. Differential Revision: https://phab.mercurial-scm.org/D9542

test-extension: flush diagnostic message to stabilize chg output Since chg server may create new file object for the attached stdout, procutil.stdout is not ui.fout and the buffered procutil.stdout data wouldn't be flushed at all. That's why test-extension.t passes without modification on Python 2.