Mercurial > hg
view tests/test-status-eacces.t @ 51815:460e80488cf0
typing: lock in correct changes from pytype 2023.04.11 -> 2023.06.16
There were a handful of other changes to the pyi files generated when updating
pytype locally (and jumping from python 3.8.0 to python 3.10.11), but they were
not as clear (e.g. the embedded type in a list changing from `nothing` to `Any`
or similar). These looked obviously correct, and agreed with PyCharm's thoughts
on the signatures.
Oddly, even though pytype starting inferring `obsutil._getfilteredreason()` as
returning bytes, it (correctly) complained about the None path when it was typed
that way. Instead, raise a ProgrammingError if an unhandled fate is calculated.
(Currently, all possibilities are handled, so this isn't reachable unless
another fate is added in the future.)
author | Matt Harbison <matt_harbison@yahoo.com> |
---|---|
date | Tue, 20 Aug 2024 18:30:47 -0400 |
parents | 86d2a28c018e |
children | fdb1971bf634 |
line wrap: on
line source
#testcases dirstate-v1 dirstate-v2 #if dirstate-v2 $ cat >> $HGRCPATH << EOF > [format] > use-dirstate-v2=1 > [storage] > dirstate-v2.slow-path=allow > EOF #endif The proliferation of status implementations can be confusing: - The pure python implementation: (no-rhg pure !) - The C implementation: (no-rhg no-rust no-pure !) - The two rust implementations: (rhg !) (no-rhg rust !) $ hg init repo1 $ cd repo1 $ mkdir d1 $ touch d1/x $ hg commit -Am. adding d1/x $ touch d1/y $ chmod -r d1 $ hg status d1: $EACCES$ ! d1/x (rhg !) ! d1/x (no-rhg rust !) $ hg status d1: $EACCES$ ! d1/x (rust !) ! d1/x (no-rust rhg !) $ chmod +r d1 $ hg status ? d1/y $ touch d1/z $ hg status ? d1/y ? d1/z