Sun, 28 May 2017 17:36:01 +0900 filterpyflakes: allow reexporting pure symbols from cffi modules
Yuya Nishihara <yuya@tcha.org> [Sun, 28 May 2017 17:36:01 +0900] rev 32543
filterpyflakes: allow reexporting pure symbols from cffi modules cffi modules will do 'from ..pure.<module> import *'.
Tue, 02 May 2017 22:28:18 +0900 import-checker: guess names of C extension modules
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 22:28:18 +0900] rev 32542
import-checker: guess names of C extension modules Since extension modules aren't included in the list of source files, they need to be populated somehow. Otherwise the import from cext/cffi would be treated as a global one.
Sun, 28 May 2017 15:21:18 +0900 import-checker: convert localmods to a set of module names
Yuya Nishihara <yuya@tcha.org> [Sun, 28 May 2017 15:21:18 +0900] rev 32541
import-checker: convert localmods to a set of module names This makes it easy to add a source-less module name to the set.
Tue, 02 May 2017 22:24:57 +0900 import-checker: allow importing symbols from pure modules
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 22:24:57 +0900] rev 32540
import-checker: allow importing symbols from pure modules This allows us to re-export pure functions from cffi modules: # mercurial/cffi/base85.py from ..pure.base85 import *
Tue, 02 May 2017 21:08:38 +0900 cffi: put compiled modules into mercurial.cffi package
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 21:08:38 +0900] rev 32539
cffi: put compiled modules into mercurial.cffi package Don't pollute the top-level namespace.
Tue, 02 May 2017 21:04:40 +0900 cffi: rename build scripts
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 21:04:40 +0900] rev 32538
cffi: rename build scripts This frees up cffi package for modules to be split from pure.
Fri, 19 May 2017 11:44:05 -0700 match: remove support for includes from patternmatcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 11:44:05 -0700] rev 32537
match: remove support for includes from patternmatcher Includes (and excludes) are now delegated to the includematcher.
Mon, 22 May 2017 23:31:15 -0700 match: simplify includematcher a bit
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 May 2017 23:31:15 -0700] rev 32536
match: simplify includematcher a bit The "include" we have in symbols is redundant and the double negative in visitdir() can be removed.
Fri, 19 May 2017 13:36:34 -0700 match: remove support for non-include patterns from includematcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 13:36:34 -0700] rev 32535
match: remove support for non-include patterns from includematcher The includematcher will always get at least one include pattern and will never get any non-include patterns, so we can remove most of the code in it. This patch does mostly straight-forward deletions of code. We will clean up further later.
Fri, 19 May 2017 22:36:14 -0700 match: split up main matcher into patternmatcher and includematcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 22:36:14 -0700] rev 32534
match: split up main matcher into patternmatcher and includematcher At this point the includematcher is an exact copy of the main matcher class. We will specialize and simplify both classes in the following patches. This initial unmodified copy is just to make the differences clearer. We also rename the main matcher to "patternmatcher" for consistency. I may eventually merge this new includematcher back into the main matcher, but I think doing it this way makes the intermediate steps clearer regardless.
Thu, 18 May 2017 23:39:39 -0700 match: remove support for exact matching from main matcher class
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 May 2017 23:39:39 -0700] rev 32533
match: remove support for exact matching from main matcher class Exact matching is now handled by the exactmatcher class. We can safely remove _files from the __repr__() implementation, because even though the field is set, the patternspat field is enough for the representation to be unambiguous (which was not the case when the matcher could handle exact matches).
Wed, 17 May 2017 09:26:15 -0700 match: handle exact matching using new exactmatcher
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 May 2017 09:26:15 -0700] rev 32532
match: handle exact matching using new exactmatcher
Fri, 12 May 2017 16:33:33 -0700 merge: use intersectmatchers() in "m2-vs-ma optimization"
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 May 2017 16:33:33 -0700] rev 32531
merge: use intersectmatchers() in "m2-vs-ma optimization" It doesn't seem like this can actually happen, but seems like cleaner anyway.
Fri, 12 May 2017 23:12:05 -0700 match: handle includes using new intersectionmatcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 May 2017 23:12:05 -0700] rev 32530
match: handle includes using new intersectionmatcher
Thu, 25 May 2017 14:32:56 -0700 match: move entire uipath() implementation to basematcher
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 May 2017 14:32:56 -0700] rev 32529
match: move entire uipath() implementation to basematcher Even though most matchers will always want to use the relative path in uipath(), when we add support for intersecting matcher, we will want to control which form to use for any kind of matcher without knowing the type (see next patch), so we need the implementation on the base class. Also rename the attribute from "pathrestricted" to "relativeuipath" since there actually are cases where we match everything but still use relative paths (like when the user runs "hg files .." from inside mercurial/).
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip