infinitepush: move the extension to core from fb-hgext This patch moves the infinitepush extension from fb-hgext to core. The extension is used to store incoming bundles during a push in bundlestore rather than applying them to the revlog. The extension was copied from the repository revision at f27f094e91553d3cae5167c0b1c42ae940f888d5 and following changes were made: * added `from __future__ import absolute_import` where missing * fixed module imports to follow the core style * minor fixes for test-check-code.t * registered the configs * adding the testedwith value to match core's convention * removed double newlines to make test-check-commit.t happy * added one line doc about extension and marked it as experimental Only one test file test-infinitepush-bundlestore.t is moved to core and following changes are made to file: * remove dependency of library.sh * split the tests into two tests i.e. test-infinitepush.t and test-infinitepush-bundlestore.t * removed testing related to other facebook's extensions pushrebase, inhibit, fbamend library-infinitepush.sh is also copied from fb-hgext from the same revision and following changes are made: * change the path to infinitepush extension as it's in core with this patch * removed sql handling from the file as we are not testing that initially Currently at this revision, test-check-module-imports.t does not pass as there is import of a module from fb/hgext in one the of the file which will be removed in the next patch. This extension right now has a lot of things which we don't require in core like `--to`, `--create` flags to `hg bookmark`, logic related to remotenames extension and another facebook's extensions, custom bundle2parts which can be prevented by using bookmarks bundle part and also logic related to sql store which is probably we don't want initially. The next patches in this series will remove all the unwanted and unrequired things from the extension and will make this a nice one. The end goal is to have a very lighweight extension with no or very less wrapping on the client side. Differential Revision: https://phab.mercurial-scm.org/D2096

narrow: use repo.local() instead of isinstance() Differential Revision: https://phab.mercurial-scm.org/D2973

tests: add zope.interface to clang-format ignore list Differential Revision: https://phab.mercurial-scm.org/D2975

contrib: rename clang-format-blacklist to clang-format-ignorelist "blacklist" is racially charged. Let's rename it to something that isn't. Differential Revision: https://phab.mercurial-scm.org/D2974

fix: new extension for automatically modifying file contents This change implements most of the corresponding proposal as discussed at the 4.4 and 4.6 sprints: https://www.mercurial-scm.org/wiki/AutomaticFormattingPlan This change notably does not include parallel execution of the formatter/fixer tools. It does allow for implementing that without affecting other areas of the code. I believe the test coverage to be good, but this is a hotbed of corner cases. Differential Revision: https://phab.mercurial-scm.org/D2897

tests: ignore zope packages when running pyflakes Differential Revision: https://phab.mercurial-scm.org/D2972

repository: define interface for local repositories Per discussions on the mailing list and at the 4.4 and 4.6 sprints, we want to start defining interfaces for local repository primitives so that we a) have a better idea of what the formal interface for various types is b) can more easily introduce alternate implementations of various components (e.g. in Rust). We have previously implemented interfaces that declare the peer and wire protocol APIs using the abc module. This commit introduces a monolithic interface for the localrepository class. It uses zope.interface - not abc - for defining and declaring the interface. The newly defined "completelocalrepository" interface is objectively horrible. It is based on what is actually in localrepository and doesn't represent a reasonable interface definition IMO. There's lots of... unwanted garbage in the interface. In other words, it reflects the horrible state of the localrepository "god object." But this is fine: a goal of this commit is to get the interface defined so that we have an interface. Future commits can refactor the interface into sub-interfaces, remove unwanted public attributes, etc. I attempted to define reasonable docstrings for the various interface members. But there are so many of them and I didn't know what some are used for. So I was lazy in a number of places and didn't write docstrings or detailed usage docs. Also, the members of the interface are defined in the order they are declared in localrepo.py. This revealed that the grouping of things in localrepo.py is... odd. The localrepository class now declares that it implements our newly defined interface. Unlike abc, zope.interface doesn't check interface conformance at type creation time (abc uses __metaclass__ magic to validate interface conformance when a type is created - usually at module import time). It does provide some functions for validating class and object conformance with declared interfaces. We add these checks to test-check-interfaces.py. We /could/ validate at run-time. But we hold off for now. (I'm a bit scared of doing that because of the various ways extensions monkeypatch repo instances.) After this commit, test-check-interfaces.py will fail if the set of public attributes on the localrepository class or instances change without corresponding updates to the interface. This is by design. Differential Revision: https://phab.mercurial-scm.org/D2933

setup: register zope.interface packages and compile C extension With this change, we should be able to use zope.interface in core! Differential Revision: https://phab.mercurial-scm.org/D2932

thirdparty: allow zope.interface.advice to be lazily imported The symbol from this module is only used in functions. Let's access that symbol through its imported module so importing zope.interface.advice can be lazy. Differential Revision: https://phab.mercurial-scm.org/D2931

thirdparty: port zope.interface to relative imports By using relative imports, we're guaranteed to get modules vendored with Mercurial rather than other random modules that might be in sys.path. My editor strips trailing whitespace on save. So some minor source code cleanup was also performed as part of this commit. # no-check-commit because some modified lines have double newlines Differential Revision: https://phab.mercurial-scm.org/D2930