Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 23:48:45 -0500] rev 44208
resourceutil: correct the root path for file based lookup under py2exe
This silly copy/paste error caused "Mercurial" to be truncated from
"C:\Program Files". The fact that "helptext" and "defaultrc" are now in a
subpackage of "mercurial" added it back on, and everything seemed to work. But
that broke if not installed to the default directory, and also caused TortoiseHg
to look at Mercurial's config files instead of its own.
Differential Revision: https://phab.mercurial-scm.org/D8054
Yuya Nishihara <yuya@tcha.org> [Tue, 22 Oct 2019 16:04:34 +0900] rev 44207
rust-cpython: mark all PyLeaked methods as unsafe
Unfortunately, these methods can be abused to obtain the inner 'static
reference. The simplest (pseudo-code) example is:
let leaked: PyLeaked<&'static _> = shared.leak_immutable();
let static_ref: &'static _ = &*leaked.try_borrow(py)?;
// PyLeakedRef::deref() tries to bound the lifetime to itself, but
// the underlying data is a &'static reference, so the returned
// reference can be &'static.
This problem can be easily fixed by coercing the lifetime, but there are
many other ways to achieve that, and there wouldn't be a generic solution:
let leaked: PyLeaked<&'static [_]> = shared.leak_immutable();
let leaked_iter: PyLeaked<slice::Iter<'static, _>>
= unsafe { leaked.map(|v| v.iter()) };
let static_slice: &'static [_] = leaked_iter.try_borrow(py)?.as_slice();
So basically I failed to design the safe borrowing interface. Maybe we'll
instead have to add much more restricted interface on top of the unsafe
PyLeaked methods? For instance, Iterator::next() could be implemented if
its Item type is not &'a (where 'a may be cheated.)
Anyway, this seems not an easy issue, so it's probably better to leave the
current interface as unsafe, and get broader comments while upstreaming this
feature.
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.
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.
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.
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().
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
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