Implement non-const `Destruct` trait in new solver
Makes it so that we can call stdlib methods like `Option::map` in **non-const** environments, since *many* stdlib methods have `Destruct` bounds 😅
This doesn't bother to implement `const Destruct` yet, but it shouldn't be too hard to do so. Just didn't bother since we already don't have much support for const traits in the new solver anyways. I'd be happy to add skeleton support for `const Destruct`, though, if the reviewer desires.
Return nested obligations from canonical response var unification
Handle alias-eq obligations being emitted from `instantiate_and_apply_query_response` in:
* `EvalCtxt` - by processing the nested obligations in the next loop by `new_goals`
* `FulfillCtxt` - by adding the nested obligations to the fulfillment's pending obligations
* `InferCtxt::evaluate_obligation` - ~~by returning `EvaluationResult::EvaluatedToAmbig` (boo 👎, see the FIXME)~~ same behavior as above, since we use fulfillment and `select_where_possible`
The only one that's truly sketchy is `evaluate_obligation`, but it's not hard to modify this behavior moving forward.
From #109037, I think a smaller repro could be crafted if I were smarter, but I am not, so I just took this from #105878.
r? `@lcnr` cc `@BoxyUwU`
Refine error spans for const args in hir typeck
Improve just a couple of error messages having to do with mismatched consts.
r? `@ghost` i'll put this up when the dependent commits are merged
Move useless_anynous_reexport lint into unused_imports
As mentioned in https://github.com/rust-lang/rust/pull/109003, this check should have been merged with `unused_imports` in the start.
r? `@petrochenkov`
Lint ambiguous glob re-exports
Attempts to fix#107563.
We currently already emit errors for ambiguous re-exports when two names are re-exported *specifically*, i.e. not from glob exports. This PR attempts to emit deny-by-default lints for ambiguous glob re-exports.
rustc_interface: Add a new query `pre_configure`
It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early.
Crate-level cfg attributes on the crate itself are then expanded normally during the main expansion pass, like attributes on any other nodes.
This is a continuation of https://github.com/rust-lang/rust/pull/92473 and one more step to very unstable crate-level proc macro attributes maybe actually working.
Previously crate attributes were pre-configured simultaneously with feature extraction, and then written directly into `ast::Crate`.
Rollup of 7 pull requests
Successful merges:
- #108541 (Suppress `opaque_hidden_inferred_bound` for nested RPITs)
- #109137 (resolve: Querify most cstore access methods (subset 2))
- #109380 (add `known-bug` test for unsoundness issue)
- #109462 (Make alias-eq have a relation direction (and rename it to alias-relate))
- #109475 (Simpler checked shifts in MIR building)
- #109504 (Stabilize `arc_into_inner` and `rc_into_inner`.)
- #109506 (make param bound vars visibly bound vars with -Zverbose)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make alias-eq have a relation direction (and rename it to alias-relate)
Emitting an "alias-eq" is too strict in some situations, since we don't always want strict equality between a projection and rigid ty. Adds a relation direction.
* I could probably just reuse this [`RelationDir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/combine/enum.RelationDir.html) -- happy to uplift that struct into middle and use that instead, but I didn't feel compelled to... 🤷
* Some of the matching in `compute_alias_relate_goal` is a bit verbose -- I guess I could simplify it by using [`At::relate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/at/struct.At.html#method.relate) and mapping the relation-dir to a variance.
* Alternatively, I coulld simplify things by making more helper functions on `EvalCtxt` (e.g. `EvalCtxt::relate_with_direction(T, T)` that also does the nested goal registration). No preference.
r? ```@lcnr``` cc ```@BoxyUwU``` though boxy can claim it if she wants
NOTE: first commit is all the changes, the second is just renaming stuff
Updates `interpret`, `codegen_ssa`, and `codegen_cranelift` to consume the new cast instead of the intrinsic.
Includes `CastTransmute` for custom MIR building, to be able to test the extra UB.
new solver cleanup + implement coherence
the cleanup:
- change `Certainty::unify_and` to consider ambig + overflow to be ambig
- rename `trait_candidate_should_be_dropped_in_favor_of` to `candidate_should_be_dropped_in_favor_of`
- remove outdated fixme
For coherence I mostly just add an ambiguous candidate if the current trait ref is unknowable. I am doing the same for reservation impl where I also just add an ambiguous candidate.
Use region-erased self type during IAT selection
Split off from #109410 as discussed.
Fixes#109299.
Re UI test: I use a reproducer of #109299 that contains a name resolution error instead of reproducer [`regionck-2.rs`](fc7ed4af16/tests/ui/associated-inherent-types/regionck-2.rs) (as found in the `AliasKind::Inherent` PR) since it would (incorrectly) pass typeck in this PR due to the lack of regionck and I'd rather not make *that* a regression test (with or without `known-bug`).
``@rustbot`` label F-inherent_associated_types
r? ``@compiler-errors``
Detect uninhabited types early in const eval
r? `@RalfJung`
implements https://github.com/rust-lang/rust/pull/108442#discussion_r1143003840
this is a breaking change, as some UB during const eval is now detected instead of silently being ignored. Users can see this and other UB that may cause future breakage with `-Zextra-const-ub-checks` or just by running miri on their code, which sets that flag by default.
Do not consider synthesized RPITITs on missing items checks
Without this patch for `tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs` we get ...
```
warning: the feature `return_position_impl_trait_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs:4:12
|
4 | #![feature(return_position_impl_trait_in_trait)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error[E0046]: not all trait items implemented, missing: `foo`, ``
--> tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs:12:1
|
8 | fn foo(&self) -> impl Sized;
| ----------------------------
| | |
| | `` from trait
| `foo` from trait
...
12 | impl MyTrait for i32 {
| ^^^^^^^^^^^^^^^^^^^^ missing `foo`, `` in implementation
error: aborting due to previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0046`.
```
instead of ...
```
warning: the feature `return_position_impl_trait_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> $DIR/dont-project-to-rpitit-with-no-value.rs:4:12
|
LL | #![feature(return_position_impl_trait_in_trait)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error[E0046]: not all trait items implemented, missing: `foo`
--> $DIR/dont-project-to-rpitit-with-no-value.rs:12:1
|
LL | fn foo(&self) -> impl Sized;
| ---------------------------- `foo` from trait
...
LL | impl MyTrait for i32 {
| ^^^^^^^^^^^^^^^^^^^^ missing `foo` in implementation
error: aborting due to previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0046`.
```
r? `@compiler-errors`
a general type system cleanup
removes the helper functions `traits::fully_solve_X` as they add more complexity then they are worth. It's confusing which of these helpers should be used in which context.
changes the way we deal with overflow to always add depth in `evaluate_predicates_recursively`. It may make sense to actually fully transition to not have `recursion_depth` on obligations but that's probably a bit too much for this PR.
also removes some other small - and imo unnecessary - helpers.
r? types
Do not suggest bounds restrictions for synthesized RPITITs
Before this PR we were getting ...
```
warning: the feature `async_fn_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> tests/ui/async-await/in-trait/missing-send-bound.rs:5:12
|
5 | #![feature(async_fn_in_trait)]
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error: future cannot be sent between threads safely
--> tests/ui/async-await/in-trait/missing-send-bound.rs:17:20
|
17 | assert_is_send(test::<T>());
| ^^^^^^^^^^^ future returned by `test` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `impl Future<Output = ()>`
note: future is not `Send` as it awaits another future which is not `Send`
--> tests/ui/async-await/in-trait/missing-send-bound.rs:13:5
|
13 | T::bar().await;
| ^^^^^^^^ await occurs here on type `impl Future<Output = ()>`, which is not `Send`
note: required by a bound in `assert_is_send`
--> tests/ui/async-await/in-trait/missing-send-bound.rs:21:27
|
21 | fn assert_is_send(_: impl Send) {}
| ^^^^ required by this bound in `assert_is_send`
help: consider further restricting the associated type
|
16 | fn test2<T: Foo>() where impl Future<Output = ()>: Send {
| ++++++++++++++++++++++++++++++++++++
error: aborting due to previous error; 1 warning emitted
```
and we want this output ...
```
warning: the feature `async_fn_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> $DIR/missing-send-bound.rs:5:12
|
LL | #![feature(async_fn_in_trait)]
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error: future cannot be sent between threads safely
--> $DIR/missing-send-bound.rs:17:20
|
LL | assert_is_send(test::<T>());
| ^^^^^^^^^^^ future returned by `test` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `impl Future<Output = ()>`
note: future is not `Send` as it awaits another future which is not `Send`
--> $DIR/missing-send-bound.rs:13:5
|
LL | T::bar().await;
| ^^^^^^^^ await occurs here on type `impl Future<Output = ()>`, which is not `Send`
note: required by a bound in `assert_is_send`
--> $DIR/missing-send-bound.rs:21:27
|
LL | fn assert_is_send(_: impl Send) {}
| ^^^^ required by this bound in `assert_is_send`
error: aborting due to previous error; 1 warning emitted
```
r? `@compiler-errors`
Only implement Fn* traits for extern "Rust" safe function pointers and items
Since calling the function via an `Fn` trait will assume `extern "Rust"` ABI and not do any safety checks, only safe `extern "Rust"` function can implement the `Fn` traits. This syncs the logic between the old solver and the new solver.
r? `@compiler-errors`
Constrain const vars to error if const types are mismatched
When equating two consts of different types, if either are const variables, constrain them to the correct const error kind.
This helps us avoid "successfully" matching a const against an impl signature but leaving unconstrained const vars, which will lead to incremental ICEs when we call const-eval queries during const projection.
Fixes#109296
The second commit in the stack fixes a regression in the first commit where we end up mentioning `[const error]` in an impl overlap error message. I think the error message changes for the better, but I could implement alternative strategies to avoid this without delaying the overlap error message...
r? `@BoxyUwU`
