extdiff: pass full paths of `dir1a` and `dir1b` to `_runperfilediff()` Earlier we were passing basename instead of the fullpath and then joining with the tmproot. This is wrong because the user can choose `rev1a` as wdir and in those cases, tmproot should not be joined with the path. I am working on refactoring extdiff logic so that we can have options like `diff --tool` and encountered this. Although this patch in itself makes no difference, however in future when a new caller of `_runperfilediff()` will be added, it will be useful to directly pass on the full paths instead. Differential Revision: https://phab.mercurial-scm.org/D8969

hgweb: compatibility of hgweb.cgi template with Python 3 When running Mercurial on Python 3 hgweb expects the config variable to be a bytestring. The solution proposed by Anton Shestakov is to use a byteprefix to the literal string defined cgi script as provided in this patch for hgweb.cgi, contrib/hgweb.fcgi and contrib/hgweb.wsgi. I am not sure whether this covers all relevant templates, but I couldn't find others. Differential Revision: https://phab.mercurial-scm.org/D8978

genosxversion: don't give up if we can't find a path to hg libraries This doesn't work if you have a PyOxidized hg on $PATH, but everything is fine if you just ignore that problem. Differential Revision: https://phab.mercurial-scm.org/D8975

tests: fix test-demandimport.py on Python 3.9 Starting with Python 3.9, importing importlib.resources (indirectly) imports the zipfile module. Therefore, the module is not suitable for the test. Instead, we can use the ftplib module, which is very unlikely to be imported during the test run.

merge with stable

Added signature for changeset f62bb5d07848

Added tag 5.5.1 for changeset f62bb5d07848

mercurial: force LF endings for *.py, *.{c,h} and *.t in .editorconfig PyCharm on Windows otherwise uses CRLF. Differential Revision: https://phab.mercurial-scm.org/D8947

hooklib: update documentation of changeset_obsoletedfor for changed hook type This updates usage example of changeset_obsoleted to reflect the move from pretxnclose to txnclose made in 04ef381000a8 (hooklib: fix detection of successors for changeset_obsoleted). Differential Revision: https://phab.mercurial-scm.org/D8929

worker: don't expose readinto() on _blockingreader since pickle is picky The `pickle` module expects the input to be buffered and a whole object to be available when `pickle.load()` is called, which is not necessarily true when we send data from workers back to the parent process (i.e., it seems like a bad assumption for the `pickle` module to make). We added a workaround for that in https://phab.mercurial-scm.org/D8076, which made `read()` continue until all the requested bytes have been read. As we found out at work after a lot of investigation (I've spent the last two days on this), the native version of `pickle.load()` has started calling `readinto()` on the input since Python 3.8. That started being called in https://github.com/python/cpython/commit/91f4380cedbae32b49adbea2518014a5624c6523 (and only by the C version of `pickle.load()`)). Before that, it was only `read()` and `readline()` that were called. The problem with that was that `readinto()` on our `_blockingreader` was simply delegating to the underlying, *unbuffered* object. The symptom we saw was that `hg fix` started failing sometimes on Python 3.8 on Mac. It failed very relyable in some cases. I still haven't figured out under what circumstances it fails and I've been unable to reproduce it in test cases (I've tried writing larger amounts of data, using different numbers of workers, and making the formatters sleep). I have, however, been able to reproduce it 3-4 times on Linux, but then it stopped reproducing on the following few hundred attempts. To fix the problem, we can simply remove the implementation of `readinto()`, since the unpickler will then fall back to calling `read()`. The fallback was added a bit later, in https://github.com/python/cpython/commit/b19f7ecfa3adc6ba1544225317b9473649815b38. However, that commit also added checking that what `read()` returns is a `bytes`, so we also need to convert the `bytearray` we use into that. I was able to add a test for that failure at least. Differential Revision: https://phab.mercurial-scm.org/D8928