progress: check what type of progress bar to use only once per topic This seems to have sped up `hg perfprogress` from 1.78 s to 1.41 s. Differential Revision: https://phab.mercurial-scm.org/D5530

progress: split up _print() method in bar-updating and debug-printing I just thought this was clearer, but it turned out to also simplify the next patch. This seems to have sped up `hg perfprogress` from 1.85 s to 1.78 s. Differential Revision: https://phab.mercurial-scm.org/D5529

progress: move cached debug flag from progress.progbar to scmutil.progress It's simpler this way. One possible drawback (and a possisble advantage) is that we now check the debug flag once per topic, so processes that generate new topics all the time will still check the flag frequently. Differential Revision: https://phab.mercurial-scm.org/D5528

progress: write ui.progress() in terms of ui.makeprogress() I think ui.makeprogress() should be the preferred interface and we should deprecate ui.progress(). All in-core callers already use ui.makeprogress(). Moving the logic to the scmutil.progress() will let us make further improvements. This seems to have sped up `hg perfprogress` from 1.92 s to 1.85 s, perhaps because we now skip the indirection of updating the progress bar via ui.progress(). Differential Revision: https://phab.mercurial-scm.org/D5527

testrunner: avoid capturing a regex group we don't care about Differential Revision: https://phab.mercurial-scm.org/D5536

remotefilelog: add newlines to ui.log() invocations The comment at the top of ui.log() says that the message should be a newline-terminated string. When using the blackbox logger, if the string does not end in a newline, the appearance in the file gets quite messy. This sometimes leaves a string with just the newline as the message, these are logged by the blackbox logger just fine. I don't know what other loggers do when logging structured data and a message that is just the newline. Differential Revision: https://phab.mercurial-scm.org/D5533

xdiff: don't attempt to use fuzzer inputs larger than 100k This is the recommended approach from [0], and limiting the input was suggested in https://github.com/google/oss-fuzz/issues/2076 when discussing our broken coverage build. 0: https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#custom-libfuzzer-options-for-clusterfuzz Differential Revision: https://phab.mercurial-scm.org/D5525

tests: support passing testcase after .t paths that have path separators This probably could have been implemented by changing the regex above this bit of code, but I wasn't sure if it would end up handling various OSes correctly, so I decided to go with this version instead. Previously: $ tests/run-tests.py tests/test-ssh.t -l running 2 tests using 2 parallel processes .. # Ran 2 tests, 0 skipped, 0 failed. $ tests/run-tests.py tests/test-ssh.t#sshv1 -l running 0 tests using 0 parallel processes # Ran 0 tests, 0 skipped, 0 failed. Now: $ tests/run-tests.py tests/test-ssh.t -l running 2 tests using 2 parallel processes .. # Ran 2 tests, 0 skipped, 0 failed. $ tests/run-tests.py tests/test-ssh.t#sshv1 -l running 1 tests using 1 parallel processes . # Ran 1 tests, 0 skipped, 0 failed. Differential Revision: https://phab.mercurial-scm.org/D5535

progress: document progress.debug config option I think it was not spotted by test-check-config.t that we had not documented it because no caller refers to the ui object simply as "ui" (it was either "self.ui" or just "self"). Differential Revision: https://phab.mercurial-scm.org/D5526

tests: migrate test-wireproto-serverreactor.py to our internal CBOR This leaves the only client of thirdparty.cbor as test-cbor.py, which appears to be testing the behavior of cborutil against cbor. We should figure out some appropriate test strings and drop thirdparty.cbor, but that's a mission for another day. Differential Revision: https://phab.mercurial-scm.org/D5522

state: update comment about use of CBOR We use our internal cbor library, not the vendored one in thirdparty. Differential Revision: https://phab.mercurial-scm.org/D5518

rust-ancestors: adjust branches and inline comments per previous change Now the top-level "if" can be read as both_visit|revs_visit|bases_visit.

rust-ancestors: remove unreachable conditions from missing_ancestors()

rust-ancestors: duplicate loop that visits parents of revs/bases As the inline comment says, it can't be cleanly implemented in Rust. It's better to duplicate the code instead of inserting "if"s. The loop will be cleaned up by future commits.

rust-ancestors: adjust indent level to make next change easier to follow