compiletest: Add directive `dont-require-annotations`
for making matching on specific diagnostic kinds non-exhaustive.
E.g. `//@ dont-require-annotations:ERROR`, like in the examples in this PR.
cc https://github.com/rust-lang/rust/pull/139427#issuecomment-2782827583Closes#132647 FYI `@BoxyUwU` since you've wanted this.
r? `@jieyouxu`
Add job summary links to post-merge report
This should make it much easier to investigate the individual job test/duration changes.
The GitHub API handling is a bit crude, but I didn't want to include octocrab, because it more than doubles the current number of dependencies of `citool`...
Can be tested with:
```bash
$ cargo run --manifest-path src/ci/citool/Cargo.toml post-merge-report bad13a970a1e008dd5d8
```
r? ```@marcoieni```
compiletest: Remove the `--logfile` flag
This flag is deprecated in libtest (#134283), and there's no evidence in-tree of this flag actually being passed to compiletest.
For detailed information about test results, bootstrap parses JSON output from compiletest instead (#108659).
As part of my experimental work on removing the libtest dependency from compiletest, it's useful to be able to disconnect libtest functionality that isn't needed.
compiletest maintenance: sort deps and drop dep on `anyhow`
Two changes:
1. Sort compiletest deps alphabetically because it was annoying me (harder to quickly glance what deps compiletest is using).
2. Drop dependency on `anyhow`. There's only one usage of `anyhow`, which is for `with_context` on sth that would immediately panic anyway.
compiletest: Stricter parsing for diagnostic kinds
Non-controversial parts of https://github.com/rust-lang/rust/pull/139427 not requiring many changes in the test suite.
r? ``@jieyouxu``
This flag is deprecated in libtest, and there's no evidence in-tree of this
flag actually being passed to compiletest.
(For detailed information about test results, bootstrap parses JSON output from
compiletest instead.)
Rollup of 10 pull requests
Successful merges:
- #138676 (Implement overflow for infinite implied lifetime bounds)
- #139024 (Make error message for missing fields with `..` and without `..` more consistent)
- #139098 (Tell LLVM about impossible niche tags)
- #139124 (compiler: report error when trait object type param reference self)
- #139321 (Update to new rinja version (askama))
- #139346 (Don't construct preds w escaping bound vars in `diagnostic_hir_wf_check`)
- #139386 (make it possible to use stage0 libtest on compiletest)
- #139421 (Fix trait upcasting to dyn type with no principal when there are projections)
- #139464 (Allow for reparsing failure when reparsing a pasted metavar.)
- #139490 (Update some comment/docs related to "extern intrinsic" removal)
r? `@ghost`
`@rustbot` modify labels: rollup
make it possible to use stage0 libtest on compiletest
With https://github.com/rust-lang/rust/pull/119899, building the library tree will require a stage 1 compiler. This is because `compiletest` is defined as a `ToolStd` (since https://github.com/rust-lang/rust/pull/68019) in order to use the in-tree library. As a result, https://github.com/rust-lang/rust/pull/119899 makes certain development workflows more difficult as changes on the compiler tree will now require recompiling `compiletest` each time.
This PR allows switching `ToolStd` to `ToolBootstrap` with a simple boolean option in `bootstrap.toml` to allow `compiletest` to use the stage 0 `libtest` instead.
The changes under `src/ci` are clearly intended to make sure that `compiletest` doesn't break during future bootstrap beta bumps.
Currently `compiletest` panics all over the place but doesn't really use
`anyhow` anyway. I'd like to introduce some more principled error
handling and disciplined diagnostic reporting in the near future.
Those that didn't previously preserved kind are now marked as not requiring annotations to keep the previous behavior.
Also, do not lose diagnostics with an empty message.
Remove support for `extern "rust-intrinsic"` blocks
Part of rust-lang/rust#132735
Looked manageable and there didn't appear to have been progress in the last two weeks,
so decided to give it a try.
Add new `PatKind::Missing` variants
To avoid some ugly uses of `kw::Empty` when handling "missing" patterns, e.g. in bare fn tys. Helps with #137978. Details in the individual commits.
r? ``@oli-obk``