merge with stable

share: move share safe functionality out of experimental The share-safe functionality is complete and all configuration options are implemented. The behavior is well discussed on mailing list and in reviews. Let's unmark this as experimental to solve a chichen and egg issue. Differential Revision: https://phab.mercurial-scm.org/D9823

share: rename share-safe warning config Config introduced in previous patch was `share.source-safe-mismatch`. Let's rename the warn as `share.source-safe-mismatch.warn`. While we are here, made sure we have different configs for upgrade and downgrade. Differential Revision: https://phab.mercurial-scm.org/D9786

share: rework config options to be much clearer and easier Recently I implemented various boolean configs which control how to behave when there is a share-safe mismatch between source and share repository. Mismatch means that source supports share-safe where as share does not or vice versa. However, while discussion and documentation we realized that it's too complicated and there are some combinations of values which makes no sense. We decided to introduce a config option with 4 possible values which makes controlling and understanding things easier. The config option `share.safe-mismatch.source-{not-}safe` can have following 4 values: * abort (default): error out if there is mismatch * allow: allow to work with respecting share source configuration * {up|down}grade-abort: try to {up|down}grade, if it fails, abort * {up|down}grade-allow: try to {up|down}grade, if it fails, continue in allow mode I am not sure if I can explain 3 config options which I deleted right now in just 5 lines which is a sign of how complex they became. No test changes demonstrate that functionality is same, only names have changed. Differential Revision: https://phab.mercurial-scm.org/D9785

typing: disable processing of mercurial/upgrade_utils/actions.py There was a recent regression in pytype that causes processing to stall and consume memory, and it doesn't sound like it will be fixed any time soon. Differential Revision: https://phab.mercurial-scm.org/D10273

re2: feed unicode string to re2 module when necessary My previous test were using the `pyre2` Python project, that wrap the Google RE2 library in python as a `re2` module and accept bytes as input. However the `fb-re2` Python project is also offering a wrapping of the Google RE2 library in python as a `re2` module ans accept only unicode on python3. So we detect this situation and convert thing to unicode when necessary. Hooray… We should consider using a rust wrapping for regexp handling. We needs regexps in Rust anyway and this give use more control with less variants and more sanity. Differential Revision: https://phab.mercurial-scm.org/D10284

typing: rewrite a conditional assignment to unconfuse pytype Otherwise, pytype and PyCharm flags it: File "/mnt/c/Users/Matt/hg/mercurial/localrepo.py", line 2903, in wlock: No attribute 'held' on _weakref.ReferenceType[nothing] [attribute-error] In Optional[Union[Any, _weakref.ReferenceType[nothing]]] File "/mnt/c/Users/Matt/hg/mercurial/localrepo.py", line 2904, in wlock: No attribute 'lock' on _weakref.ReferenceType[nothing] [attribute-error] In Optional[Union[Any, _weakref.ReferenceType[nothing]]] Differential Revision: https://phab.mercurial-scm.org/D10215

typing: add assertions to localrepo.py to appease pytype Differential Revision: https://phab.mercurial-scm.org/D10214

obsutil: maintain a homogenous list when computing successors In practice, this wasn't a problem because of an internal check for an empty list, but it avoids the following pytype error: File "/mnt/c/Users/Matt/hg/mercurial/obsutil.py", line 823, in successorsandmarkers: No attribute 'markers' on List[nothing] [attribute-error] In Union[Any, List[nothing], _succs] Differential Revision: https://phab.mercurial-scm.org/D10213

typing: add an assertion to verify.py to appease pytype Differential Revision: https://phab.mercurial-scm.org/D10212