Sat, 19 Oct 2019 17:01:28 +0900 rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 17:01:28 +0900] rev 44206
rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError As I said, it shouldn't be an error of Python layer, but is something like a coding error. Returning BorrowMutError makes more sense. There's a weird hack to propagate the borrow-by-leaked state to RefCell to obtain BorrowMutError. If we don't like it, maybe we can add our own BorrowMutError.
Sat, 19 Oct 2019 16:48:34 +0900 rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new()
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:48:34 +0900] rev 44205
rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new() For the same reason as the previous patch. The unsafe stuff can be better documented if these functions are inlined.
Sat, 19 Oct 2019 16:34:02 +0900 rust-cpython: inline PySharedState::try_borrow_mut()
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:34:02 +0900] rev 44204
rust-cpython: inline PySharedState::try_borrow_mut() Since the core borrowing/leaking logic has been moved to PySharedRef* and PyLeaked*, it doesn't make sense that PySharedState had a function named "try_borrow_mut". Let's turn it into a pure data struct.
Sat, 12 Oct 2019 23:34:05 +0900 rust-cpython: add panicking version of borrow_mut() and use it
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Oct 2019 23:34:05 +0900] rev 44203
rust-cpython: add panicking version of borrow_mut() and use it The original borrow_mut() is renamed to try_borrow_mut(). Since leak_immutable() no longer incref the borrow count, the caller should know if the underlying value is borrowed or not. No Python world is involved. That's why we can simply use the panicking borrow_mut().
Tue, 28 Jan 2020 22:27:30 -0500 setup: don't skip the search for global hg.exe if there is no local instance
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:27:30 -0500] rev 44202
setup: don't skip the search for global hg.exe if there is no local instance The point of trying not to blindly execute `hg` on Windows is that the local hg.exe would be given precedence, and if py3 isn't on PATH, it errors out with a modal dialog. But that's not a problem if there is no local executable that could be run. The problem that I recently ran into was I upgraded the repo format to use zstd. But doing a `make clean` deletes all of the supporting libraries, causing the next run to abort with a message about not understanding the `revlog-compression-zstd` requirement. By getting rid of the local executable in the previous commit when cleaning, we avoid leaving a broken executable around, and avoid the py3 PATH problem too. There is still a small hole in that `hg.exe` needs to be deleted before switching between py2/py3/PyOxidizer builds, because the zstd module won't load. But that seems like good hygiene anyway. Differential Revision: https://phab.mercurial-scm.org/D8038
Tue, 28 Jan 2020 22:35:08 -0500 make: also delete hg.exe when cleaning
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:35:08 -0500] rev 44201
make: also delete hg.exe when cleaning This will be needed for the next patch, which has more details. It has to come before the call into setup.py because even `python setup.py clean` calls hg to generate the version file. Differential Revision: https://phab.mercurial-scm.org/D8037
Thu, 23 Jan 2020 15:44:30 -0800 merge: start using the per-side copy dicts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 15:44:30 -0800] rev 44200
merge: start using the per-side copy dicts The point of this patch is mostly to clarify `manifestmerge()`. I find it much easier to reason about now. Differential Revision: https://phab.mercurial-scm.org/D7990
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 tip