profile: use explicit logic to control file closing We make the decision to close 'fp' more explicit instead of relying on the implication of other variable. This makes the overall logic more robust.

profiling: move 'fp' closing logic into its own function We are about to make the logic more robust and reuse it in more place, we start by isolating what we have.

py3: use python3 hg in test-py3-commands.t at places where py2 hg was used This patch fixes my mistakes where I added test in test-py3-commands.t as `hg ...` where I forgot hg here refers to Python 2 mercurial.

test-dirstate-race: back out changeset c82fa7efcbc8 This is non-deterministic. In any case, I switched to using debugrebuilddirstate in my WIP patches, which makes this moot.

revset: fix order of first/last members in compound expression (BC) Suppose len(subset) >> len(ls) in common cases, 'subset & ls' should be avoided whenever possible.

revset: filter first/last members by __and__ operation This replaces 'if y in subset' with '& subset'. first(null) and last(wdir()) are fixed thanks to fullreposet.__and__. This also revealed that first() and last() don't follow the order of the input set. 'ls & subset' is valid only if the ordering requirement is 'define' or 'any'. No performance regression observed: revset #0: limit(0:9999, 100, 9000) 0) 0.001164 1) 0.001135 revset #2: 9000 & limit(0:9999, 100, 9000) 0) 0.001224 1) 0.001181 revset #3: last(0:9999, 100) 0) 0.000237 1) 0.000199

revset: reject negative number to select first/last n members Negative 'lim' doesn't make sense here, and it makes things complicated when using list[:lim].

revset: fix order of last() n members where n > 1 (BC) last() is implemented using a reversed iterator, so the result should be reversed again. I've marked this as BC since it's quite old bug seen in 3.0. The first bad revision is 4849f574aa24 "revset: changed last implementation to use lazy classes."

debugrevspec: add option to suppress list of computed revisions Test will be added later.

debugrevspec: add option to print representation of smartset object It's possible by -v, but -v also prints a parsed tree. Test will be added later.

bookmarks: make sure we close the bookmark file after reading We previously lacked an explicit close of the bookmark file.

bookmarks: rephrase a comment to be shorted and clearer The initial motivation is that I need an initial level of indent in the next changeset o:-) It turn out I like the new version better.

checkheads: use a "lazyancestors" object for allfuturecommon Instead of walking all ancestors to compute the full set we now check membership lazily. This massively speed. On a million-ish revision repository, this remove 14 seconds from the push logic, making the checkheads function disappear from profile.

checkheads: use "revnum" in the "allfuturecommon" set The obsolete post-processing needs to know the extend of the pushed set. The way it is implemented is... suboptimal. It build a full set of all nodes in the pushset and it does so using changectx. We have much better API for this now. The simplest is to use the existing lazy ancestors computation. That logic uses revnum and not node (for good reason) so we start with updating the post-processing code to handle a "allfuturecommon" set containing revision numbers.

checkheads: use 'nodemap.get' to convert nodes to revs We are about to call 'torev' on node that might be locally missing. In this case, 'nodemap.revs' will return None (something valid in our usecase) while 'changelog.rev' would raise an exception. We make this change in a distinct changeset to show it does not impact the tests.

checkheads: pass "ispushed" function to the obsmarkers logic We are about to make "allfuturecommon" a set of revs instead of a set of nodes. The function updated in this patch do not needs to know about these details so we just pass it a 'ispushed(node)' function. This will simplify the next changeset.

profile: drop maybeprofile It seems sufficiently simple to use "profile(enabled=X)" to not justify having a dedicated context manager just to read the config. (I do not have a too strong opinion about this).

profile: support --profile in alias and abbreviated version (--prof) We now process the "--profile" a second time after alias has been processed and the command argument fully parsed. If appropriate we enable profiling at that time. In these situation, the --profile will cover less than if the full --profile flag was passed on the command line. This is better than the previous behavior (flag ignored) and still fullfil multiple valid usecases.

profile: make the contextmanager object available to the callers This will allow calling methods on the object in the code using the context manager.

profile: introduce a knob to control if the context is actually profiling This is a step toward allowing context where the profiling in enabled withing the context range. This also open the way to kill the dedicated "maybeprofile" context manager and keep only one of 'profile' and 'maybeprofile'.

profile: introduce a "start" method to the profile context The start method is doing all profiler setup and activation. It is currently unconditionally called by '__init__' but this will be made more flexible in later changesets.

profile: upgrade the "profile" context manager to a full class So far we have been able to use a simple decorator for this. However using the current context manager makes the scope of the profiling in dispatch constrainted and the time frame to decide to enable profiling quite limited (using "maybeprofile") This is the first step toward the ability to enable the profiling from within the profiling scope. eg:: with maybeprofiling(ui) as profiler: ... bar.foo(): ... if options['profile']: profiler.start() ... fooz() ... My target usecase is adding support for "--profile" to alias definitions with effect. These are to be used with "profiling.output=blackbox" to gather data about operation that get slow from time to time (eg: pull being minutes instead of seconds from time to time). Of course, in such case, the scope of the profiling would be smaller since profiler would be started after running extensions 'reposetup' (and other potentially costly logic), but these are not relevant for my target usecase (multiple second commits, multiple tens of seconds pull). Currently adding '--profile' to a command through alias requires to re-spin a Mercurial binary (using "!$HG" in alias), which as a significant performance impact, especially in context where startup performance is being worked on... An alternative approach would be to stop using the context manager in dispatch and move back to a try/finally setup.

setup: avoid linker warnings on Windows about multiple export specifications The PyMODINIT_FUNC macro contains __declspec(dllexport), and then the build process adds an "/EXPORT func" to the command line. The 64-bit linker flags this [1]. Everything except zstd.c and bser.c are covered by redefining the macro in util.h [2]. These modules aren't built with util.h in the #include path, so the redefining hack would have to be open coded two more times. After seeing that extra_linker_flags didn't work, I couldn't find anything authoritative indicating why, though I did see an offhand comment on SO that CFLAGS is also ignored on Windows. I also don't fully understand the interaction between msvccompiler and msvc9compiler- I first subclassed the latter, but it isn't used when building with VS2008. I know the camelcase naming isn't the standard, but the HackedMingw32CCompiler class above it was introduced 5 years ago (and I think the current style was in place by then), so I assume that there's some reason for it. [1] https://support.microsoft.com/en-us/help/835326/you-receive-an-lnk4197-error-in-the-64-bit-version-of-the-visual-c-compiler [2] https://bugs.python.org/issue9709#msg120859

memctx: always use cache for filectxfn I don't see a downside to doing this unless I'm missing something. Thanks to foozy for correcting my previous bad logic.

test-hardlinks: stabilize for Windows This broke in c2cb0de25120, which breaks hardlinks when the executable bit is toggled.

releasenotes: add more tests for formatting and merging of release notes

releasenotes: command to manage release notes files Per discussion on the mailing list, we want better release notes for Mercurial. This patch introduces an extension that provides a command for producing release notes files. Functionality is implemented as an extension because it could be useful outside of the Mercurial project and because there is some code (like rst parsing) that already exists in Mercurial and it doesn't make sense to reinvent the wheel. The general idea with the extension is that changeset authors declare release notes in commit messages using rst directives. Periodically (such as at publishing or release time), a project maintainer runs `hg releasenotes` to extract release notes fragments from commit messages and format them to an auto-generated release notes file. More details are explained inline in docstrings. There are several things that need addressed before this is ready for prime time: * Moar tests * Interactive merge mode * Implement similarity detection for individual notes items * Support customizing section names/titles * Parsing improvements for bullet lists and paragraphs * Document which rst primitives can be parsed * Retain arbitrary content (e.g. header section/paragraphs) from existing release notes file * Better error messages (line numbers, hints, etc)

packagelib: use LANGUAGE=C for "hg version" If "hg version" does not contain "version" (e.g. Japanese), $hgversion was empty and rpmbuild failed.

rpms: add hgdemandimport in files

rpms: remove '%if "%{?pythonver}" != "2.4"' Mercurial requires python >= 2.7.