Tue, 22 Oct 2019 10:01:48 -0400 censor: document that some commands simply ignore censored data
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 22 Oct 2019 10:01:48 -0400] rev 43434
censor: document that some commands simply ignore censored data I can't see a benefit for hg grep to ever error out early when it encounters censored data.
Tue, 22 Oct 2019 09:56:40 -0400 grep: warn on censored revisions instead of erroring out
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 22 Oct 2019 09:56:40 -0400] rev 43433
grep: warn on censored revisions instead of erroring out We need most of the grep logic to go through in case we encounter a censored revision, so we just return a None body for a censored node, and we stop just short of trying to record matches with the contents of that censored body. The other parts such as recording that the censored file has been considered at this revision needs to go into the proper dicts. I have also gotten weary of all the abbreviations, so while I did a small refactor to move the file-data-getting operation into a common function, I also expanded the abbreviations of the relevant variables within this little function. Hopefully some day this helps someone figure out what all the abbreviations mean. Although the censoring docs currently state that some commands error out or are ignored depending on the `censor.policy` config, I cannot see a benefit for grep to ever stop dead in its tracks when a censored revision is encountered. I will also amend the docs to indicate that some commands, such as grep, unconditionally ignore censored revisions.
Tue, 15 Oct 2019 22:44:55 +0900 py3: enable legacy fs encoding to fix filename compatibility on Windows
Yuya Nishihara <yuya@tcha.org> [Tue, 15 Oct 2019 22:44:55 +0900] rev 43432
py3: enable legacy fs encoding to fix filename compatibility on Windows This patch is untested. I just followed the instruction: https://docs.python.org/3/whatsnew/3.6.html#pep-529-change-windows-filesystem-encoding-to-utf-8
Sat, 19 Oct 2019 14:30:19 +0900 rust-cpython: run cargo fmt
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 14:30:19 +0900] rev 43431
rust-cpython: run cargo fmt
Sat, 05 Oct 2019 09:33:01 -0400 rust-cpython: remove useless PyResult<> from leak_immutable()
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 09:33:01 -0400] rev 43430
rust-cpython: remove useless PyResult<> from leak_immutable() The caller should know if the shared data is mutably borrowed or not.
Sat, 05 Oct 2019 09:01:25 -0400 rust-cpython: remove useless PyRefMut wrapper
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 09:01:25 -0400] rev 43429
rust-cpython: remove useless PyRefMut wrapper
Sat, 05 Oct 2019 08:59:09 -0400 rust-cpython: drop manual management of mutably_borrowed
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 08:59:09 -0400] rev 43428
rust-cpython: drop manual management of mutably_borrowed RefCell::borrow() should guarantee there's no mutable borrow. As a follow up, maybe PySharedState can be a pure data structure + function. Most ref-sharing business has already been moved to PySharedRef* and PyLeaked*.
Sat, 05 Oct 2019 08:56:15 -0400 rust-cpython: leverage RefCell::borrow() to guarantee there's no mutable ref
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 08:56:15 -0400] rev 43427
rust-cpython: leverage RefCell::borrow() to guarantee there's no mutable ref Since the underlying value can't be mutably borrowed by PyLeaked, we don't have to manage yet another mutably-borrowed state. We can just rely on the RefCell implementation. Maybe we can add try_leak_immutable(), but this patch doesn't in order to keep the patch series not too long.
Sat, 12 Oct 2019 20:48:30 +0900 rust-cpython: remove useless Option<$leaked> from py_shared_iterator
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Oct 2019 20:48:30 +0900] rev 43426
rust-cpython: remove useless Option<$leaked> from py_shared_iterator We no longer need to carefully drop the iterator when it's consumed. Mutation is allowed even if the iterator exists. There's a minor behavior change: next(iter) may return/raise something other than StopIteration if it's called after the iterator has been fully consumed, and if the Rust object isn't a FusedIterator.
Sat, 12 Oct 2019 20:26:38 +0900 rust-cpython: allow mutation unless leaked reference is borrowed
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Oct 2019 20:26:38 +0900] rev 43425
rust-cpython: allow mutation unless leaked reference is borrowed In other words, mutation is allowed while a Python iterator holding PyLeaked exists. The iterator will be invalidated instead. We still need a borrow_count to prevent mutation while leaked data is dereferenced in Rust world, but most leak_count business is superseded by the generation counter. decrease_leak_count(py, true) will be removed soon.
Sat, 05 Oct 2019 08:27:57 -0400 rust-cpython: add generation counter to leaked reference
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 08:27:57 -0400] rev 43424
rust-cpython: add generation counter to leaked reference This counter increments on borrow_mut() to invalidate existing leaked references. This is modeled after the iterator invalidation in Python. The other checks will be adjusted by the subsequent patches.
Sat, 12 Oct 2019 19:26:23 +0900 rust-cpython: add stub wrapper that'll prevent leaked data from being mutated
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Oct 2019 19:26:23 +0900] rev 43423
rust-cpython: add stub wrapper that'll prevent leaked data from being mutated In order to allow mutation of PySharedRefCell value while PyLeaked reference exists, we need yet another "borrow" scope where mutation is prohibited. try_borrow<'a> and try_borrow_mut<'a> defines the "borrow" scope <'a>. The subsequent patches will implement leak counter based on this scope. PyLeakedRef<T> and PyLeakedRefMut<T> could be unified to PyLeakedRef<&T> and PyLeakedRef<&mut T> respectively, but I didn't do that since it seemed a bit weird that deref_mut() would return a mutable reference to an immutable reference.
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 tip