revset-branch: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-rangeset: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-only: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset: cache most conditions used in `filter` Except when stated otherwise, the condition used in `smartset.filter` will be cached. A new argument has been introduced to disable that behavior. We use it for filters created from `and` and `sub` operations. This gives massive performance boosts for revsets with expensive conditions. revset: branch(stable) or branch(default) before) wall 4.329070 comb 4.320000 user 4.310000 sys 0.010000 (best of 3) after) wall 2.356451 comb 2.360000 user 2.330000 sys 0.030000 (best of 4) revset: author(mpm) or author(lmoscovicz) before) wall 4.434719 comb 4.440000 user 4.440000 sys 0.000000 (best of 3) after) wall 2.321720 comb 2.320000 user 2.320000 sys 0.000000 (best of 4)

baseset: empty or one-element sets are ascending and descending The empty set is full of interesting properties. In the ordering case, the one element set is too.

filteredset: drop explicit order management Now that all low-level smartset classes have proper ordering and fast iteration management, we can just rely on the subset in filteredset.

revset: restore order of `or` operation as in Mercurial 2.9 Lazy revset broke the ordering of the `or` revset. We now stop assuming that two ascending revset are combine into an ascending one. Behavior in 3.0: 3:4 or 2:5 == [2, 3, 4, 5] Behavior in 2.9: 3:4 or 2:5 == [3, 4, 2, 5] We are adding a test for it. For unclear reason, the performance `or` revset with expensive filter are getting even worse than they used to be. This is probably caused by extra uncached containment check or iteration. revset #9: author(lmoscovicz) or author(mpm) before) wall 3.487583 comb 3.490000 user 3.490000 sys 0.000000 (best of 3) after) wall 4.481486 comb 4.480000 user 4.470000 sys 0.010000 (best of 3) revset #10: author(mpm) or author(lmoscovicz) before) wall 3.164839 comb 3.170000 user 3.160000 sys 0.010000 (best of 3) after) wall 4.574965 comb 4.570000 user 4.570000 sys 0.000000 (best of 3)

revset-_descendant: rework the whole sorting and combining logic We use the & operator to combine with subset (since this is more likely to be optimised than filter) and we enforce the sorting of the result. Without this enforced sorting, we may result in a different iteration order than the set _descendent was computed from. This reverts a bad `test-glog.t` change from 69402eb72115. Another side effect is that `test-mq.t` shows `qparent::` including `-1` if `qparent is -1`. This sound like a positive change. This has good and bad impacts on the benchmarks, here is a good ones: revset: 0:: before) wall 0.045489 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) after) wall 0.034330 comb 0.030000 user 0.030000 sys 0.000000 (best of 100) revset: roots((0::) - (0::tip)) before) wall 0.134090 comb 0.140000 user 0.140000 sys 0.000000 (best of 63) after) wall 0.128346 comb 0.130000 user 0.130000 sys 0.000000 (best of 69) revset: ::p1(p1(tip)):: before) wall 0.143892 comb 0.140000 user 0.140000 sys 0.000000 (best of 55) after) wall 0.124502 comb 0.130000 user 0.130000 sys 0.000000 (best of 65) revset: roots((0:tip)::) before) wall 0.204966 comb 0.200000 user 0.200000 sys 0.000000 (best of 43) after) wall 0.184455 comb 0.180000 user 0.180000 sys 0.000000 (best of 47) Here is a bad one: revset: (20000::) - (20000) before) wall 0.009592 comb 0.010000 user 0.010000 sys 0.000000 (best of 222) after) wall 0.029837 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)

addset: do lazy sorting The previous implementation was consuming the whole revset when asked for any sort. The addset class is now doing lazy sorting like all other smarset classes. This has no significant impact in the benchmark as-is. But this is important to later change.

test-import.t: use proper revset order This test, written after 3.0, is relying on addset being enforced ascending if both side are ascending. We are about to restore the ordering to 2.9 behavior (elements are ordered in the order they are specified). We fix the test before fixing the order.

baseset: drop custom __sub__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant difference but real usecase may. This will also be important for further improvements to addset later in this series.

baseset: drop custom __and__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant regression but real usecase may. This even gives some speedup in some cases: revset #15: min(0::) before) wall 0.001247 comb 0.000000 user 0.000000 sys 0.000000 (best of 1814) after) wall 0.000942 comb 0.000000 user 0.000000 sys 0.000000 (best of 2367) This will also be important for further improvement to addset later in this series.

baseset: drop custom __add__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant differences but real usecase may. This will also be important for further improvements to addset later in this series.

obsolete: use format version 1 as the default for obsstore

test-obsolete: remove subminute timezone in test Obsmarker format "1" does not supports sub minute timezone. So we change the test to something slightly more sensible.

obsolete: add a "format.obsstore-version" config option This option controls what version of the binary format to use when creating a new obsstore file. Default is still the old format. No safeguards are currently placed around the option value, but no clueless users are in danger of harm since it is undocumented.

obsolete: introduce a new binary encoding for obsmarkers (version 1) This new encoding explicitly stores the date and parents allowing a significantly faster marker decoding. See inline documentation for details. This format is not yet used to store format on disk. But it will be used in bundle2 exchange if both side support it. Support for on-disk format is coming in other changesets.

obsstore: add a flag for sha256 hashes We add flag to inform that the marker is using sha256 hashes. As format 0 is not able to handle sha256 hashes (32 bytes long), we plain crash if we even attempt to encode a sha256 with it.

obsolete: use uint## in the format documention This is shorter and kind of more readable for people who care about binary format.

obsolete: gather _fm0 meta encoding with other _fm0 code

obsolete: _rename decodemeta to _fm0decodemeta This will be format zero specific.

obsolete: _rename encodemeta to _fm0encodemeta This will be format zero specific.

obsolete: store metadata as a tuple of (key, value) pairs (API) Different formats will encode metadata in different ways. So we cannot keep the binary blob in the object anymore. We use a tuple to ensure it is immutable and hashable.

merge with stable

templater: fix ifcontains when list is a string (issue4399)

shelve: don't delete "." when rebase is a no-op (issue4398) When unshelving and facing a conflict, if we resolve all conflicts in favour of the committed changes instead of the shelved changes, then the ensuing implicit rebase is a no-op. That is, there is nothing to rebase. In this case, there are no extra intermediate shelve commits to strip either. Prior to this change, the commit being unshelved to would be marked for destruction in a rather catastrophic way. The relevant part of the test case failed as follows: $ hg unshelve -c unshelve of 'default' complete $ hg diff warning: ignoring unknown working parent 33f7f61e6c5e! diff --git a/a/a b/a/a new file mode 100644 --- /dev/null b/a/a @@ -0,0 1,3 @@ a c x $ hg status warning: ignoring unknown working parent 33f7f61e6c5e! M a/a ? a/a.orig ? foo/foo $ hg summary warning: ignoring unknown working parent 33f7f61e6c5e! parent: -1:000000000000 (no revision checked out) branch: default commit: 1 modified, 2 unknown (new branch head) update: 4 new changesets (update) With this change, this test case now passes.

merge: make error message consistent with other commands If a merge is attempted when another merge is already ongoing, we give the message "outstanding uncommitted merges". Many other commands (such as backout, rebase, histedit) give the same message in singular form. Since the singular form also seems to make more sense, let's use that for 'hg merge' as well.

test-run-tests: add a test for detection of failure to start a server This also highlights a bug: right now we print "2 failed" but we only ran one test.

run-tests: more accurate/helpful message than "diff generation failed" Diff generation didn't really fail, it recognized that an hg serve server has failed to start, and thus skipped the diff generation intentionally. The most common reason for a server to fail to start is that the port was already in use, so output HGPORT as well, to help finding it (since pgrep -f 'hg serve' is not sufficient, if the command line is something like 'hg -R main serve')

run-tests: handle --jobs and --first gracefully Without this change, --first causes currently-running tests to explode in violent and surprising ways when their temporary directory gets cleaned up. Now we just suppress failure messages from non-first failures when running in --first mode.

config: use the same hgrc for a cloned repo as for an uninitted repo This just copies the same local sample hgrc, except it sets the default path to the repo it was cloned from. This is cut-and-paste from the local sample hgrc, but I think it's acceptable, since the two pieces of code are right next to each other and they're small. There is danger of them going out of synch, but it would complicate the code too much to get rid of this C&P. I also add ui as an import to hg.py, but with demandimport, this should not be a noticeable performance hit.

config: give a more detailed sample repo config Some examples of the typical configurations that one might want to do in an .hg/hgrc file. This includes a default-push that happens to point to the same location as my-fork. I insist on the myfork terminology for a server-side clone. Bitbucket, Github, and others have widely popularised this meaning of "fork". This also includes a gentle nudge to use a repo-specific username, which is something that people might not instinctively realise is an option.

smartset: drop infamous ascending, descending All your friends are dead.

fullreposet: use `isascending` instead of `ascending` to recognise smartsets `ascending` is going to be removed.

fullreposet: use `sort` to enforce the order The `ascending` and `descending` methods are useless.

revancestors: replace `descending` with `sort(reverse=False)`

_descendants: replace `ascending()` with `sort()`

_descendants: directly use smartset As `addset` objects are proper smartset objects, we do not need to make any transformation of the result.

baseset: explicitly track order of the baseset A baseset starts without an explicit order. But as soon as a sort is requested, we simply register that the baseset has an order and use the ordered version of the list to behave accordingly. We will want to properly record the order at creation time in the future. This would unlock more optimisation and avoid some sorting.

baseset: fix isascending and isdescending We now have sufficient information to return the proper value there.

baseset: prepare lazy ordering in __iter__ We'll explicitly track the order of the baseset to take advantage of the ascending and descending lists during iteration.

baseset: implement a fastasc and fastdesc Baseset contains already-computed revisions. It is considered "cheap" to do operations on an already-computed set. So we add attributes to hold version of the list in ascending and descending order and use them for `fastasc` and `fastdesc`. Having distinct lists is important to provide correct iteration in all cases. Altering a python list will impact an iterator connected to it. eg: not preserving order at iterator creation time >>> l = [0, 1] >>> i = iter(l) >>> l.reverse() >>> list(i) [1, 0] eg: corrupting in progress iteration >>> l = [0, 1] >>> i = iter(l) >>> i.next() 0 >>> l.reverse() >>> i.next() 0

baseset: stop inheriting from built-in list class The baseset is doing more and more smartset magic and using its list-like property less and less. So we store the list of revisions in an explicit attribute and stop inheriting. This requires reimplementing some basic methods.

strip: stop calling `remove` on smartset The `remove` method is not part of the smartset specification. We use a plain old list comprehension instead.

rebase: transform the smartset to a list before comparing with a list This is highly suboptimal but smartsets are not comparable to lists yet.

merge.update: use `first` instead of direct indexing This makes it compatible with all smartset classes.

qimport: use `first` and `last` instead of direct indexing This makes it compatible with all smartset classes.

rebase: use `last` instead of direct indexing This makes it compatible with all smartset classes.

mq: use `last` instead of direct indexing This makes it compatible with all smartset classes.

repair: use `first` instead of direct indexing This makes it compatible with all smartset classes.

rangeset: use `first` and `last` instead of direct indexing This makes it compatible with all smarsets classes.

revpair: use `first` and `last` instead of direct indexing This makes it compatible with all smarsets classes.

revsingle: use `last` instead of direct indexing This makes it compatible with all smarsets classes.

revset-limit: use boolean testing instead of `len(revs) < 1` I'm not sure why we wrote it that way. But smartsets have faster/lazier non-zero testing than length computation.

filteredset: implement `first` and `last`

baseset: implement `first` and `last` methods

generatorset: implement first and last methods

addset: implement first and last methods The implementation is non-lazy for now. One may want to make it more lazy in the future.

spanset: implement `first` and `last` methods

smartset: add first and last methods In multiple places in the code, we use `someset[0]` or `someset[-1]`. This works only because the `someset` is usually a baseset. For the same reason we introduce a `first` and `last` methods to be implemented for all smartset classes.

getgraphlogrevs: remove user of baseset.append A `baseset` has multiple cached results and will get even more in the future. Making it an object "populated once" like the other smartsets makes it both safer and simpler. The append method will be removed at some point.

getlogrevs: remove user of baseset.append A `baseset` has multiple cached results and will get even more in the future. Making it an object "populated once" like the other smartsets makes it both safer and simpler. The append method will be removed at some point.

revset-last: remove user of baseset.append A `baseset` has multiple cached results and will get even more in the future. Making it an object "populated once" like the other smartsets makes it both safer and simpler. The append method will be removed at some point.

revset-limit: remove user of baseset.append A `baseset` has multiple cached results and will get even more in the future. Making it an object "populated once" like the other smartsets makes it both safer and simpler. The append method will be removed at some point.

mq: use `revs.sort()` to ensure the set is ascending Sorting is super-cheap with the new smartset class, so we can use it to enforce the order. Otherwise all smartset classes would have to allow direct indexing.

baseset: use default value instead of [] when possible For pure cleanup purposes, we replace all the occurences of `baseset([])` with `baseset()`.

generatorset: implement isascending and isdescending

generatorset: explicitly track iteration order The expected iteration order may be different than the fast iteration order (eg: ancestors(42) is expected to be iterated upward but is fast/lazy to compute downward. So we explicitly track the iteration order and enforce it if the manual iteration is requested. Default expected iteration order of a generator set is ascending because I'm not aware of any descending revset that need a generatorset. The first to find such descending revset will have the pleasure to make this configurable.

addset: drop caching through generatorset The utility of this cache is debatable (no visible benchmark impact) and using generatorset for such purpose makes the code complicated. We drop it for now. Someone can reintroduce a smart version of it in the future if it is detected to be relevant.

generatorset: get list-based fast iterations after the generator is consumed When all revisions are known, we shortcut most of the class logic to use list iteration instead. The cost of the sort is expected to be non-significant. The list creation and sorting could be done lazily in the future. We have to copy the list to not break existing iterator created before we finished consuming the generator.

generatorset: move iteration code into _iterator _iterator handles the generator iteration. The `__iter__` method will need changes to handle ordering-related information.

generatorset: stop using a base as the _genlist It does not add anything and makes it more complicated to have a simple baseset implementation.

generatorset: drop the leading underscore in the class name This is a real smart set now.

generatorset: update the docstring now that it is a smartset The documentation was still stating that this class was not a smartset. We drop that part.

addset: drop the leading underscore from the class name This class is now a real smartset.

addset: this is a smartset, update the docstring The documentation was still stating that this class is a not a smartset. We drop that part.

addset: use the ascending argument in _iterordered Fix a bug where fastasc and fastdesc were iterator in the same order as self._ascending.

rebase: add help examples

rebase: attempt to clarify --base

manifest: rearrange add() method and add comments for clarity Omit the check of bool(p1) since it's always true in practice: it will either be nullid or some valid manifest sha, and we know nullid won't ever be in the cache so we can simplify understanding of this code.

manifest: simplify manifest.add() by making args required I verified that changed was never false (it was always a 2-tuple) by adding @@ -220,6 +225,8 @@ class manifest(revlog.revlog): def add(self, map, transaction, link, p1=None, p2=None, changed=None): + if not changed: + assert False, 'changed was %r' % changed # if we're using the cache, make sure it is valid and # parented by the same node we're diffing against if not (changed and p1 and (p1 in self._mancache)): and observing that the test suite still passed. Making all the arguments required should help future readers understand what's going on here.

manifest: move manifest parsing to module-level We'll need this in the sharded manifest hashing routine, and I need to tweak it anyway, so make it module-level now.

revlog: move references to revlog.hash to inside the revlog class This will make it possible for subclasses to have different hashing schemes when appropriate. I anticipate using this in manifests. Note that there's still one client of mercurial.revlog.hash() outside of revlog: mercurial.context.memctx uses it to construct the file entries in an in-memory manifest. I don't think this will be a problem in the immediate future, so I've left it as-is.

revlog: mark nullhash as module-private No other module should ever need this, so mark it with _ so nobody tries to use it.

ui: disable echo back of prompt input if ui is set to non-tty purposely 9ab18a912c44 is nice for test output, but it also affects command-server channel. Command-server client shouldn't receive echo-back message, which makes it harder to parse the output.

dirstate: cache util.normcase while constructing the foldmap This is a small win on OS X. hg perfdirstatefoldmap: before: wall 0.399708 comb 0.410000 user 0.390000 sys 0.020000 (best of 25) after: wall 0.386331 comb 0.390000 user 0.370000 sys 0.020000 (best of 25)

normcase: for darwin, use fast ASCII lower Constructing the foldmap is much faster on OS X now. For a large real-world repo, hg perfdirstatefoldmap: before: wall 0.805278 comb 0.800000 user 0.790000 sys 0.010000 (best of 13) after: wall 0.399708 comb 0.410000 user 0.390000 sys 0.020000 (best of 25) This is a nice boost to 'hg status', especially with the third-party hgwatchman extension enabled (which eliminates stat calls). For the above repo, 'hg status' goes from 1.17 seconds to 0.74.

perf: add a way to measure the perf of constructing the foldmap Constructing the foldmap is a necessary part of operations like 'hg status' on OS X. This command allows us to measure the perf of constructing it.

encoding.lower: use fast ASCII lower This benefits, among other things, the case collision auditor. On a Linux system with a large real-world repo where all filenames are ASCII, hg perfcca: before: wall 0.260157 comb 0.270000 user 0.230000 sys 0.040000 (best of 38) after: wall 0.164616 comb 0.160000 user 0.160000 sys 0.000000 (best of 54)

parsers: add a function to efficiently lowercase ASCII strings We need a way to efficiently lowercase ASCII strings. For example, 'hg status' needs to build up the fold map -- a map from a canonical case (for OS X, lowercase) to the actual case of each file and directory in the dirstate. The current way we do that is to try decoding to ASCII and then calling lower() on the string, labeled 'orig' below: str.decode('ascii') return str.lower() This is pretty inefficient, and it turns out we can do much better. I also tested out a condition-based approach, labeled 'cond' below: (c >= 'A' && c <= 'Z') ? (c + ('a' - 'A')) : c 'cond' turned out to be slower in all cases. A 256-byte lookup table with invalid values for everything past 127 performed similarly, but this was less verbose. On OS X 10.9 with LLVM version 6.0 (clang-600.0.51), the asciilower function was run against two corpuses. Corpus 1 (list of files from real-world repo, > 100k files): orig: wall 0.428567 comb 0.430000 user 0.430000 sys 0.000000 (best of 24) cond: wall 0.077204 comb 0.070000 user 0.070000 sys 0.000000 (best of 100) lookup: wall 0.060714 comb 0.060000 user 0.060000 sys 0.000000 (best of 100) Corpus 2 (mozilla-central, 113k files): orig: wall 0.238406 comb 0.240000 user 0.240000 sys 0.000000 (best of 42) cond: wall 0.040779 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) lookup: wall 0.037623 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) On a Linux server-class machine with GCC 4.4.6 20120305 (Red Hat 4.4.6-4): Corpus 1 (real-world repo, > 100k files): orig: wall 0.260899 comb 0.260000 user 0.260000 sys 0.000000 (best of 38) cond: wall 0.054818 comb 0.060000 user 0.060000 sys 0.000000 (best of 100) lookup: wall 0.048489 comb 0.050000 user 0.050000 sys 0.000000 (best of 100) Corpus 2 (mozilla-central, 113k files): orig: wall 0.153082 comb 0.150000 user 0.150000 sys 0.000000 (best of 65) cond: wall 0.031007 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) lookup: wall 0.028793 comb 0.030000 user 0.030000 sys 0.000000 (best of 100) SSE instructions might help even more, but I didn't experiment with those.

match: remove unnecessary setting of self._always The 'always' class calls its parent constructor with an empty list of patterns, which will result in a matcher that always matches. The parent constructor will set self._always to True in such cases, so there is no need to set it again.

bookmarks: port to generic templater

bookmarks: split ui.write() so that it can be easily ported to formatter api Test output changes because color labels are applied separately.

bookmarks: iterate bookmarks list even if it is known to be empty This clarifies that "no bookmarks set" is displayed in addition to the list of bookmarks. In JSON output, for example, [] should be written if empty, and "no bookmarks set" message should be skipped.

repoview: remove hiddencache verification We have been running hiddencache verification since 3.1.1 and so far not received a bug report concerning it. Therefore we remove the verification code and make the hiddencache authoritive. That way we get the intended speedup.

color: reorganise and sectionify the help text The color docstring was getting long. This splits it up into bite-sized sections and rearranges the order of the paragraphs a little to match these sections.

color: update description of the extension The color extension long ago ceased to work only for the status and qseries commands.

help: show all nested subsections of a section with `hg help foo.section` Used to be that `hg help hgrc.paths` would show "paths" ------- Assigns symbolic names to repositories. The left side is the symbolic name, and the right gives the directory or URL that is the location of the repository. Default paths can be declared by setting the following entries. and stop there. Obviously the result seems better as shown in the attached test.

help: fix output of sections in `hg help foo.somesection` There was a bug in c3c3dd31fe1c. The block that added definitions to getsections should have been an elif, not an if. Otherwise section titles get added twice, since the else clause would always get executed for section titles.

log: show phase in hg log -v with the phase template It seems weird that `hg log -v -T phases` would be *less* verbose than `hg log -T phases`. This cset corrects that oversight.

log: add labels to the phase template This copies the labelled default template and just adds an extra {phase} keyword as necessary.

log: rewrite default template to use labels (issue2866) This is a complete rewrite of the default template to use labels. This seems ultimately useless to me in most cases. The biggest benefit of this patch to me seems to be a fairly complicated example of the templating engine. It was a lot of hard work to figure out the precise acceptable syntax, since it's almost undocumented. Hat tip to Steve Losh's smartlog template, which helped me figure out a lot of the syntax. Hopefully later I can use the present default log template as an example for documenting the templating engine. A test is attached. My goal was to match the --color=debug output, which may differ slightly in newlines from the actual ANSI escape codes output. I consider this an acceptable invisible deviation. There seems to be a considerable slowdown with this rewrite. Before: $ time hg log -T default -r .~100::. > /dev/null real 0m0.882s user 0m0.812s sys 0m0.064s $ time hg log -T default -r .~100::. > /dev/null real 0m0.872s user 0m0.796s sys 0m0.068s $ time hg log -T default -r .~100::. > /dev/null real 0m0.917s user 0m0.836s sys 0m0.076s After: $ time hg log -T default -r .~100::. > /dev/null real 0m1.480s user 0m1.392s sys 0m0.072s $ time hg log -T default -r .~100::. > /dev/null real 0m1.500s user 0m1.400s sys 0m0.088s $ time hg log -T default -r .~100::. > /dev/null real 0m1.462s user 0m1.364s sys 0m0.092s Following the maxim, "make it work, profile, make it faster, in that order", I deem this slowdown acceptable for now. I suspect but have not confirmed that a big slowdown comes from calling keywords twice in the file templates, once to test the existence of output and again to actually list the output. If so, a simple speedup might be to improve the templating engine to cache keywords when called more than once on the same revision. TODO: I found a bug while working on this. The following stack traces: hg log -r . -T '{ifcontains(phase, "secret public", "lol", "omg")}\n'

log: do not hide the public phase in debug mode (BC) When 51fc43253a52 introduced phases to the `hg log --debug` output, it also disabled outputting public phase. At the same time, it always shows phases in the default template, `hg log --debug -T default`. Those two should produce the same output, but they don't. I think it makes a lot more sense to always show all phases. There's already loss of backwards compatibility in this case when using a newer hg on an old hg repo, since draft commits will show up in the output of `hg log --debug`. Finally, I just don't think that any sort of information should be hidden with --debug. This flag should be about showing as much information as possible.

templater: set the correct phase for parents Akin to f6371cc62d2a which did this for `hg log`, the following sets the correct phase for the {phase} keyword when the context is a parent of the current cset. This allows templates such as the following to be defined, parent = '{label("log.parent changeset.{phase}", "parent: {rev}:{node|formatnode}")}\n' which when called on a parent (e.g. with the `parents` template keyword), will produce the correct phase.

color: omit debug label output on empty strings This is most noticeable when using custom templates. Before this patch, a template like {label("foo.bar", baz)} would emit [foo.bar|] whenever baz was empty. This cset simply omits all output when baz is empty.

tests: make hghave list features alphabetically

revset: remove the now unused _descgeneratorset class

revset: use _generatorset in _revancestors The _descgeneratorset class is going away.

revset: remove now unused class _ascgeneratorset

revset: use _generatorset directly in _revdescendant _ascgeneratorset is going away.

generatorset: move membership testing on ordered gen to the main class We are phasing out the ordered version of the class to simplify the code.

generatorset: make use of the new mechanism in the subclass Until we remove them, we use the new parameter of _generatorset to make sure the code is run.

generatorset: make it possible to use gen as fastasc or fastdesc We gain a parameter to inform that the generator is ascending or descending. If the generator is ordered, it is also used for the `fastasc` or `fastdesc` version. The _ascgeneratorset and _descgeneratorset class will be removed soon.

baseset: rely on the abstractsmartset implementation for filter

_orderedsetmixin: drop this now unused class All my friends are dead.

spanset: drop _orderedsetmixin inheritance The min/max method are as well provided by abstractsmartset.

orderedlazyset: drop this now unused class All my friends are dead.

_descendant: use filteredset instead of orderedlazyset The orderedlazyset class is going away. Filteredset gives the same service.

addset: use the base implementation for ascending and descending

addset: use base implementation for __filter__