Tue, 19 Nov 2019 23:16:16 +0900 rust-cpython: import utils::files::* function at module level stable
Yuya Nishihara <yuya@tcha.org> [Tue, 19 Nov 2019 23:16:16 +0900] rev 43867
rust-cpython: import utils::files::* function at module level IIRC, it's common in Rust to call functions with the module prefix. Differential Revision: https://phab.mercurial-scm.org/D7613
Mon, 18 Nov 2019 17:37:59 +0100 py3: send bytes from Rust-created warning patterns stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 18 Nov 2019 17:37:59 +0100] rev 43866
py3: send bytes from Rust-created warning patterns Python code expects bytes in both Python 2 and Python 3, so we should send bytes. Differential Revision: https://phab.mercurial-scm.org/D7612
Mon, 18 Nov 2019 17:34:44 +0100 py3: pass bytes to `configint` and `configbool` stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 18 Nov 2019 17:34:44 +0100] rev 43865
py3: pass bytes to `configint` and `configbool` Both functions require bytes, even in Python 3. Differential Revision: https://phab.mercurial-scm.org/D7611
Sun, 10 Nov 2019 07:30:14 -0800 rust-threads: force Rayon to respect the worker count in config stable
Raphaël Gomès <rgomes@octobus.net> [Sun, 10 Nov 2019 07:30:14 -0800] rev 43864
rust-threads: force Rayon to respect the worker count in config As per the inline comment, this is a workaround because Rust code does not yet know how to read config files. Differential Revision: https://phab.mercurial-scm.org/D7610
Thu, 12 Dec 2019 15:55:25 +0100 rust-dirs: handle forgotten `Result`s
Raphaël Gomès <rgomes@octobus.net> [Thu, 12 Dec 2019 15:55:25 +0100] rev 43863
rust-dirs: handle forgotten `Result`s In 1fe2e574616e I introduced a temporary bugfix to align Rust code with a new behavior from C/Python and forgot about a few `Result`s (cargo's compiler cache does not re-emit warnings on cached modules). This fixes it. For the record, I am still unsure that this behavior change is a good idea. Note: I was already quite unhappy with the setters and getters for the `DirstateMap` and, indirectly, `Dirs`, and this only further reinforces my feelings. I hope we can one day fix that situation at the type level; Georges Racinet and I were just talking about devising a POC for using the builder pattern in the context of FFI with Python, we'll see what comes out of it. Differential Revision: https://phab.mercurial-scm.org/D7609
Fri, 13 Dec 2019 09:43:43 -0800 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 13 Dec 2019 09:43:43 -0800] rev 43862
merge with stable
Mon, 09 Dec 2019 22:24:58 -0800 status: outputting structured unfinished-operation information
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Mon, 09 Dec 2019 22:24:58 -0800] rev 43861
status: outputting structured unfinished-operation information This adds a new item in the json/template output for morestatus and added item types to all entries. Differential Revision: https://phab.mercurial-scm.org/D7595
Thu, 05 Dec 2019 14:28:21 -0800 chg: fix chg to work with py3.7+ "coercing" the locale
Kyle Lippincott <spectral@google.com> [Thu, 05 Dec 2019 14:28:21 -0800] rev 43860
chg: fix chg to work with py3.7+ "coercing" the locale When the environment is empty (specifically: it doesn't contain LC_ALL, LC_CTYPE, or LANG), Python will "coerce" the locale environment variables to be a UTF-8 capable one. It sets LC_CTYPE in the environment, and this breaks chg, since chg operates by: - start hg, using whatever environment the user has when chg starts - hg stores a hash of this "original" environment, but python has already set LC_CTYPE even though the user doesn't have it in their environment - chg calls setenv over the commandserver. This clears the environment inside of hg and sets it to be exactly what the environment in chg is (without LC_CTYPE). - chg calls validate to ensure that the environment hg is using (after the setenv call) is the one that the chg process has - if not, it is assumed the user changed their environment and we should use a different server. This will *never* be true in this situation because LC_CTYPE was removed. Differential Revision: https://phab.mercurial-scm.org/D7550
Mon, 09 Dec 2019 22:20:35 -0500 fuzz: add support for fuzzing under either Python 2 or 3
Augie Fackler <augie@google.com> [Mon, 09 Dec 2019 22:20:35 -0500] rev 43859
fuzz: add support for fuzzing under either Python 2 or 3 This was more of a hairball than I hoped, but it appears to work. The hg-py3 branch of my oss-fuzz fork on github has the remaining changes to switch us to Python 3, but we may as well retain Python 2 fuzzing support for at least a little while. Differential Revision: https://phab.mercurial-scm.org/D7592
Fri, 22 Nov 2019 23:43:59 -0500 phabricator: color the status in the "phabstatus" view
Matt Harbison <matt_harbison@yahoo.com> [Fri, 22 Nov 2019 23:43:59 -0500] rev 43858
phabricator: color the status in the "phabstatus" view I couldn't figure out strikethrough for "abandoned" like I've see with word diff. Differential Revision: https://phab.mercurial-scm.org/D7608
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip