tests: use baseurl instead of advertisedbaseurl The distinction matters for e.g. hosts behind load balancers. But for the test environment, it doesn't matter. For whatever reason, advertisedbaseurl is resolving to http://1.0.0.127.in-addr.arpa:$HGPORT on my MBP. This hostname fails to resolve, causing the test to fail. No clue what's up with that behavior. Differential Revision: https://phab.mercurial-scm.org/D4973

py3: another one started passing Differential Revision: https://phab.mercurial-scm.org/D4990

py3: one more passing test Differential Revision: https://phab.mercurial-scm.org/D4989

scmutil: wrap locker information in bytestr before repr()ing it Differential Revision: https://phab.mercurial-scm.org/D4988

py3: more passing tests Differential Revision: https://phab.mercurial-scm.org/D4987

py3: whitelist another passing test Differential Revision: https://phab.mercurial-scm.org/D4986

obsolete: convert error string to a sysstr This should be okay because we're just %-formatting a hash into a localized string. Differential Revision: https://phab.mercurial-scm.org/D4985

tests: ensure the python 3 passing test list stays sorted Differential Revision: https://phab.mercurial-scm.org/D4984

py3: sort passing test list Differential Revision: https://phab.mercurial-scm.org/D4983

py3: tweak stdout writing in test-hgweb-no-path-info.t We want to write bytes for convenience. This requires sys.stdout.buffer. But using sys.stdout.buffer introducing buffered output. So we sprinkle code with sys.stdout.flush() to force immediate writes. After all that, Python 3 was emitting b'' prefixed output for errors. So we only print errors if there were some. There aren't, so b'' don't come into play and output is identical in Python 2 and 3. Differential Revision: https://phab.mercurial-scm.org/D4972

py3: use .+ instead of .* in regexp pattern Python 3.7 changed the behavior of re.sub(). See https://bugs.python.org/issue33585. The new code should work on old and new Pythons. Differential Revision: https://phab.mercurial-scm.org/D4971

py3: coerce bytestr to bytes to appease urllib.parse.quote_from_bytes() Differential Revision: https://phab.mercurial-scm.org/D4969

py3: pass str and return bytes from mimetypes.guess_type() This function wants a str (which represents a path) and returns a str. We normalize input to str and output to bytes. Differential Revision: https://phab.mercurial-scm.org/D4967

py3: use bytes literal in test-hgweb-json.t # skip-blame just b'' prefix Differential Revision: https://phab.mercurial-scm.org/D4970

py3: convert diff opcode name to bytes Differential Revision: https://phab.mercurial-scm.org/D4968

py3: byteify hgweberror.py # skip-blame just b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D4966

py3: encode JSON str to bytes json.dumps() will emit UTF-8 str on Python 2 and 3. Use sysbytes to force the .encode('utf-8') on Python 3 and no-op on Python 2. Differential Revision: https://phab.mercurial-scm.org/D4965

py3: use b'' in test-check-interfaces.py # skip-blame just b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D4964

revlog: optimize ancestors() to not check filtered revisions for each While reviewing the Rust implementation, I noticed iter(ancestors) doesn't need to check filtering state for each parent revision. And doing that appears to have some measurable perf win. $ hg perfancestors -R mercurial (orig) wall 0.038093 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) (this) wall 0.024795 comb 0.020000 user 0.020000 sys 0.000000 (best of 117)

phabricator: drop support for the legacy phabricator.auth.token config (BC) The test for this broke in dc82ad1b7f77 when statistics started being tracked. It wasn't noticed because none of the bots have the vcr module installed. It looks like the custom_patches argument should patch in the custom httpconnection, and I can't figure out what is going on.

absorb: print '{rev}:' as a prefix to the hash I don't see a sane way to print the summary to identify the changed commit, but this at least makes it a bit easier to identify a commit when a group of them changes.

packaging: fix "make centos{5,6,7}" Without this change, make centos{5,6,7} fails with error: cp: cannot stat '<basedir>/rpmbuild/RPMS/*/*': No such file or directory This change is the exact equivalent of bc4bbc42899a (which applied to Fedora).

narrow: don't compress the bundle2 when sending 'error:abort' This is similar to waht getbundle() does and also explicitly specifies that we should get a compressed bundle2 in normal cases when not sending 'error:abort'. Differential Revision: https://phab.mercurial-scm.org/D4934

push: add "remote" to 'repository changed while pushing' messages (issue5971) Differential Revision: https://phab.mercurial-scm.org/D4933

fuzz: try setting PYTHONNOUSERSITE=1 to avoid loading site-packages Right now the fuzzer is crashing trying to look up the home dir for uid 0, which is breaking in the fuzz environment. Differential Revision: https://phab.mercurial-scm.org/D4936

perf: extract result formatting in its own function This will make it easier to reuse in another changesets.

perf: extract the timing of a section in a context manager This makes it easier to reuse it in other (future) part of the code that requires their own time management.

pref: support negative indexing in perfrevlogrevisions This is useful to check for a consistent final slice in multiple different repositories.

perf: accept formatter option for perfmanifest

perf: fix -T json The previous code was mixing formatting and data, breaking `-T json` with unexpected data. We fix the issue and add a test to prevent future regression.

formatter: more details on assertion failure This is useful when the assertion fails.

wireprotov2: raise ProgrammingError on unknown action Suggested by @durin42 in review of D4923. Differential Revision: https://phab.mercurial-scm.org/D4935

wireprotov2: send content encoded frames from server Now that we have support for negotiating encodings and configuring an encoder, we can start sending content encoded frames from the server. This commit teaches the wireprotov2 server code to send content encoded frames. On the mozilla-unified repository with zstd enabled peers, this change reduces the total amount of data transferred from server to client drastically: befor: 7,190,995,812 bytes after: 1,605,508,691 bytes Differential Revision: https://phab.mercurial-scm.org/D4927

wireprotov2: raise exception in objects() if future has been resolved Differential Revision: https://phab.mercurial-scm.org/D4926

wireprotov2: don't emit empty frames Staring at logs revealed the presence of empty frames that should have contained payload. Let's stop that from happening. Differential Revision: https://phab.mercurial-scm.org/D4925

wireprotov2: remove functions for creating response frames from bytes All code in the actual server uses oncommandresponsereadyobjects(). Test code was ported to that method. This resulted in a handful of subtle test changes. Differential Revision: https://phab.mercurial-scm.org/D4924

wireprotov2: handle noop action This action can be returned from the client reactor. We should handle it. Differential Revision: https://phab.mercurial-scm.org/D4923

wireprotov2: send protocol settings frame from client Now that we have client and server reactor support for protocol settings and encoding frames, we can start to send them out over the wire! This commit teaches the client reactor to send out a protocol settings frame when needed. The httpv2 peer has been taught to gather a list of supported content encoders and to advertise them through the client reactor. Because the client is now sending new frame types by default, this constitutes a compatibility break in the framing protocol. The media type version has been bumped accordingly. This will ensure existing clients won't attempt to send the new frames to old servers not supporting this explicit media type. I'm not bothering with the BC annotation because everything wireprotov2 is highly experimental and nobody should be running a server yet. Differential Revision: https://phab.mercurial-scm.org/D4922

wireprotov2: define and use stream encoders Now that we have basic support for defining stream encoding, it is time to start doing something with it. We define various classes implementing stream encoders/decoders for the defined encoding profiles. This is relatively straightforward. We teach the inputstream and outputstream classes how to encode, decode, and flush data. We then teach the clientreactor how to filter received data through the inputstream decoder. One of the features of the framing format is that streams can span requests. This is a differentiating feature from say HTTP/2, which associates streams with requests. By allowing streams to span requests, we can reuse compression context data across requests/responses. But in order to do this, we need a mechanism to "flush" the encoder at logical boundaries so that receivers receive all data where it is expected. And a "flush" event is distinct from a "finish" event from the perspective of certain compressors because a "flush" will retain compression context state whereas a "finish" operation will not. This is why encoders have both a flush() and a finish() and each uses specific flushing semantics on the underlying compressor. The added tests verify various behavior of decoders via clientreactor. These tests do test some compression behavior via use of outputstream. But for all intents and purposes, server reactor support for encoding is not yet implemented. Differential Revision: https://phab.mercurial-scm.org/D4921

lfs: avoid a potential variable reference before assignment error in cmdserver A coworker hit this once yesterday when pulling in thg (a retry worked), and then I hit it with strip after a pull. I had a difficult time recreating a test for this (at least one of the tricks was to not use '-R', which seems to cause reposetup() to be called for each command), so I'm not sure how large of a window there actually is for this. Calling reposetup() *after* the requirement is added will skip the hook entirely. The other issue I had was adding a couple `ui.status()` lines around the check that installs the hook. On Windows, the cmdserver process ballooned to 1.6GB and hung. Changing that to `ui.warn()` avoided the hang. It also hung on macOS, but without the large memory usage.

wireprotov2: establish dedicated classes for input and output streams Streams are unidirectional. As part of implementing encoding/decoding support, it became clear that it didn't make sense for a generic "stream" class to hold functionality related to both encoding and decoding. So we create new classes to represent the flavor of stream. Differential Revision: https://phab.mercurial-scm.org/D4920

wireprotov2: pass ui into clientreactor and serverreactor This will allow us to use config options to influence compression settings. Differential Revision: https://phab.mercurial-scm.org/D4919

wireprotov2: handle stream encoding settings frames Like what we just did for the server reactor, we teach the client reactor to handle stream encoding settings frames. The code is very similar. We define a method on the stream class to handle processing the data within the decoded frames. However, it doesn't yet do anything useful. Differential Revision: https://phab.mercurial-scm.org/D4918

wireprotov2: document client reactor actions We should document these so consumers have an easier life. Differential Revision: https://phab.mercurial-scm.org/D4917

wireprotov2: handle sender protocol settings frames We teach the server reactor to handle the optional sender protocol settings frames, which can only be sent at the beginning of frame exchange. Right now, we simply decode the data and record the sender protocol settings on the server reactor instance: we don't yet do anything meaningful with the data. Differential Revision: https://phab.mercurial-scm.org/D4916

wireprotov2: update stream encoding specification The encoding of data within streams in the frame-based protocol is not yet defined or implemented. This means that all data in wire protocol version 2 is currently being sent out raw, without compression. That's obviously not ideal. This commit formalizes the beginnings of stream encoding support in the protocol. I suspect we'll change behavior substantially in the future. My goal is to get something landed so we can use compression. We can build out more robust support later. Because the frame type ID changed, this is strictly BC. But existing code wasn't using the frame. I'll bump the framing protocol version later once code is introduced to use the new frame. Differential Revision: https://phab.mercurial-scm.org/D4915

cborutil: cast bytearray to bytes This code didn't like passing in bytearray instances. Let's cast bytearray to bytes so it works. Differential Revision: https://phab.mercurial-scm.org/D4914

tests: disable zstd in test This makes the test pass in pure installs. Differential Revision: https://phab.mercurial-scm.org/D4913

wireprotov2: remove "compression" from capabilities response This is not used. And future commits will change how this mechanism works. Let's remove it. As a bonus, this fixes some test failures on pure installs (due to zstd references). Differential Revision: https://phab.mercurial-scm.org/D4912

zstandard: vendor python-zstandard 0.10.1 This was just released. The upstream source distribution from PyPI was extracted. Unwanted files were removed. The clang-format ignore list was updated to reflect the new source of files. setup.py was updated to pass a new argument to python-zstandard's function for returning an Extension instance. Upstream had to change to use relative paths because Python 3.7's packaging doesn't seem to like absolute paths when defining sources, includes, etc. The default relative path calculation is relative to setup_zstd.py which is different from the directory of Mercurial's setup.py. The project contains a vendored copy of zstandard 1.3.6. The old version was 1.3.4. The API should be backwards compatible and nothing in core should need adjusted. However, there is a new "chunker" API that we may find useful in places where we want to emit compressed chunks of a fixed size. There are a pair of bug fixes in 0.10.0 with regards to compressobj() and decompressobj() when block flushing is used. I actually found these bugs when introducing these APIs in Mercurial! But existing Mercurial code is not affected because we don't perform block flushing. # no-check-commit because 3rd party code has different style guidelines Differential Revision: https://phab.mercurial-scm.org/D4911

rust-chg: install signal handlers to forward signals to server I use sync::Once as a synchronization primitive because it's quite easy to use, and is good enough to prevent data race in these C functions.

rust-chg: remove SIGCHLD handler which won't work in oxidized chg Since pager is managed by the Rust part, the C code doesn't know the pager pid. I could make the Rust part teach the pid to C, but still installing SIGCHLD handler seems horrible idea since we no longer use handcrafted low-level process management functions. Instead, I'm thinking of adding async handler to send SIGPIPE at the exit of the pager.

rust-chg: extract signal handlers from chg/procutil.c abortmsgerrno() and debugmsg() are removed, and the public interface instead returns success/error status. Since signal handlers can't propagate errors, the result of kill() is just ignored.

help: document about "version" template keywords

help: document about "tags" template keywords

help: document about "status" template keywords

help: document about "resolve" template keywords

help: document about "paths" template keywords

help: document about "identify" template keywords

help: document about "grep" template keywords

chgserver: catch Abort while parsing early args to shut down cleanly _loadnewui() calls dispatcher functions, which may raise Abort if unparsable arguments are passed in. The server should catch such errors and translate them to the "exit 255" instruction so the client can finish the IPC session cleanly. Spotted while porting the chg client to Rust.

chg: upgrade client to use "setumask2" command No compatibility code is added to the client side, since it's unlikely for new client to communicate with the old server.

chgserver: add "setumask2" command which uses correct message frame The first 4 bytes should be a length field, not a value. Spotted while porting chg functions to the Rust one.

packaging: "make deb" no longer fails Release 4.7 rationalized the layout of the build scripts. Unfortunately, while "make docker-ubuntu-*" and "make docker-debian-*" worked as expected, "make deb" was broken. Before this change "make deb" was failing with the following error: You are not inside a Mercurial repository! Or, after the latest changes: You are inside <fullpath>, which is not the root of a Mercurial repository Moreover, when "make deb" failed, the cleanup routine deleted the wrong directory (contrib/packaging/debian instead of <reporoot>/debian) resulting in a corrupted working copy that needed to be hg revert-ed. After this change the docker targets continue to work, and the deb one is able to finish.

packaging: cleanup() did not read the value of $CLEANUP When the original author put CLEANUP in a conditional statement he was probably willing to use it to control the "if". This change tries to restore that behaviour: the "rm" clause is triggered if and only if CLEANUP is defined and not empty.

packaging: builddeb's cleanup needs to expand PWD, safely Single quotes would not expand the variable.

packaging: blindly factor out trap's cleanup function in builddeb This commit blindly extracts builddeb's trap routine in a dedicated function. While doing so, I think two bugs are exposed, which will be addressed in the next commits: - single quoting around '$CLEANUP' will always evaluate to the literal '$CLEANUP' regardless of the variable's value. The "if" will always be true. - the removal operation will not expand $PWD (and a variable expansion would need double quotes, anyways.

packaging: print full path to the packages when builddeb finishes successfully

packaging: print more specific error messages when builddeb fails

cmdutil: sort unresolved paths I noticed that `hg status` was printing unresolved paths in a non-deterministic order. This patch fixes that. I'm not sure if the sorting should be done in merge.mergestate.unresolved() instead. Either way fixes the presentation issue. Differential Revision: https://phab.mercurial-scm.org/D4929

fuzz: report error if Python code raised exception I think that's what we wanted to do, given the most of the code block is surrounded by try-except. 'lazymanifest(mdata)' is moved to the try block as it can fail.

revlog: explicitly initialize static variables I know .bss section is zero-filled, but explicit initialization should be better as we rely on that.

tests: do not change sys.path, it can break loading cext.parsers When running this tests with run-tests, the prefix would resolve mercurial.cext to the source tree and the attempt to load mercurial.cext.parsers would therefore fail since it doesn't exist in it. With the regular search path from run-tests, it is picked up from the temporary prefix correctly. Differential Revision: https://phab.mercurial-scm.org/D4910

tests: deal with differences in tic from ncurses and NetBSD Differential Revision: https://phab.mercurial-scm.org/D4909

closehead: fix close-head -r listification Differential Revision: https://phab.mercurial-scm.org/D4908

import-checker: use testparseutil.embedded() to centralize detection logic This patch fixes issues of embedded() in import-checker.py below, too. - overlook (or mis-detect) the end of inline script in doctest style - overlook inline script in doctest style at the end of file (and ignore invalid un-closed heredoc at the end of file, too) - overlook code fragment in styles below - "python <<EOF" (heredoc should be "cat > file <<EOF" style) - "cat > foobar.py << ANYLIMIT" (limit mark should be "EOF") - "cat << EOF > foobar.py" (filename should be placed before limit mark) - "cat >> foobar.py << EOF" (appending is ignored)

tests: use NO_CHECK_EOF as heredoc limit mark to omit checking code fragments This patch uses NO_CHECK_EOF as heredoc limit mark instead of EOF, in order to avoid checking all python code fragments in test-contrib-check-code.t, because almost all of them has un-recommended implementations intentionally.

contrib: add an utility module to parse test scripts This patch centralizes the logic to pick up code fragments embedded in *.t script, in order to: - apply checking with patterns in check-code.py on such embedded code fragments Now, check-code.py completely ignores embedded code fragments. I'll post another patch series to check them. - replace similar code path in contrib/import-checker.py Current import-checker.py has problems below. Fixing each of them is a little difficult, because parsing logic and pattern strings are tightly coupled. - overlook (or mis-detect) the end of inline script in doctest style 8a8dd6e4a97a fixed a part of this issue, but not enough. - it overlooks inline script in doctest style at the end of file (and ignores invalid un-closed heredoc at the end of file, too) - it overlooks code fragment in styles below - "python <<EOF" (heredoc should be "cat > file <<EOF" style) - "cat > foobar.py << ANYLIMIT" (limit mark should be "EOF") - "cat << EOF > foobar.py" (filename should be placed before limit mark) - "cat >> foobar.py << EOF" (appending is ignored) - it is not extensible for other than python code fragments (e.g. shell script, hgrc file, and so on) This new module can detect python code fragments in styles below: - inline script in doctest style (starting by " >>> " line) - python invocation with heredoc script ("python <<EOF") - python script in heredoc style (redirected into ".py" file) As an example of extensibility of new module, this patch also contains implementation to pick up code fragment below. This will be useful to add additional restriction for them, for example. - shell script in heredoc style (redirected into ".sh" file) - hgrc configuration in heredoc style (redirected into hgrc or $HGRCPATH)

tests: use environment variable indirectly Using environment variable directly in heredoc python code will cause syntax error at checking module importation by import-checker.py strictly, because "$varname" is invalid in Python syntax. "$varname" becomes valid after environment variable substitution by shell at writing text into file. Current import-checker.py overlooks code fragment changed in this patch, because of a restriction below for a line starting code fragment. - filename must be specified before limit mark NG: cat <<EOF > FILE.py OK: cat > FILE.py <<EOF import-checker.py itself is fixed in subsequent patch.

tests: import multiple modules separately Current import-checker.py overlooks code fragment changed in this patch, because of restrictions below for a line starting code fragment. - filename must be specified before limit mark NG: cat <<EOF > FILE.py OK: cat > FILE.py <<EOF - limit mark must not be quoted NG: cat > FILE.py <<'EOF' OK: cat > FILE.py <<EOF import-checker.py itself is fixed in subsequent patch.

fuzz: allow manifest fuzzer to detect leaks Huzzah! Differential Revision: https://phab.mercurial-scm.org/D4907

fuzzers: init Python in LLVMFuzzerInitialize and intentionally leak it This sidesteps leaks (or "leaks", I'm not sure) in CPython, and lets our fuzzer work. Differential Revision: https://phab.mercurial-scm.org/D4906

revlog: if the module is initialized more than once, don't leak nullentry Caught (annoyingly) by the manifest fuzzer. Differential Revision: https://phab.mercurial-scm.org/D4905

narrow: move remaining narrow-limited dirstate walks to core In most places we now filter at a higher level (the context object), but there are few places that relied on the dirstate walk to be filtered by the narrowspec. The important cases are those used by `hg add` and `hg addremove`. This patch updates them to pass in a matcher instead of relying on the dirstate to do the filtering. The dirstate filtering is also dropped in narrowdirstate.py. Not always filtering in the dirstate should be useful for a future `hg status --include-outside-narrow` option. These places now end up doing an unrestricted dirstate walk after this patch: * debugfileset * perfwalk * sparse (but restricted to sparse config) * largefiles I'll let anyone who cares about these cases adapt them to work with narrow if necessary. Differential Revision: https://phab.mercurial-scm.org/D4901

narrow: allow repo.narrowmatch(match) to include exact matches from "match" Differential Revision: https://phab.mercurial-scm.org/D4900

narrow: filter files by narrowspec in ctx.matches() This has no effect yet because 1) for committed changes, ctx.matches() just calls ctx.walk(), which we updated in the previous patch, and 2) for the working copy, the filtering is also done in the overridden dirstate.walk() in narrowdirstate. Differential Revision: https://phab.mercurial-scm.org/D4899

narrow: only walk files within narrowspec also for committed revisions Narrow has been walking only paths matching the narrowspec when walking the working copy. We have not done the same filtering when walking committed revisions (e.g. "hg files -r "), which seems a little odd. Let's make it consistent. Differential Revision: https://phab.mercurial-scm.org/D4898

status: intersect matcher with narrow matcher instead of filtering afterwards I seem to have done a very naive move of the code from the narrow extension into core in e411774a2e0f (narrow: move status-filtering to core and to ctx, 2018-08-02). It seems obvious that a better way is to intersect the matchers. Note that this means that when requesting status for the working directory in a narrow repo, we now pass the narrow matcher (possibly intersected with a user-provided matcher) into _buildstatus() and then into dirstate.status() and dirstate.walk(), which will the intersect it again with the narrow matcher. That's functionally fine, but wasteful. I hope to later remove the dirstate wrapping that adds the second layer of matcher intersection. Differential Revision: https://phab.mercurial-scm.org/D4897

localrepo: allow narrowmatch() to accept matcher to intersect with It's pretty common that we need to intersect a matcher we already have (usually from the user) with the narrow matcher. Let's make repo.narrowmatch() take an optional matcher to intersect with. Differential Revision: https://phab.mercurial-scm.org/D4896

obsolete: fix ValueError when stored note contains ':' char (issue5783) The newer version of `amend -n 'Some some'` accepts containing ':' char. The information contained in this note 'Testing::Obstore' gives ValueError, because we are trying to store more than 2 values in key and value. Differential Revision: https://phab.mercurial-scm.org/D4883 Differential Revision: https://phab.mercurial-scm.org/D4882

narrow: update TODO.rst now that we share format with sparse The narrowspec format was unified with the sparse format in f64ebe7d2259 (narrowspec: use sparse.parseconfig() to parse narrowspec file (BC), 2018-08-03). Differential Revision: https://phab.mercurial-scm.org/D4904

narrow: update TODO.rst now that we filter status in ctx The comment referred to was addressed in e411774a2e0f (narrow: move status-filtering to core and to ctx, 2018-08-02). I also think 84092edd5c88 (narrow: drop unnecessary overrides of patch, 2018-09-28) suggests that it was the right thing to do. Differential Revision: https://phab.mercurial-scm.org/D4903

narrow: update TODO.rst now that the narrowspec is in .hg/store We no longer have the unfortunate wrappostshare() and unsharenarrowspec() since 576eef1ab43d (narrow: move .hg/narrowspec to .hg/store/narrowspec (BC), 2018-08-02). Differential Revision: https://phab.mercurial-scm.org/D4902

py3: add 8 new passing tests to whitelist found by buildbot We are getting close! Differential Revision: https://phab.mercurial-scm.org/D4893

py3: use '%f' for floats instead of '%s' I remember Yuya saying we need to use bytestr() or '%r' because '%s' was clever. Not sure it applies to this or not. Differential Revision: https://phab.mercurial-scm.org/D4894

narrow: move adding of narrow server capabilities to core We use the experimental.narrow config option introduced in one of the previous patch and move the functionality of adding narrow server capabilities to core. Differential Revision: https://phab.mercurial-scm.org/D4891