-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Computing <MyStruct as std::ptr::Pointee>::Metadata
fails when trailing field has a projection
#92577
Comments
Same error message as #90738, though it's unclear whether that issue is related. |
Minimized: #![feature(ptr_metadata)]
trait HasType {
type Type;
}
impl HasType for () {
type Type = ();
}
pub struct MyStruct {
_field: <() as HasType>::Type,
}
pub fn bar() {
let val: <MyStruct as std::ptr::Pointee>::Metadata;
} The rust/library/core/src/hash/mod.rs Lines 791 to 799 in 181e915
The issue is caused by how we handle projections when computing the rust/compiler/rustc_trait_selection/src/traits/project.rs Lines 1403 to 1404 in 181e915
which causes us to not create a candidate for the projection type in the tail of rust/compiler/rustc_trait_selection/src/traits/project.rs Lines 1432 to 1438 in 181e915
cc @SimonSapin - we need to be normalizing somewhere, but I'm not exactly sure where the correct place is. |
I’m sorry but I don’t think I can help much. I don’t even know what normalizing means precisely. As I mentioned in #81172
So the only hint I can offer is: does the code for |
Option::unwrap()
on a None
value', compiler/rustc_monomorphize/src/collector.rs:894:93<MyStruct as std::ptr::Pointee>::Metadata
fails when trailing field has a projection
cc @rust-lang/wg-traits - I'm not quite sure what the proper normalization behavior is. We need to be able to perform this projection during typecheck (e.g. |
Why are we not normalizing? Because we don't want to replace with an inference var? |
@Aaron1011, so I put up a fix for this in #92248. Someone mind reviewing that PR? It's gone some time without being touched. My PR seems to successfully compile both examples linked in this issue.
Is it really not sufficient to just normalize during selection? Are there any consequences of normalization failing here, other than giving us errors the regular ambiguity "type annotation needed" errors? |
…pointee, r=jackh726 Normalize struct tail type when checking Pointee trait Let's go ahead and implement the FIXMEs by properly normalizing the struct-tail type when satisfying a Pointee obligation. This should fix the ICE when we try to calculate a layout depending on `<Ty as Pointee>::Metadata` later. Fixes rust-lang#92128 Fixes rust-lang#92577 Additionally, mark the obligation as ambiguous if there are any infer types in that struct-tail type. This has the effect of causing `<_ as Pointee>::Metadata` to be properly replaced with an infer variable ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/traits/project.rs#L813)) and registered as an obligation... this turns out to be very important in unifying function parameters with formals that are assoc types. Fixes rust-lang#91446
Code
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8e31db4a857f6bcdbf287b8d9745ca22
Meta
(Build fails with an ICE on current stable/beta/nightly on the playground.)
Error output
Backtrace
The text was updated successfully, but these errors were encountered: