[-Ztrait-solver=next, mir-typeck] instantiate hidden types in the root universe
Fixes an ICE in the test `member-constraints-in-root-universe`.
Main motivation is to make #112691 pass under the new solver.
r? ``@compiler-errors``
Fix return type notation associated type suggestion when -Zlower-impl-trait-in-trait-to-assoc-ty
This avoid suggesting the associated types generated for RPITITs when the one the code refers to doesn't exist and rustc looks for a suggestion.
r? `@compiler-errors`
Fix return type notation errors with -Zlower-impl-trait-in-trait-to-assoc-ty
This just adjust the way we check for RPITITs and uses the new helper method to do the "old" and "new" check at once.
r? `@compiler-errors`
Don't emit same goal as input during `wf::unnormalized_obligations`
r? `@aliemjay` cc `@lcnr`
I accidentally pruned the logic to handle `WF(?0)` when writing `wf::unnormalized_obligations`.
idk if you wanted to construct a test first, but this is an obvious fix. Copied the comment from above.
Fixesrust-lang/trait-system-refactor-initiative#36
Stop bubbling out hidden types from the eval obligation queries
r? `@compiler-errors`
I don't know why these were added, but they are not needed anymore. The relevant test is unaffected and I didn't see anything interesting in logging that would have justified it.
This PR has no effect on the new solver behaviour of cf2dff2b1e/tests/ui/impl-trait/issue-99642.rs (which is overflow) and cf2dff2b1e/tests/ui/impl-trait/issue-99642-2.rs (which is "unstable certainty ICE")
Various impl trait in assoc tys cleanups
r? `@compiler-errors`
All commits except for the last are pure refactorings. 274dab5bd658c97886a8987340bf50ae57900c39 allows struct fields to participate in deciding whether a function has an opaque in its signature.
best reviewed commit by commit
Stop hiding const eval limit in external macros
fixes#112748
We don't emit a hard error if there was a previous deny lint triggering with the same message. If that lint ends up not being emitted, we ICE and don't emit an error either.
Migrate `item_bounds` to `ty::Clause`
Should be simpler than the next PR that's coming up. Last three commits are the relevant ones.
r? ``@oli-obk`` or ``@lcnr``
Don't ICE on unnormalized struct tail in layout computation
1. We try to compute a `SizeSkeleton` even if a layout error occurs, but we really only need to do this if we get `LayoutError::Unknown`, since that means our type is too polymorphic to actually compute the full layout. If we have other errors, like `LayoutError::NormalizationError` or `LayoutError::Cycle`, then we can't really make any progress, since this represents an actual error.
2. Avoid using `normalize_erasing_regions` and `struct_tail_erasing_lifetimes` since those ICE on normalization errors, and since we may call `layout_of` in HIR typeck, we don't know for certain that we're on the happy path.
Fixes#112736
Always register sized obligation for argument
Removes a "hack" that skips registering sized obligations for parameters that are simple identifiers. This doesn't seem to affect diagnostics because we're probably already being smart enough about deduplicating identical error messages anyways.
Fixes#112608
rustc_session: default to -Z plt=yes on non-x86_64
Per the discussion in #106380 plt=no isn't a great default, and rust-lang/compiler-team#581 decided that the default should be PLT=yes for everything except x86_64. Not everyone agrees about the x86_64 part of this change, but this at least is an improvement in the state of things without changing the x86_64 situation, so I've attempted making this change in the name of not letting the perfect be the enemy of the good.
Please let me know if I've messed this up somehow - I'm not wholly confident I got this right.
r? `@nikic`
Avoid guessing unknown trait implementation in suggestions
When a trait is used without specifying the implementation (e.g. calling a non-member associated function without fully-qualified syntax) and there are multiple implementations available, use a placeholder comment for the implementation type in the suggestion instead of picking a random implementation.
Example:
```
fn main() {
let _ = Default::default();
}
```
Previous output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = <FileTimes as Default>::default();
| +++++++++++++ +
```
New output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = </* self type */ as Default>::default();
| +++++++++++++++++++ +
```
Fixes#112897
Don't structurally resolve during method ambiguity in probe
See comment in UI test for reason for the failure. This is all on the error path anyways, not really sure what the assertion is there to achieve anyways...
Fixes#111739
When a trait is used without specifying the implementation (e.g. calling
a non-member associated function without fully-qualified syntax) and
there are multiple implementations available, use a placeholder comment
for the implementation type in the suggestion instead of picking a
random implementation.
Example:
```
fn main() {
let _ = Default::default();
}
```
Previous output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = <FileTimes as Default>::default();
| +++++++++++++ +
```
New output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = </* self type */ as Default>::default();
| +++++++++++++++++++ +
```
Per the discussion in #106380 plt=no isn't a great default, and
rust-lang/compiler-team#581 decided that the default should be PLT=yes
for everything except x86_64. Not everyone agrees about the x86_64 part
of this change, but this at least is an improvement in the state of
things without changing the x86_64 situation, so I've attempted making
this change in the name of not letting the perfect be the enemy of the
good.
Account for sealed traits in privacy and trait bound errors
On trait bound errors caused by super-traits, identify if the super-trait is publicly accessibly and if not, explain "sealed traits".
```
error[E0277]: the trait bound `S: Hidden` is not satisfied
--> $DIR/sealed-trait-local.rs:17:20
|
LL | impl a::Sealed for S {}
| ^ the trait `Hidden` is not implemented for `S`
|
note: required by a bound in `Sealed`
--> $DIR/sealed-trait-local.rs:3:23
|
LL | pub trait Sealed: self:🅱️:Hidden {
| ^^^^^^^^^^^^^^^ required by this bound in `Sealed`
= note: `Sealed` is a "sealed trait", because to implement it you also need to implelement `a:🅱️:Hidden`, which is not accessible; this is usually done to force you to use one of the provided types that already implement it
```
Deduplicate privacy errors that point to the same path segment even if their deduplication span are different.
When encountering a path that is not reachable due to privacy constraints path segments other than the last, keep metadata for the last path segment's `Res` in order to look for alternative import paths for that item to suggest. If there are none, be explicit that the item is not accessible.
```
error[E0603]: module `b` is private
--> $DIR/re-exported-trait.rs:11:9
|
LL | impl a:🅱️:Trait for S {}
| ^ private module
|
note: the module `b` is defined here
--> $DIR/re-exported-trait.rs:5:5
|
LL | mod b {
| ^^^^^
help: consider importing this trait through its public re-export instead
|
LL | impl a::Trait for S {}
| ~~~~~~~~
```
```
error[E0603]: module `b` is private
--> $DIR/private-trait.rs:8:9
|
LL | impl a:🅱️:Hidden for S {}
| ^ ------ trait `b` is not publicly reachable
| |
| private module
|
note: the module `b` is defined here
--> $DIR/private-trait.rs:2:5
|
LL | mod b {
| ^^^^^
```
Suggest publicly accessible paths for items in private mod:
When encountering a path in non-import situations that are not reachable
due to privacy constraints, search for any public re-exports that the
user could use instead.
Track whether an import suggestion is offering a re-export.
When encountering a path with private segments, mention if the item at
the final path segment is not publicly accessible at all.
Add item visibility metadata to privacy errors from imports:
On unreachable imports, record the item that was being imported in order
to suggest publicly available re-exports or to be explicit that the item
is not available publicly from any path.
In order to allow this, we add a mode to `resolve_path` that will not
add new privacy errors, nor return early if it encounters one. This way
we can get the `Res` corresponding to the final item in the import,
which is used in the privacy error machinery.
When implementing a public trait with a private super-trait, we now emit
a note that the missing bound is not going to be able to be satisfied,
and we explain the concept of a sealed trait.
Avoid `Lrc<Box<dyn CodegenBackend>>`.
Because `Lrc<Box<T>>` is silly. (Clippy warns about `Rc<Box<T>>` and `Arc<Box<T>>`, and it would warn here if (a) we used Clippy with rustc, and (b) Clippy knew about `Lrc`.)
r? `@bjorn3`
