fsmonitor: handle unicode keys in tuples In Python 3, keys in the bset tuple are typically str, not bytes. PyBytes_AsString() would return NULL. But we weren't checking the return value and this would lead to a segfault. This commit makes the code type and Python version aware. The Python version specific code is to allow us to utilize a modern API for converting str -> char* without having to allocate an extra PyObject. FWIW I wanted to assume that keys were always str. However, there appear to be some bytes keys in some cases. I haven't debugged this further. Differential Revision: https://phab.mercurial-scm.org/D7210

fsmonitor: make _hashignore compatible with Python 3 The Hasher wants a bytes but we were feeding it a str. Let's use our repr() implementation to return bytes. In addition, the hexdigest() would return a str, which would be compared against a bytes and would always fail. Normalize to bytes so the compare works. Differential Revision: https://phab.mercurial-scm.org/D7209

fsmonitor: normalize hostname to bytes Without this, we get a str/bytes mismatching when using % formatting a few lines below. Differential Revision: https://phab.mercurial-scm.org/D7208

fsmonitor: access repo.root There is no repo._root. It looks like fsmonitor has been busted since this access was introduced in ab1900323b1 in July 2019! Differential Revision: https://phab.mercurial-scm.org/D7207

fsmonitor: coerce watchman exception to bytes Without this, we get errors due to passing str to a function which expects bytes. Differential Revision: https://phab.mercurial-scm.org/D7206

fsmonitor: fix str/bytes mismatch when accessing watchman version There were 2 bugs here. First, keys in the tuple are always str. Second, we needed to normalize the value to bytes to prevent a str/bytes mismatch on Python 3. With this commit, `hg debuginstall` with fsmonitor enabled now works on Python 3. Differential Revision: https://phab.mercurial-scm.org/D7205

fsmonitor: reapply b1f62cd39b5c The recent revendoring of pywatchman undid this changeset. Let's reapply it. This commit was generated by running `hg graft -f b1f62cd39b5c`. It applied cleanly. Differential Revision: https://phab.mercurial-scm.org/D7204

fsmonitor: reapply dd35abc409ee The recent revendoring of pywatchman undid this bug fix. Let's reapply it. Differential Revision: https://phab.mercurial-scm.org/D7203

fsmonitor: remove pywatchman from exclusion rule The recently vendored pywatchman code base is now formatted with black. We can now remove pywatchman from our black exclusion rule. Differential Revision: https://phab.mercurial-scm.org/D7202

fsmonitor: refresh pywatchman with upstream This commit vendors pywatchman commit 259dc66dc9591f9b7ce76d0275bb1065f390c9b1 from upstream without modifications. The previously vendored pywatchman from changeset 16f4b341288d was from Git commit c77452. This commit effectively undoes the following Mercurial changesets: * dd35abc409ee fsmonitor: correct an error message * b1f62cd39b5c fsmonitor: layer on another hack in bser.c for os.stat() compat (issue5811) * c31ce080eb75 py3: convert arguments, cwd and env to native strings when spawning subprocess * 876494fd967d cleanup: delete lots of unused local variables * 57264906a996 watchman: add the possibility to set the exact watchman binary location The newly-vendored code has support for specifying the binary location, so 57264906a996 does not need applied. But we do need to modify our code to specify a proper argument name. 876494fd967d is not important, so it will be ignored. c31ce080eb75 globally changed the code base to always pass str to subprocess. But pywatchman's code is Python 3 clean, so we don't need to do this. This leaves dd35abc409ee and b1f62cd39b5c, which will be re-applied in subsequent commits. Differential Revision: https://phab.mercurial-scm.org/D7201