Uplift next trait solver to `rustc_next_trait_solver`
🎉
There's so many FIXMEs! Sorry! Ideally this merges with the FIXMEs and we track and squash them over the near future.
Also, this still doesn't build on anything other than rustc. I still need to fix `feature = "nightly"` in `rustc_type_ir`, and remove and fix all the nightly feature usage in the new trait solver (notably: let-chains).
Also, sorry `@lcnr` I know you asked for me to separate the commit where we `mv rustc_trait_selection/solve/... rustc_next_trait_solver/solve/...`, but I had already done all the work by that point. Luckily, `git` understands the file moves so it should still be relatively reviewable.
If this is still very difficult to review, then I can do some rebasing magic to try to separate this out. Please let me know!
r? lcnr
Replace all `&DiagCtxt` with a `DiagCtxtHandle<'_>` wrapper type
r? `@davidtwco`
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
Basically I will add a field to the `DiagCtxtHandle` that refers back to the `InferCtxt`'s (and others) `Option<ErrorHandled>`, allowing us to immediately taint these contexts when emitting an error and not needing manual tainting anymore (which is easy to forget and we don't do in general anyway)
More thorough status-quo tests for `#[coverage(..)]`
In light of the stabilization push at https://github.com/rust-lang/rust/issues/84605#issuecomment-2166514660, I have written some tests to more thoroughly capture the current behaviour of the `#[coverage(..)]` attribute.
These tests aim to capture the *current* behaviour, which is not necessarily the desired behaviour. For example, some of the error message are not great, some things that perhaps ought to cause an error do not, and recursive coverage attributes have not been implemented yet.
`@rustbot` label +A-code-coverage
coverage: Add debugging flag `-Zcoverage-options=no-mir-spans`
When set, this flag skips the code that normally extracts coverage spans from MIR statements and terminators. That sometimes makes it easier to debug branch coverage and MC/DC coverage instrumentation, because the coverage output is less noisy.
For internal debugging only. If future code changes would make it hard to keep supporting this flag, it should be removed at that time.
`@rustbot` label +A-code-coverage
Migrate `error-found-staticlib-instead-crate`, `output-filename-conflicts-with-directory`, `output-filename-overwrites-input`, `native-link-modifier-verbatim-rustc` and `native-link-verbatim-linker` `run-make` tests to `rmake.rs` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Rework `feature(precise_capturing)` to represent `use<...>` as a syntactical bound
Reworks `precise_capturing` for a recent lang-team consensus.
Specifically:
> The conclusion of the team is that we'll make use<..> a bound. That is, we'll support impl use<..> + Trait, impl Trait + use<..>, etc.
> For now, we will support at most one such bound in a list of bounds, and semantically we'll only support these bounds in the item bounds of RPIT-like impl Trait opaque types (i.e., in the places discussed in the RFC).
Lang decision in favor of this approach:
- https://github.com/rust-lang/rust/issues/125836#issuecomment-2151351849
Tracking:
- https://github.com/rust-lang/rust/issues/123432
Return opaque type from PanicInfo::message()
This changes the return type of the (unstable) PanicInfo::message() method to an opaque type (that implements Display). This allows for a bit more flexibility in the future.
See https://github.com/rust-lang/rust/issues/66745
Migrate `extern-flag-fun`, `incremental-debugger-visualiser` and `incremental-session-fail` `run-make` tests to `rmake.rs`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: arm-android
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc
try-job: dist-i686-mingw
Migrate `link-arg`, `link-dedup` and `issue-26092` `run-make` tests to `rmake` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
All of these tests check if rustc's output contains (or does not) contain certain strings. Does that mean these could be better suited to becoming UI/codegen tests?
try-job: x86_64-msvc
Update books
## rust-lang/book
5 commits in 5228bfac8267ad24659a81b92ec5417976b5edbc..45c1a6d69edfd1fc91fb7504cb73958dbd09441e
2024-06-14 16:25:20 UTC to 2024-06-11 13:43:29 UTC
- Convert Chapters 12-14 (rust-lang/book#3959)
- Fix a typo in `ADMIN_TASKS` (rust-lang/book#3958)
- Swap inconsistent `assert_eq!` argument order in testing chapter (rust-lang/book#3497)
- Convert chapter 11 to use Listing component (rust-lang/book#3955)
- Convert ch02 and ch03 listings to `<Listing>` (rust-lang/book#3926)
## rust-lang/edition-guide
5 commits in bbaabbe088e21a81a0d9ae6757705020d5d7b416..cb58c430b4e8054c2cb81d2d4434092c482a93d8
2024-06-13 16:52:10 UTC to 2024-06-06 21:19:03 UTC
- Merge PR #307: Add IntoIterator for Box<[T]> in 2024
- "cargo fix" now removes "extern crate" statements (rust-lang/edition-guide#305)
- typo (rust-lang/edition-guide#306)
- Remove public/private dependencies from 2024 (rust-lang/edition-guide#303)
- Add stub for macro fragment matcher updates (rust-lang/edition-guide#302)
## rust-lang/reference
1 commits in 6019b76f5b28938565b251bbba0bf5cc5c43d863..0b805c65804019b0ac8f2fe3117afad82a6069b8
2024-06-07 16:06:44 UTC to 2024-06-07 16:06:44 UTC
- union syntax fix for empty field list (rust-lang/reference#1509)
## rust-lang/rust-by-example
4 commits in 4840dca06cadf48b305d3ce0aeafde7f80933f80..b1d97bd6113aba732b2091ce093c76f2d05bb8a0
2024-06-17 12:45:15 UTC to 2024-06-06 11:44:38 UTC
- Update ja.po and mdbook-i18n-helpers (rust-lang/rust-by-example#1863)
- Fix typo (rust-lang/rust-by-example#1861)
- Update instruction to add language entry of TRANSLATING.md (rust-lang/rust-by-example#1860)
- Incorrect variable name according to comments (rust-lang/rust-by-example#1858)
## rust-lang/rustc-dev-guide
10 commits in 6a7374bd87cbac0f8be4fd4877d8186d9c313985..aec82168dd3121289a194b381f56076fc789a4d2
2024-06-16 06:39:57 UTC to 2024-06-04 05:31:05 UTC
- tell about `STAGE0_MISSING_TARGETS` for new targets (rust-lang/rustc-dev-guide#1996)
- Rewrite CI documentation (rust-lang/rustc-dev-guide#1972)
- Compiletest docs for recently-added features (rust-lang/rustc-dev-guide#1994)
- Add {{target}} to header substitutions (rust-lang/rustc-dev-guide#1995)
- run-make: add tip about quick-compile with stage0 rustc (rust-lang/rustc-dev-guide#1993)
- Mention `COMPILETEST_REQUIRE_ALL_LLVM_COMPONENTS` in `needs-llvm-components` documentation (rust-lang/rustc-dev-guide#1990)
- Add run-make port initiative to the Recurring work section (rust-lang/rustc-dev-guide#1992)
- Document the `//@ unused-revision-names:` test header (rust-lang/rustc-dev-guide#1991)
- Fix dead links (rust-lang/rustc-dev-guide#1988)
- use `&` to load completions for PowerShell (rust-lang/rustc-dev-guide#1978)
Rename `InstanceDef` -> `InstanceKind`
Renames `InstanceDef` to `InstanceKind`. The `Def` here is confusing, and makes it hard to distinguish `Instance` and `InstanceDef`. `InstanceKind` makes this more obvious, since it's really just describing what *kind* of instance we have.
Not sure if this is large enough to warrant a types team MCP -- it's only 53 files. I don't personally think it does, but happy to write one if anyone disagrees. cc ``@rust-lang/types``
r? types
