rust-cpython: use PyList.insert() instead of .insert_item() Silences the deprecated warning. https://github.com/dgrunwald/rust-cpython/commit/e8cbe864841714c5555db8c90e057bd11e360c7f

rust-cpython: bump cpython to 0.4 to switch to upstreamed PySharedRef

rust: update dependencies For no particular reason, but just because I'll bump the rust-cpython version.

Added signature for changeset 7f5410dfc8a6

Added tag 5.3 for changeset 7f5410dfc8a6

rust-dirstatemap: add missing @propertycache While investigating a regression on `hg update` performance introduced by the Rust `dirstatemap`, two missing `@propertycache` were identified when comparing against the Python implementation. This adds back the first one, that has no observable impact on behavior. The second one (`nonnormalset`) is going to be more involved, as the caching has to be done from the Rust side of things. Differential Revision: https://phab.mercurial-scm.org/D8047

worker: Use buffered input from the pickle stream On Python 3, "pickle.load" will raise an exception ("_pickle.UnpicklingError: pickle data was truncated") when it gets a short read, i.e. it receives fewer bytes than it requested. On our build machine, Mercurial seems to frequently hit this problem while updating a mozilla-central clone iff it gets scheduled in batch mode. It is easy to trigger with: #wipe the workdir rm -rf * hg update null chrt -b 0 hg update default I've also written the following program, which demonstrates the core problem: from __future__ import print_function import io import os import pickle import time obj = {"a": 1, "b": 2} obj_data = pickle.dumps(obj) assert len(obj_data) > 10 rfd, wfd = os.pipe() pid = os.fork() if pid == 0: os.close(rfd) for _ in range(4): time.sleep(0.5) print("First write") os.write(wfd, obj_data[:10]) time.sleep(0.5) print("Second write") os.write(wfd, obj_data[10:]) os._exit(0) try: os.close(wfd) rfile = os.fdopen(rfd, "rb", 0) print("Reading") while True: try: obj_copy = pickle.load(rfile) assert obj == obj_copy except EOFError: break print("Success") finally: os.kill(pid, 15) The program reliably fails with Python 3.8 and succeeds with Python 2.7. Providing the unpickler with a buffered reader fixes the issue, so let "os.fdopen" create one. https://bugzilla.mozilla.org/show_bug.cgi?id=1604486 Differential Revision: https://phab.mercurial-scm.org/D8051

packaging: lowercase the `contrib` and `templates` directories with Inno I have no idea why these (and `contrib/vim`) were leading with uppercase with Inno, but not WiX. It probably doesn't matter too much, but might be a problem with `templates` if the user enabled case sensitivity on NTFS. Differential Revision: https://phab.mercurial-scm.org/D8063

packaging: merge the requirements.txt files for WiX and Inno Now that the content is common, there's no need to have separate files. The content still differs from the non-Windows platforms though. Differential Revision: https://phab.mercurial-scm.org/D8066

packaging: bundle dulwich, keyring, and pywin32-ctypes with WiX too TortoiseHg installs these, which is possibly where they originated (though I would have thought it more likely to be in the WiX installer, given its heritage). When I was working on the TortoiseHg app for Mac (which uses the similar `py2app`), it wasn't possible to use the keyring extension (even externally) without bundling this keyring package into the app. Assuming the same principle applies here, these would enable some common extensions. One of the things that the TortoiseHg packager on macOS does now is it adds the user's local `site-packages` directory to `sys.path`. That would allow the user to install these critical modules in cases like this. But that can probably wait for py3 packaging. The only difference in the installed packages that I see now is WiX also bundles distutils for some reason. I suppose that's not harming anything, so I'm not touching it. The only orphans in the install directories when comparing WiX and Inno now is the Copying.txt vs COPYING.rtf, the two uninstaller files for Inno, and a `Mercurial.url` file in Inno. I have no idea what that is, and it has *.ini syntax with a single field pointing to the Mercurial homepage. Differential Revision: https://phab.mercurial-scm.org/D8062