Fri, 16 Jan 2015 14:58:06 -0800 trydiff: move git-header code out of diffline function
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:58:06 -0800] rev 24020
trydiff: move git-header code out of diffline function This collects more of the code for writing git headers in a single place and makes diffline() close on a few variables less.
Tue, 27 Jan 2015 09:22:59 -0500 _fm1readmarkers: generate list in C
Martin von Zweigbergk <martinvonz@google.com> [Tue, 27 Jan 2015 09:22:59 -0500] rev 24019
_fm1readmarkers: generate list in C This moves perfloadmarkers from ! result: 63866 ! wall 0.239217 comb 0.250000 user 0.240000 sys 0.010000 (best of 42) to ! result: 63866 ! wall 0.218795 comb 0.210000 user 0.210000 sys 0.000000 (best of 46)
Tue, 20 Jan 2015 13:38:07 -0500 obsolete: use parsers.fm1readmarker if it exists for a ~38% perf win
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 13:38:07 -0500] rev 24018
obsolete: use parsers.fm1readmarker if it exists for a ~38% perf win This moves perfloadmarkers on my linux workstation (63494 markers from mpm, crew, and myself) performance from ! wall 0.357657 comb 0.360000 user 0.350000 sys 0.010000 (best of 28) to ! wall 0.222345 comb 0.220000 user 0.210000 sys 0.010000 (best of 41) which is a pretty good improvement. On my BSD machine, which is ancient and slow, before: ! wall 3.584964 comb 3.578125 user 3.539062 sys 0.039062 (best of 3) after: ! wall 2.267974 comb 2.265625 user 2.195312 sys 0.070312 (best of 5) I feel like we could do better by moving the whole generator function into C, but I didn't want to tackle that right away.
Fri, 23 Jan 2015 15:11:25 -0500 parsers: add fm1readmarker
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:11:25 -0500] rev 24017
parsers: add fm1readmarker This lets us do most of the interesting work of parsing obsolete markers in C, which should provide significant time savings. Thanks to Martin von Zweigbergk for some cleanups on this code.
Tue, 03 Feb 2015 13:17:21 -0500 util: add getbefloat64
Augie Fackler <augie@google.com> [Tue, 03 Feb 2015 13:17:21 -0500] rev 24016
util: add getbefloat64 As far as I can tell, this is wrong. double's format isn't strictly specified in the C standard, but the wikipedia article implies that platforms implementing optional Annex F "IEC 60559 floating-point arithmetic" will work correctly. My local C experts believe doing *((double *) &t) is a strict aliasing violation, and that using a union is also one. Doing memcpy appears to be the least-undefined behavior possible.
Tue, 20 Jan 2015 14:09:57 -0500 util: add getbe{u,}int16 utility methods
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 14:09:57 -0500] rev 24015
util: add getbe{u,}int16 utility methods
Tue, 20 Jan 2015 09:38:22 -0500 obsolete: make optional offset parameter to fm*readmarkers required
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 09:38:22 -0500] rev 24014
obsolete: make optional offset parameter to fm*readmarkers required It was always passed by the only callsite, so just make it required.
Mon, 02 Feb 2015 14:26:47 -0500 log: fix json-formatted output when file copies are listed (issue4523) stable
Augie Fackler <augie@google.com> [Mon, 02 Feb 2015 14:26:47 -0500] rev 24013
log: fix json-formatted output when file copies are listed (issue4523)
Tue, 03 Feb 2015 17:54:01 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 03 Feb 2015 17:54:01 -0600] rev 24012
merge with stable
Tue, 27 Jan 2015 17:24:12 -0800 copy: move _forwardcopies file logic to a function
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 17:24:12 -0800] rev 24011
copy: move _forwardcopies file logic to a function Moves the _forwardcopies missingfiles logic to a separate function so that other extensions which need to prefetch information about the files being processed have a hook point. This saves extensions from having to recompute this information themselves, and thus saves several seconds off of various commands (like rebase).
Tue, 27 Jan 2015 17:23:18 -0800 copy: move mergecopies file logic to a function
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 17:23:18 -0800] rev 24010
copy: move mergecopies file logic to a function Moves the mergecopies nonoverlap logic to a separate function so that other extensions which may need to prefetch information about the files being processed have a hook point. This saves extensions from having to recompute this information themselves, and thus saves several seconds off of various commands (like rebase).
Mon, 02 Feb 2015 16:19:35 -0800 histedit: allow configuring default behavior
Durham Goode <durham@fb.com> [Mon, 02 Feb 2015 16:19:35 -0800] rev 24009
histedit: allow configuring default behavior Adds a configuration setting for allowing users to specify the default behavior of 'hg histedit' without arguments. This saves users from having to manually figure out the bottom commit or a complicated revset. My current revset of choice is "only(.) & draft() - ::merge()" The commits that histedit can work with is usually quite limited, so if this feature ends up working well, we may want to consider making "only(.) & draft() - ::merge()" the default behavior for everyone.
Tue, 03 Feb 2015 21:56:29 +0900 revset: get revision number of each node from target namespaces stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 03 Feb 2015 21:56:29 +0900] rev 24008
revset: get revision number of each node from target namespaces Before this patch, revset predicate "named()" uses each nodes gotten from target namespaces directly. This causes problems below: - combination of other predicates doesn't work correctly, because they assume that revisions are listed up in number - "hg log" doesn't show any revisions for "named()" result, because: - "changeset_printer" stores formatted output for each revisions into dict with revision number (= ctx.rev()) as a key of them - "changeset_printer.flush(rev)" writes stored output for the specified revision, but - "commands.log" invokes it with the node, gotten from "named()" - "hg debugrevspec" shows nodes (= may be binary) directly Difference between revset predicate "tag()" and "named('tags')" in tests is fixed in subsequent patch.
Sun, 01 Feb 2015 14:05:15 -0500 largefiles: update _subdirlfs() comment
Matt Harbison <matt_harbison@yahoo.com> [Sun, 01 Feb 2015 14:05:15 -0500] rev 24007
largefiles: update _subdirlfs() comment http://www.selenic.com/pipermail/mercurial-devel/2015-February/065958.html
Sat, 31 Jan 2015 00:13:29 -0500 largefiles: use the core file copy logic to validate the destination path
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Jan 2015 00:13:29 -0500] rev 24006
largefiles: use the core file copy logic to validate the destination path The destination is validated by pathutil.canonpath() for illegal components, and that it is in the repository. The logic for creating the standin directory tree was calling this before cmdutil.copy(), but without the destination file name component. The cmdutil.copy() logic also calls pathutil.canonpath(), but with the file name component. By always calling the core logic first, the error message is always consistent. Specifically, the old behavior for these tests was to say '.hg' contains an illegal component, and '..' is not under root. A user wasn't likely to notice the discrepancy, but this eliminates a needless difference when running the test suite with --config extensions.largefiles=.
Fri, 16 Jan 2015 15:40:59 -0800 trydiff: inline indexmeta()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:40:59 -0800] rev 24005
trydiff: inline indexmeta() The function is trivial and is only called in one place.
Fri, 23 Jan 2015 14:09:49 -0800 parsers: rewrite index_ancestors() in terms of index_commonancestorsheads()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 23 Jan 2015 14:09:49 -0800] rev 24004
parsers: rewrite index_ancestors() in terms of index_commonancestorsheads() The first 80% of index_ancestors() is identical to index_commonancestorsheads(), so just call that function instead.
Thu, 22 Jan 2015 11:09:34 -0500 filelog: remove unused _file method
Mike Edgar <adgar@google.com> [Thu, 22 Jan 2015 11:09:34 -0500] rev 24003
filelog: remove unused _file method
Mon, 26 Jan 2015 15:18:07 -0800 histedit: store full node hash in rules
Mateusz Kwapich <mitrandir@fb.com> [Mon, 26 Jan 2015 15:18:07 -0800] rev 24002
histedit: store full node hash in rules Previously histedit only stored the short version of the rule nodes in the state. This meant that later we couldn't resolve a rule node to its full form if the commit had been deleted from the repo. Let's store the full form from the beginning.
Fri, 16 Jan 2015 14:49:08 -0800 trydiff: order header-writing code in same order as output
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:49:08 -0800] rev 24001
trydiff: order header-writing code in same order as output Instead of inserting a line before the others header lines, move the code that writes that line before the code that writes the other lines.
Fri, 16 Jan 2015 14:53:37 -0800 trydiff: inline sole addmodehdr() call
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:53:37 -0800] rev 24000
trydiff: inline sole addmodehdr() call Now that there is only a single call to addmodehdr() left, and there is other similar code (for new/deleted files) around that call site, let's inline the function there. That also makes it clearer under what circumstances the header is actually written (when modes differ).
Fri, 16 Jan 2015 14:46:03 -0800 trydiff: join filename with prefix only once
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:46:03 -0800] rev 23999
trydiff: join filename with prefix only once
Thu, 22 Jan 2015 17:00:54 -0800 trydiff: collect header-writing in one place
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jan 2015 17:00:54 -0800] rev 23998
trydiff: collect header-writing in one place This is the first step towards simplifying the big loop in trydiff(). This will make both the header code and the non-header code clearer, and it prepares for further simplification of the many nested if-statements in the body of the loop.
Fri, 16 Jan 2015 10:57:13 -0800 trydiff: make variable names more consistent
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 10:57:13 -0800] rev 23997
trydiff: make variable names more consistent Use '1' and '2' as suffix for names just like in the parameters 'ctx[12]': to,tn -> content1,content2 a,b -> f1, f2 omode,mode -> mode1,mode2 omode,nmode -> mode1,mode2 onode,nnode -> node1,node2 oflag,nflag -> flag1,flag2 oindex,nindex -> index1,index2
Fri, 16 Jan 2015 17:01:58 -0800 trydiff: check only if added file is a copy target, not source
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 17:01:58 -0800] rev 23996
trydiff: check only if added file is a copy target, not source When creating a diff with copy/rename enabled, we consider added files and check if they are either copy sources or targets. However, an added file should never be a copy source. The test suite seems to agree with this: all tests pass if we raise an exception when an added file is a copy source. So, let's simplify the code by dropping the conditions that are never true. For those interested in the historical reasons: Before commit d1f209bb9564 (patch: separate reverse copy data (issue1959), 2010-02-11), 'copy' seems to have been a bidirectional map. Then that commit split it up into two unidirectional maps and duplicated the logic to look in both maps. It was still needed at that point to look in both maps, as the copy detection was poor and could sometimes be reported in reverse. A little later came 91eb4512edd0 (copies: rewrite copy detection for non-merge users, 2012-01-04). That commit fixed the copy detection to be backwards when it should, and made the hacks in trydiff unnecessary.
Thu, 29 Jan 2015 21:12:35 -0800 trydiff: remove unused variable 'modifiedset'
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Jan 2015 21:12:35 -0800] rev 23995
trydiff: remove unused variable 'modifiedset' We started updating 'modifiedset' in a9853fc172d2 (trydiff: simplify checking for additions, 2014-12-23) but in the same commit, we removed the last use of the variable. Clean it up.
Mon, 02 Feb 2015 23:07:04 +0900 revset: replace parsing alias definition by _parsealiasdefn to parse strictly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 02 Feb 2015 23:07:04 +0900] rev 23994
revset: replace parsing alias definition by _parsealiasdefn to parse strictly Before this patch, referring alias arguments is parsed by string base operation "str.replace". This causes problems below (see the previous patch introducing "_parsealiasdefn" for detail) - the shorter name argument breaks referring the longer name - argument names in the quoted string are broken This patch replaces parsing alias definition by "_parsealiasdefn" to parse strictly.
Mon, 02 Feb 2015 23:07:04 +0900 revset: introduce _parsealiasdefn to parse alias definitions strictly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 02 Feb 2015 23:07:04 +0900] rev 23993
revset: introduce _parsealiasdefn to parse alias definitions strictly This patch introduces "_parsealiasdefn" to parse alias definitions strictly. For example, it can avoid problems below, which current implementation can't. - the shorter name argument breaks referring the longer name one in the definition, if the former is completely prefix of the latter for example, the alias definition "foo($1, $10) = $1 or $10" is parsed as "_aliasarg('$1') or _aliasarg('$1')0" and causes parse error, because tail "0" of "_aliasarg('$1')0" is invalid. - argument names in the quoted string are broken for example, the definition "foo($1) = $1 or desc('$1')" is parsed as "_aliasarg('$1') or desc('_aliasarg(\'$1\')')" and causes unexpected description matching against not '$1' but '_aliasarg(\'$1\')'. To decrease complication of patch, current implementation for alias definitions is replaced by "_parsealiasdefn" in the subsequent patch. This patch just introduces it. This patch defines "_parsealiasdefn" not as a method of "revsetalias" class but as a one of "revset" module, because of ease of testing by doctest.
Mon, 02 Feb 2015 22:28:52 +0900 hgweb: use revset.spanset where appropriate
Yuya Nishihara <yuya@tcha.org> [Mon, 02 Feb 2015 22:28:52 +0900] rev 23992
hgweb: use revset.spanset where appropriate It is remainder of 9ad6dae67845 where spanset was introduced.
Sun, 01 Feb 2015 14:09:31 +0100 subrepo: add 'cat' support for git subrepos
Mathias De Maré <mathias.demare@gmail.com> [Sun, 01 Feb 2015 14:09:31 +0100] rev 23991
subrepo: add 'cat' support for git subrepos V2: use 'self._ctx.node()' instead of 'rev' in makefileobj. As Matt Harbison mentioned, using 'rev' does not make sense, since we'd be passing a git revision to the top-level Mercurial repository.
Mon, 02 Feb 2015 12:50:48 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Feb 2015 12:50:48 -0600] rev 23990
merge with stable
Sun, 01 Feb 2015 20:21:02 -0600 Added signature for changeset fbdd5195528f stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 20:21:02 -0600] rev 23989
Added signature for changeset fbdd5195528f
Sun, 01 Feb 2015 20:20:51 -0600 Added tag 3.3 for changeset fbdd5195528f stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 20:20:51 -0600] rev 23988
Added tag 3.3 for changeset fbdd5195528f
Sun, 01 Feb 2015 18:47:04 -0600 merge with i18n stable 3.3
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 18:47:04 -0600] rev 23987
merge with i18n
Sun, 01 Feb 2015 08:24:08 +0900 i18n-ja: synchronized with 9a391d720cf9 stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Feb 2015 08:24:08 +0900] rev 23986
i18n-ja: synchronized with 9a391d720cf9
Thu, 29 Jan 2015 10:13:18 -0200 i18n-pt_BR: synchronized with 448bb32b8ee6 stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 29 Jan 2015 10:13:18 -0200] rev 23985
i18n-pt_BR: synchronized with 448bb32b8ee6
Sun, 01 Feb 2015 16:33:45 -0600 filectx: use _descendantrev in parents() stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:33:45 -0600] rev 23984
filectx: use _descendantrev in parents() This lets us be lazy about linkrev adjustments when tracing history.
Sun, 01 Feb 2015 16:26:35 -0600 filectx: if we have a _descendantrev, use it to adjust linkrev stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:26:35 -0600] rev 23983
filectx: if we have a _descendantrev, use it to adjust linkrev This lets us use _adjustlinkrev lazily.
Sun, 01 Feb 2015 16:25:12 -0600 copies: use linkrev for file tracing limit stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:25:12 -0600] rev 23982
copies: use linkrev for file tracing limit This lets us lazily evaluate _adjustlinkrev.
Sun, 01 Feb 2015 16:23:07 -0600 filectx: use linkrev to sort ancestors stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:23:07 -0600] rev 23981
filectx: use linkrev to sort ancestors We're going to make rev() lazily do _adjustlinkrevs, and we don't want that to happen when we're quickly tracing through file ancestry without caring about revs (as we do when finding copies). This takes us back to pre-linkrev-correction behavior, but shouldn't regress us relative to the last stable release.
Fri, 30 Jan 2015 16:02:28 +0000 _adjustlinkrev: reuse ancestors set during rename detection (issue4514) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 16:02:28 +0000] rev 23980
_adjustlinkrev: reuse ancestors set during rename detection (issue4514) The new linkrev adjustement mechanism makes rename detection very slow, because each file rewalks the ancestor dag. To mitigate the issue in Mercurial 3.3, we introduce a simplistic way to share the ancestors computation for the linkrev validation phase. We can reuse the ancestors in that case because we do not care about sub-branching in the ancestors graph. The cached set will be use to check if the linkrev is valid in the search context. This is the vast majority of the ancestors usage during copies search since the uncached one will only be used when linkrev is invalid, which is hopefully rare.
Fri, 30 Jan 2015 14:39:03 +0000 filectx: move _adjustlinkrev to a method stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 14:39:03 +0000] rev 23979
filectx: move _adjustlinkrev to a method We are going to introduce some wider caching mechanisms during linkrev adjustment. As there is no specific reason to not be a method and some reasons to be a method, let's make it a method.
Sat, 31 Jan 2015 01:00:50 +0900 revset: raise RepoLookupError to make present() predicate continue the query stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 31 Jan 2015 01:00:50 +0900] rev 23978
revset: raise RepoLookupError to make present() predicate continue the query Before this patch, "bookmark()", "named()" and "tag()" predicates raise "Abort", when the specified pattern doesn't match against existing ones. This prevents "present()" predicate from continuing the query, because it only catches "RepoLookupError". This patch raises "RepoLookupError" instead of "Abort", to make "present()" predicate continue the query, even if "bookmark()", "named()" or "tag()" in the sub-query of it are aborted. This patch doesn't contain raising "RepoLookupError" for "re:" pattern in "tag()", because "tag()" treats it differently from others. Actions of each predicates at failure of pattern matching can be summarized as below: predicate "literal:" "re:" ---------- ----------- ------------ bookmark abort abort named abort abort tag abort continue (*1) branch abort continue (*2) ---------- ----------- ------------ "tag()" may have to abort in the (*1) case for similarity, but this change may break backward compatibility of existing revset queries. It seems to have to be changed on "default" branch (with "BC" ?). On the other hand, (*2) seems to be reasonable, even though it breaks similarity, because "branch()" in this case doesn't check exact existence of branches, but does pick up revisions of which branch matches against the pattern. This patch also adds tests for "branch()" to clarify behavior around "present()" of similar predicates, even though this patch doesn't change "branch()".
Sun, 01 Feb 2015 09:36:47 +0900 templatekw: re-add showtags() to list tags keyword up in online help stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Feb 2015 09:36:47 +0900] rev 23977
templatekw: re-add showtags() to list tags keyword up in online help Changeset d69a7fc68ad5 removed "showtags()" definition for "tags" template keyword from "templatekw.py", because "namespaces" puts a helper function for it into template keyword map automatically. This works correctly from the point of view of templating functionality. But on the other hand, it removed "tags" template keyword from "hg help templates" unexpectedly, because online help text is built before "namespaces" puts a helper function for "tags" into template keyword map. This patch is a kind of backing d69a7fc68ad5 out, but this implements "showtags()" with newly introduced "shownames()" instead of originally used "showlist()".
Fri, 30 Jan 2015 20:44:11 -0500 largefiles: don't interfere with logging normal files stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Jan 2015 20:44:11 -0500] rev 23976
largefiles: don't interfere with logging normal files The previous code was adding standin files to the matcher's file list when neither the standin file nor the original existed in the context. Somehow, this was confusing the logging code into behaving differently from when the extension wasn't loaded. It seems that this was an attempt to support naming a directory that only contains largefiles, as a test fails if the else clause is dropped entirely. Therefore, only append the "standin" if it is a directory. This was found by running the test suite with --config extensions.largefiles=. The first added test used to log an additional cset that wasn't logged normally. The only relation it had to file 'a' is that 'a' was the source of a move, but it isn't clear why having '.hglf/a' in the list causes this change: @@ -47,6 +47,11 @@ Make sure largefiles doesn't interfere with logging a regular file $ hg log a --config extensions.largefiles= + changeset: 3:2ca5ba701980 + user: test + date: Thu Jan 01 00:00:04 1970 +0000 + summary: d + changeset: 0:9161b9aeaf16 user: test date: Thu Jan 01 00:00:01 1970 +0000 The second added test used to complain about a file not being in the parent revision: @@ -1638,10 +1643,8 @@ Ensure that largefiles doesn't intefere with following a normal file $ hg --config extensions.largefiles= log -f d -T '{desc}' -G - @ c - | - o a - + abort: cannot follow file not in parent revision: ".hglf/d" + [255] $ hg log -f d/a -T '{desc}' -G @ c | Note that there is still something fishy with the largefiles code, because when using a glob pattern like this: $ hg log 'glob:sub/*' the pattern list would contain '.hglf/glob:sub/*'. None of the tests show this (this test lives in test-largefiles.t at 1349), it was just something that I noticed when the code was loaded up with print statements.
Fri, 30 Jan 2015 21:11:02 +0000 discovery: properly exclude locally known but filtered heads stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 21:11:02 +0000] rev 23975
discovery: properly exclude locally known but filtered heads The conditional was a bit too narrow and produced buggy result when a node was present in both common and heads (because it pleased the discovery) and it was locally known but filtered. This resulted in buggy getbundle request and server side crash.
Fri, 30 Jan 2015 21:40:30 +0000 test: make test-extdiff resilient to /usr/bin/echo stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 21:40:30 +0000] rev 23974
test: make test-extdiff resilient to /usr/bin/echo My test machine has 'echo' in '/usb/bin/echo', #dontaskmewhy.
Fri, 30 Jan 2015 18:49:33 +0000 obsstore: make the invalid markers check wrap-able stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 18:49:33 +0000] rev 23973
obsstore: make the invalid markers check wrap-able Some evolve user ignored the invalid markers for about two years and still have some of them in some repository. This lead to plain abort whenever mercurial try to open such repo. We need reinstall some way to clean this up in the evolve extension. For this purpose, we need the checker code wrap-able independently. This is scheduled for stable as this issue is blocking some evolve user.
(0) -10000 -3000 -1000 -300 -100 -48 +48 +100 +300 +1000 +3000 +10000 tip