status: remove pointless filtering by alwaysmatcher in morestatus The code has been like this since it was imported from FB's hg-experimental repo. It has been like that even since it was added in that repo. So I don't know why it looks that way. Perhaps the idea was to one day filter the unresolved paths by any patterns provided by the user. We can add a matcher back if we ever decide to do that. Differential Revision: https://phab.mercurial-scm.org/D7591

tests: add test for Rust formatting We enforce formatting for Python and C. It makes sense to do it for Rust as well. Since our rustfmt.toml relies on unstable rustfmt features, we need to use a Nightly rustfmt with --unstable-features in order for it to work. This is a bit hacky and I would prefer we remove this requirement. But for now, this commit assumes this is the way things must be and we go out of our way to detect and use the rustfmt from the "nightly" toolchain, as installed via rustup. We had to add some environment variables to the tests to make the Rust binaries happy. Otherwise when running rustfmt we get an error about no default toolchain being installed. Differential Revision: https://phab.mercurial-scm.org/D7579

rust: run rustfmt # skip-blame automated reformatting Differential Revision: https://phab.mercurial-scm.org/D7578

fuzz: clean up some repetition on building parsers.so fuzzers There was a lot of repetition here that I realized could be cleared out. I think there's some more work we could do here, but this is enough for now. Differential Revision: https://phab.mercurial-scm.org/D7568

fuzz: remove legacy setup for running fuzzers outside oss-fuzz We don't need this anymore. Differential Revision: https://phab.mercurial-scm.org/D7567

tests: finally fix up test-fuzz-targets.t It's been failing on my workstation for a while, since I have a new enough LLVM that I had the fuzzer goo, but not so new that I actually had FuzzedDataProvider. This is a better solution all around in my opinion. I _believe_ this should let us run these tests on most systems, even those using GCC instead of clang. That said, my one attempt to test this on my macOS laptop failed miserably, and I don't feel like doing more work on this right now. Differential Revision: https://phab.mercurial-scm.org/D7566

fuzz: make standalone_fuzz_target_runner call LLVMFuzzerInitialize Otherwise some of our fuzzers crash when they try and use Python. Differential Revision: https://phab.mercurial-scm.org/D7565

fuzz: use a more standard approach to allow local builds of fuzzers This is taken from the (improved since we started fuzzing) guide on ideal integrations. Rather than have our own wonky targets for building outside the fuzzer universe, we have a driver program we carry along and use when we're not using LibFuzzer. This will let us jettison a fair amount of goo. contrib/fuzz/standalone_fuzz_target_runner.cc is https://github.com/google/oss-fuzz/ file projects/example/my-api-repo/standalone from git revision c4579d9358a73ea5dbcc99cb985de1f2bf76dcf7, reformatted with out clang-format settings and a no-check-code comment added. It allows running a single test input through a fuzzer, rather than performing ongoing fuzzing as libfuzzer would. contrib/fuzz/FuzzedDataProvider.h is https://github.com/llvm/llvm-project/ file /compiler-rt/include/fuzzer/FuzzedDataProvider.h from git revision a44ef027ebca1598892ea9b104d6189aeb3bc2f0, reformatted with our clang-format settings and a no-check-code comment added. We can discard this if we instead want to add an hghave check for a new enough llvm that includes FuzzedDataProvder.h in the fuzzer headers. Differential Revision: https://phab.mercurial-scm.org/D7564

fuzz: use a variable to allow specifying python-config to use Eventually we should probably default this to just `python-config` and have the oss-fuzz build.sh script specify the sanpy python-config, but for now this lets us make progress. Differential Revision: https://phab.mercurial-scm.org/D7563

fuzz: suppress deprecated-register warnings in our compile These come from the Python.h headers still using the `register` keyword and our use of C++17. I think this will go away when we're using Python 3 for our fuzzing, but that can come later. Differential Revision: https://phab.mercurial-scm.org/D7562