Don't pick `T: FnPtr` nested goals as the leaf goal in diagnostics for new solver
r? `@lcnr`
See `tests/ui/traits/next-solver/diagnostics/dont-pick-fnptr-bound-as-leaf.rs` for a minimized example of what code this affects the diagnostics off. The output of running nightly `-Znext-solver` on that test is the following:
```
error[E0277]: the trait bound `Foo: Trait` is not satisfied
--> src/lib.rs:14:20
|
14 | requires_trait(Foo);
| -------------- ^^^ the trait `FnPtr` is not implemented for `Foo`
| |
| required by a bound introduced by this call
|
note: required for `Foo` to implement `Trait`
--> src/lib.rs:7:16
|
7 | impl<T: FnPtr> Trait for T {}
| ----- ^^^^^ ^
| |
| unsatisfied trait bound introduced here
note: required by a bound in `requires_trait`
--> src/lib.rs:11:22
|
11 | fn requires_trait<T: Trait>(_: T) {}
| ^^^^^ required by this bound in `requires_trait`
```
Part of rust-lang/trait-system-refactor-initiative#148
Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors
r? `@lcnr`
I added `structurally_normalize_term` so that code that is generic over ty or const can use the structurally normalize helpers. See `tests/ui/traits/next-solver/diagnostics/alias_relate_error_uses_structurally_normalize.rs` for a description of the reason for the (now fixed) ICEs
This CL makes a number of small changes to dyn compatibility errors:
- "object safety" has been renamed to "dyn-compatibility" throughout
- "Convert to enum" suggestions are no longer generated when there
exists a type-generic impl of the trait or an impl for `dyn OtherTrait`
- Several error messages are reorganized for user readability
Additionally, the dyn compatibility error creation code has been
split out into functions.
cc #132713
cc #133267
remove support for the (unstable) #[start] attribute
As explained by `@Noratrieb:`
`#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
- `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
- `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways*
`#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program.
So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
Note that this feature has **not** been RFCed in the first place.
*This comment was posted [in May](https://github.com/rust-lang/rust/issues/29633#issuecomment-2088596042) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.*
Closes https://github.com/rust-lang/rust/issues/29633
try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
Rework dyn trait lowering to stop being so intertwined with trait alias expansion
This PR reworks the trait object lowering code to stop handling trait aliases so funky, and removes the `TraitAliasExpander` in favor of a much simpler design. This refactoring is important for making the code that I'm writing in https://github.com/rust-lang/rust/pull/133397 understandable and easy to maintain, so the diagnostics regressions are IMO inevitable.
In the old trait object lowering code, we used to be a bit sloppy with the lists of traits in their unexpanded and expanded forms. This PR largely rewrites this logic to expand the trait aliases *once* and handle them more responsibly throughout afterwards.
Please review this with whitespace disabled.
r? lcnr
new solver: prefer trivial builtin impls
As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/needs_help.3A.20trivial.20builtin.20impls), this PR:
- adds a new `BuiltinImplSource::Trivial` source, and marks the `Sized` builtin impls as trivial
- prefers these trivial builtin impls in `merge_trait_candidates`
The comments can likely be wordsmithed a bit better, and I ~stole~ was inspired by the old solver ones. Let me know how you want them improved.
When enabling the new solver for tests, 3 UI tests now pass:
- `regions/issue-26448-1.rs` and its sibling `regions/issue-26448-2.rs` were rejected by the new solver but accepted by the old one
- and `issues/issue-42796.rs` where the old solver emitted some overflow errors in addition to the expected error
(For some reason one of these tests is run-pass, but I can take care of that another day)
r? lcnr
Detect if-else chains with a missing final else in type errors
```
error[E0308]: `if` and `else` have incompatible types
--> $DIR/if-else-chain-missing-else.rs:12:12
|
LL | let x = if let Ok(x) = res {
| ______________-
LL | | x
| | - expected because of this
LL | | } else if let Err(e) = res {
| | ____________^
LL | || return Err(e);
LL | || };
| || ^
| ||_____|
| |_____`if` and `else` have incompatible types
| expected `i32`, found `()`
|
= note: `if` expressions without `else` evaluate to `()`
= note: consider adding an `else` block that evaluates to the expected type
```
We probably want a longer explanation and fewer spans on this case.
Partially address #133316.
```
error[E0308]: `if` and `else` have incompatible types
--> $DIR/if-else-chain-missing-else.rs:12:12
|
LL | let x = if let Ok(x) = res {
| ______________-
LL | | x
| | - expected because of this
LL | | } else if let Err(e) = res {
| | ____________^
LL | || return Err(e);
LL | || };
| || ^
| ||_____|
| |_____`if` and `else` have incompatible types
| expected `i32`, found `()`
|
= note: `if` expressions without `else` evaluate to `()`
= note: consider adding an `else` block that evaluates to the expected type
```
We probably want a longer explanation and fewer spans on this case.
Partially address #133316.
Prefer lower `TraitUpcasting` candidates in selection
Fixes#135463. The underlying cause is this ambiguity, but it's more clear (and manifests as a coercion error, rather than a MIR validation error) when it's written the way I did in the UI test.
Sorry this is cursed r? lcnr
Treat safe target_feature functions as unsafe by default [less invasive variant]
This unblocks
* #134090
As I stated in https://github.com/rust-lang/rust/pull/134090#issuecomment-2541332415 I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions.
This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
Make sure we can produce `ConstArgHasWrongType` errors for valtree consts
I forgot about `ty::ConstKind::Value` in #134771.
The error message here could use some work -- both in the new trait solver and the old trait solver. But unrelated to the issue here.
Fixes https://github.com/rust-lang/rust/issues/135361 -- this was only ICEing in coherence because coherence uses the new trait solver, but I don't think the minimization is worth committing compared to the test I added.
r? ```@lcnr``` or ```@BoxyUwU```
Exclude dependencies of `std` for diagnostics
Currently crates in the sysroot can show up in diagnostic suggestions, such as in https://github.com/rust-lang/rust/issues/135232. To prevent this, duplicate `all_traits` into `visible_traits` which only shows traits in non-private crates.
Setting `#![feature(rustc_private)]` overrides this and makes items in private crates visible as well, since `rustc_private` enables use of `std`'s private dependencies.
This may be reviewed per-commit.
Fixes: https://github.com/rust-lang/rust/issues/135232
Add an alternative to `tcx.all_traits()` that only shows traits that the
user might be able to use, for diagnostic purposes. With this available,
make use of it for diagnostics including associated type errors, which
is part of the problem with [1].
Includes a few comment updates for related API.
[1]: https://github.com/rust-lang/rust/issues/135232
fix ICE with references to infinite structs in consts
fixes https://github.com/rust-lang/rust/issues/114484
Normalizing `<Type as Pointee>::Metadata` may emit a (non-fatal) error during trait selection if finding the struct tail of `Type` hits the recursion limit. When this happens, prior this PR, we would treat the projection as rigid, i.e. don't normalize it further. This PR changes it so that we normalize to `ty::Error` instead.
This is important, because to compute the layout of `&Type` we need to compute the layout of `<Type as Pointee>::Metadata`
2ae9916816/compiler/rustc_ty_utils/src/layout.rs (L247-L273)
and computing the layout of a rigid alias will (correctly) fail and needs to report an error to the user. For example:
```rust
trait Project {
type Assoc;
}
fn foo<T: Project>() {
[(); {
let _: Option<T::Assoc> = None;
// ^^^^^^^^ this projection is rigid, so we can't know it's layout
0
}];
}
```
```
error: constant expression depends on a generic parameter
--> src/lib.rs:6:10
|
6 | [(); {
| __________^
7 | | let _: Option<T::Assoc> = None;
8 | | // ^^^^^^^^ this projection is rigid, so we can't know it's layout
9 | | 0
10 | | }];
| |_____^
|
= note: this may fail depending on what value the parameter takes
```
For non-generic rigid projections we will currently ICE, because we incorrectly assume that `LayoutError::Unknown` means that a const must be generic (https://github.com/rust-lang/rust/issues/135138). This is being fixed and turned into a proper error in https://github.com/rust-lang/rust/pull/135158.
```rust
#![feature(trivial_bounds)]
trait Project {
type Assoc;
}
fn foo()
where
u8: Project,
{
[(); {
let _: Option<<u8 as Project>::Assoc> = None; // ICEs currently, but will be an error
0
}];
}
```
However, if we hit the recursion limit when normalizing `<Type as Pointee>::Metadata` we don't want to report a layout error, because we already emitted the recursion error. So by normalizing to `ty::Error` here, we get a `LayoutError::ReferencesError` instead of a `LayoutError::Unknown` and don't report the layout error to the user.
Adds `#[rustc_force_inline]` which is similar to always inlining but
reports an error if the inlining was not possible, and which always
attempts to inline annotated items, regardless of optimisation levels.
It can only be applied to free functions to guarantee that the MIR
inliner will be able to resolve calls.
Add a list of symbols for stable standard library crates
There are a few locations where the crate name is checked against an enumerated list of `std`, `core`, `alloc`, and `proc_macro`, or some subset thereof. In most cases when we are looking for any "standard library" crate, all four crates should be treated the same. Change this so the crates are listed in one place, and that list is used wherever a list of `std` crates is needed.
`test` could be considered relevant in some of these cases, but generally treating it separate from the others seems preferable while it is unstable.
There are also a few places that Clippy will be able to use this.
Implement `const Destruct` in old solver
Self-explanatory. Not totally settled that this is the best structure for built-in trait impls for effect goals in the new solver, but it's almost certainly the simplest.
r? lcnr or re-roll
Suggest Replacing Comma with Semicolon in Incorrect Repeat Expressions
Fixes#80173
This PR detects typos in repeat expressions like `["_", 10]` and `vec![String::new(), 10]` and suggests replacing comma with semicolon.
Also, improves code in other place by adding doc comments and making use of a helper function to check if a type implements `Clone`.
References:
1. For `vec![T; N]`: https://doc.rust-lang.org/std/macro.vec.html
2. For `[T; N]`: https://doc.rust-lang.org/std/primitive.array.html
There are a few locations where the crate name is checked against an
enumerated list of `std`, `core`, `alloc`, and `proc_macro`, or some
subset thereof. In most of these cases, all four crates should likely be
treated the same. Change this so the crates are listed in one place, and
that list is used wherever a list of `std` crates is needed.
`test` could be considered relevant in some of these cases, but
generally treating it separate from the others seems preferable while it
is unstable.
There are also a few places that Clippy will be able to use this.
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.
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.
