Existential type ICE #52985
Comments
oli-obk
added
A-impl-trait
|
It should be enough to turn the panic into a So in https://github.com/rust-lang/rust/blob/master/src/librustc/traits/query/normalize.rs#L124 try the following things in the given order:
|
oli-obk
added
the
E-mentor
|
I would like to take this if no one else is working on it. Just to make sure I understand so far:
Does that sound right? I'm going to spend some time as well to better understand this, because I have no idea yet what |
|
Ignore the other snippets, those are doing the right thing. The issue is that main needs the existential type
|
|
Using just option 2, we get the following, which appears to line up with rust/src/librustc/middle/intrinsicck.rs Line 110 in 7bbcd00 ./dev/code/rust$ rustc +stage1 ./dev/tests/data/rust_52895_ice.rs
error[E0512]: transmute called with types of different sizes
--> ./dev/tests/data/rust_52895_ice.rs:11:27
|
11 | let _: Foo = unsafe { std::mem::transmute(0u8) };
| ^^^^^^^^^^^^^^^^^^^
|
= note: source type: u8 (8 bits)
= note: target type: Foo (this type's size can vary)
error: aborting due to previous error
For more information about this error, try `rustc --explain E0512`.I think this is ok. Works as well if you go full bore with transmuting Foo to Foo without resolving Foo's concrete size (see below), and (to me) tells me that Foo's size can't be resolved to something concrete. I will begin creating regression test cases. Please let me know if this doesn't seem like the right error, or if there's anything else I should take into account. #![feature(existential_type)]
existential type Foo: Copy;
// make compiler happy about using 'Foo'
fn bar(x: Foo) -> Foo { x }
fn main() {
let x: Foo;
let _: Foo = unsafe { std::mem::transmute(x) };
}which results in the below. ./dev/code/rust$ rustc +stage1 ./dev/tests/data/rust_52895_confusing_mismatch.rs
error[E0512]: transmute called with types of different sizes
--> ./dev/tests/data/rust_52895_confusing_mismatch.rs:10:27
|
10 | let _: Foo = unsafe { std::mem::transmute(x) };
| ^^^^^^^^^^^^^^^^^^^
|
= note: source type: Foo (this type's size can vary)
= note: target type: Foo (this type's size can vary)
error: aborting due to previous error
For more information about this error, try `rustc --explain E0512`. |
|
The error message is pretty good indeed. Although I fear out of the wrong reasons XD. I think this is what happens when one tries to transmute an unsized type. One small thing that you could try is to return Ideally the error would point to the function at some point. What happens in your current version if you minimize the test to #![feature(existential_type)]
existential type Foo: Copy;
// make compiler happy about using 'Foo'
fn bar(x: Foo) -> Foo { x }
fn main() {
let x = bar(unimplemented!());
} |
|
Returning The test reduction snippet suggested above produces the following: |
|
Thanks for trying it out. the So one further thing to try is the To improve the span with the resulting query error, you can look for calls to In case we are not actually seeing a good diagnostic, just going for a cycle error seems fine. We can then leave the issue open for further investigation into improving the span. |
|
The only span around calls to For now, I've gotten the cycle error in place and accompanied by the span corresponding to the existential type def just so that it's pointing the user at something relevant instead of nothing, captured in the PR detailed above. |
…li-obk 52985: cause cycle err on inf trait normalization Issue: #52985 - If an existential type is defined, but no user code infers the concrete type behind the existential type, normalization would infinitely recurse on this existential type which is only defined in terms of itself. - Instead of raising an inf recurse error, we cause a cycle error to help highlight that the issue is that the type is only defined in terms of itself. - Three known potential improvements: - If type folding itself was exposed as a query, used by normalization and other mechanisms, cases that would cause infinite recursion would automatically cause a cycle error. - The span for the cycle error should be improved to point to user code that fails to allow inference of the concrete type of the existential type, assuming that this error occurs because no user code can allow inference the concrete type. - A mechanism to extend the cycle error with a helpful note would be nice. Currently, the error is built and maintained by src/librustc/ty/query/plumbing, with no known way to extend the information that the error gets built with. r? @oli-obk
|
Leaving open per discussion starting at #53316 (comment); need to investigate error handling at an earlier time than the transmute, since before transmute is even scanned we should be able to tell that the existential type does not have an underlying concrete type defined. |
|
Forgot to put closes issue in the commit message, and I don't think I can close this myself. Per the above PR, this issue can be closed. |
The ICE message is almost the same as #52701 , yet the code is verrry different:
Backtrace:
Unrelated data:
changing
fn barto the following compiles just fine:however, when removing the
u8here, we get a compile error:The text was updated successfully, but these errors were encountered: