Improve diagnostics for `HostEffectPredicate` in the new solver
Adds derived cause for host effect predicates. Some diagnostics regress, but that's connected to the fact that our predicate visitor doesn't play well with aliases just yet.
Add support for wasm exception handling to Emscripten target
This is a draft because we need some additional setting for the Emscripten target to select between the old exception handling and the new exception handling. I don't know how to add a setting like that, would appreciate advice from Rust folks. We could maybe choose to use the new exception handling if `Ctarget-feature=+exception-handling` is passed? I tried this but I get errors from llvm so I'm not doing it right.
Rollup of 7 pull requests
Successful merges:
- #134742 (Use `PostBorrowckAnalysis` in `check_coroutine_obligations`)
- #134771 (Report correct `SelectionError` for `ConstArgHasType` in new solver fulfill)
- #134951 (Suppress host effect predicates if underlying trait doesn't hold)
- #135097 (bootstrap: Consolidate coverage test suite steps into a single step)
- #135146 (Don't enable anyhow's `backtrace` feature in opt-dist)
- #135153 (chore: remove redundant words in comment)
- #135157 (Move the has_errors check in rustdoc back to after TyCtxt is created)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't enable anyhow's `backtrace` feature in opt-dist
As of the stabilization of `std::backtrace` in Rust 1.65, this package flag has no effect other than to enable an unused dependency on the `backtrace` crate.
(See <af0937ef72/Cargo.toml (L18-L23)>.)
While the presence of this feature in opt-dist doesn't cause other tools (which use anyhow) to actually *build* backtrace, it does affect the global crate graph used for dependency version resolution. After removing this feature, we can use `cargo tree --invert --package backtrace` to see that the only remaining reverse-dependency of backtrace is `color-eyre`, which is used by `ui_test`.
bootstrap: Consolidate coverage test suite steps into a single step
Now that I have more understanding of bootstrap steps, and a renewed distaste for unnecessary macros, I have managed to express the subtleties of the `tests/coverage` test suite in a single step defined in ordinary code, with no need for helper macros.
Deciding which modes to run is still a bit clunky due to limitations in existing ShouldRun/PathSet APIs, but I think it's a net improvement over having to declare several different steps to handle the suite path and aliases.
The interaction with `--skip` isn't as nice as I'd like, but all of the known limitations are limitations that already existed in the previous implementation.
One minor change is that by default compiletest is now invoked in `coverage-run` mode even when cross-compiling. However, in that situation compiletest still knows that it should skip all of the individual coverage-run tests.
r? jieyouxu (or reassign)
Suppress host effect predicates if underlying trait doesn't hold
Don't report two errors for when the (`HostEffectPredicate`) `T: const Trait` isn't implemented because (`TraitPredicate`) `T: Trait` doesn't even hold.
Use `PostBorrowckAnalysis` in `check_coroutine_obligations`
This currently errors with:
```
error: concrete type differs from previous defining opaque type use
--> tests/ui/coroutine/issue-52304.rs:10:21
|
10 | pub fn example() -> impl Coroutine {
| ^^^^^^^^^^^^^^ expected `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'{erased} i32 return_ty=() witness={example::{closure#0}}}`, got `{example::{closure#0} upvar_tys=() resume_ty=() yield_ty=&'static i32 return_ty=() witness={example::{closure#0}}}`
|
= note: previous use here
```
This is because we end up redefining the opaque in `check_coroutine_obligations` but with the `yield_ty = &'erased i32` from hir typeck, which causes the *equality* check for opaques to fail.
The coroutine obligtions in question (when `-Znext-solver` is enabled) are:
```
Binder { value: TraitPredicate(<Opaque(DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), []) as std::marker::Sized>, polarity:Positive), bound_vars: [] }
Binder { value: AliasRelate(Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. })), Equate, Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()]))), bound_vars: [] }
Binder { value: AliasRelate(Term::Ty(Coroutine(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), [(), (), &'{erased} i32, (), CoroutineWitness(DefId(0:6 ~ issue_52304[4c6d]::example::{closure#0}), []), ()])), Subtype, Term::Ty(Alias(Opaque, AliasTy { args: [], def_id: DefId(0:5 ~ issue_52304[4c6d]::example::{opaque#0}), .. }))), bound_vars: [] }
```
Ignoring the fact that we end up stalling some really dumb obligations here (lol), I think it makes more sense for us to be using post borrowck analysis for this check anyways.
r? lcnr
Merge the intrinsic and user tests for `select_unpredictable`
[1] mentions that having a single test with `-Zmerge-functions=disabled` is preferable to having two separate tests. Apply that to the new `select_unpredictable` test here.
[1]: https://github.com/rust-lang/rust/pull/133964#issuecomment-2569693325
A few borrowck tweaks to improve 2024 edition migration lints
See first two commits' changes to test outputs. Test coverage in this area is kinda weak, but I think it affects more cases than this (like the craters that will begin to trigger the `tail_expr_drop_order` tests in #134523).
Third commit is a drive-by change that removes a deref hack from `UseSpans` which doesn't really improve diagnostics much.
Mention `unnameable_types` in `unreachable_pub` documentation.
This link makes sense because someone who wishes to avoid unusable `pub` is likely, but not guaranteed, to be interested in avoiding unnameable types.
Also fixed some grammar problems I noticed in the area.
Fixes#116604.
r? Urgau
dev guide ping group and set adhoc reviewers to compiler
r? ``@jieyouxu`` ``@Kobzol``
I added you both to the `cc` list since you're both also on the list of owners for `src/doc/rustc-dev-guide`
triagebot: label `src/doc/rustc-dev-guide` changes with `A-rustc-dev-guide`
Probably should also create a dev-guide reviewer pool for this repo 🤔
r? ``@Kobzol``
Add doc aliases for `libm` and IEEE names
Searching "fma" in the Rust documentation returns results for `intrinsics::fma*`, but does not point to the user-facing `mul_add`. Add aliases for `fma*` and the IEEE operation name `fusedMultiplyAdd`. Add the IEEE name to `sqrt` as well, `squareRoot`.
add m68k-unknown-none-elf target
r? `@workingjubilee`
The existing `m68k-unknown-linux-gnu` target builds `std` by default, requires atomics, and has a base cpu with an fpu. A smaller/more embedded target is desirable both to have a baseline target for the ISA, as well to make debugging easier for working on the llvm backend. Currently this target is using the `M68010` as the minimum CPU due, but as missing features are merged into the `M68k` llvm backend I am hoping to lower this further.
I have been able to build very small crates using a toolchain built against this target (together with a later version of `object`) using the configuration described in the target platform-support documentation, although getting anything of substantial complexity to build quickly hits errors in the llvm backend
As of the stabilization of `std::backtrace` in Rust 1.65, this package flag has
no effect other than to enable an unused dependency on the `backtrace` crate.
This link makes sense because someone who wishes to avoid unusable `pub`
is likely, but not guaranteed, to be interested in avoiding unnameable
types.
Also fixed some grammar problems I noticed in the area.
Fixes#116604.
Clarified the documentation on `core::iter::from_fn` and `core::iter::successors`
This PR clarifies the closure requirements for `core::iter::from_fn` and `core::iter::successors`.
`std::iter::successors` in particular is a bit difficult to understand if you are not already familiar with the signature of [`checked_mul`](https://docs.rs/num/latest/num/trait.CheckedMul.html) used in the example.
See https://github.com/rust-lang/rust/issues/135087
cg_llvm: Use constants for DWARF opcodes, instead of FFI calls
Split off from #134009 to incorporate feedback from https://github.com/rust-lang/rust/pull/134009#discussion_r1903133906.
Most of the constant values now come from gimli, which is already a compiler dependency.
I noticed that `DW_OP_LLVM_fragment` is an LLVM detail that is not defined by DWARF and could hypothetically change, so I added a static assertion on the C++ side to detect that if it ever happens.
r? workingjubilee
Add a notion of "some ABIs require certain target features"
I think I finally found the right shape for the data and checks that I recently added in https://github.com/rust-lang/rust/pull/133099, https://github.com/rust-lang/rust/pull/133417, https://github.com/rust-lang/rust/pull/134337: we have a notion of "this ABI requires the following list of target features, and it is incompatible with the following list of target features". Both `-Ctarget-feature` and `#[target_feature]` are updated to ensure we follow the rules of the ABI. This removes all the "toggleability" stuff introduced before, though we do keep the notion of a fully "forbidden" target feature -- this is needed to deal with target features that are actual ABI switches, and hence are needed to even compute the list of required target features.
We always explicitly (un)set all required and in-conflict features, just to avoid potential trouble caused by the default features of whatever the base CPU is. We do this *before* applying `-Ctarget-feature` to maintain backward compatibility; this poses a slight risk of missing some implicit feature dependencies in LLVM but has the advantage of not breaking users that deliberately toggle ABI-relevant target features. They get a warning but the feature does get toggled the way they requested.
For now, our logic supports x86, ARM, and RISC-V (just like the previous logic did). Unsurprisingly, RISC-V is the nicest. ;)
As a side-effect this also (unstably) allows *enabling* `x87` when that is harmless. I used the opportunity to mark SSE2 as required on x86-64, to better match the actual logic in LLVM and because all x86-64 chips do have SSE2. This infrastructure also prepares us for requiring SSE on x86-32 when we want to use that for our ABI (and for float semantics sanity), see https://github.com/rust-lang/rust/issues/133611, but no such change is happening in this PR.
r? `@workingjubilee`
Subtree sync for rustc_codegen_cranelift
Aside from a Cranelift update, nothing major this time.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
