-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
ICE on "computing whether GenFuture<_> is Copy
"
#95034
Comments
Copy
"Copy
"
@rustbot claim |
Wow this ICE is super weird. I believe it has to do something with the Generalizer in rustc_infer, the fact that generator interiors are represented with higher-kinded types, the fact that the Gonna keep working on it for a couple of hours, but I think it might be impossible to fix currently. Or at least it requires someone a lot smarter than me. |
Is this a thing in current rust? 🤯 Honestly, I was surprised that rustc accepts trait Tr<A> { type B; type C; }
struct S<A, B, T: Tr<A, B = B>>(<T as Tr<A>>::C); Does this pattern exist in practice? People would use PhantomData and this should avoid this problem (I hope). |
Yep, see https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_infer/infer/combine.rs.html#506-530. This wf trick just ends up not working for higher-kinded types due to strange caveats... |
Well, either a caveat or just a bug I cannot find. |
I honestly don't think I understand enough about variance and the Generalizer type relation to fix this issue. I think this would technically be solved by lazy projection normalization, since this is due to a inference variable created by normalizing a projection type. I will at least add a known-bug test for this. Sorry! @rustbot release-assignment |
@compiler-errors have you found the exact regressed commit? It would take ages on my potato pc to bisect through commits. And thanks again for your efforts. Very much appreciated. |
I am pretty certain this is due to #85499 |
Uh this is complicated. Just trying to reduce the MCVE a bit. Here are some failed attempts:
However, I did manage to get a more reduced version: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=12b8530b4dc298dcf302f955d82fc0f1 That being said, there is a lot here that has to go perfectly (wrong).
I suspect that this hints at the root of the problem here. We should not be assigning bivariant to parameters (this happens when rustc "gives up" - and should error out, sooner than where we are getting the ice probably). It's also a bit interesting though that the call through I think this is probably just |
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-medium |
I was able to minimize it further so that I hope the new ICE provides further insight. pub trait Object<'a> { // <- can't remove `'a`
type Error; // <- can't remove because then `E`s are no longer constrained below
type Future;
}
impl Object<'static> for u8 {
type Error = ();
type Future = ();
}
impl<'a, E, A: Object<'a, Error = E>> Object<'a> for (A,) {
type Error = ();
type Future = CustomFut<'a, E, A>; // <- Replacing `E` with `A::Error` compiles
}
pub struct CustomFut<'a, E, A: Object<'a, Error = E>> {
ph: std::marker::PhantomData<(A::Future,)>, // <- adding `E` to the tuple compiles
}
pub trait AsyncFn {
fn call_async(&self);
}
impl<F: Fn() -> Fut, Fut> AsyncFn for F {
fn call_async(&self) {}
}
async fn create<T: Object<'static>>() {
let _fut: T::Future = unimplemented!();
std::future::ready(()).await; // <- any await point should work
}
pub fn test() {
let _ = create::<(u8,)>.call_async(); // <- .call_async() is important (can't remove or replace with `(...)()`; so is `(u8,)` (`u8` doesn't work)
} Error outputOutput with backtrace
|
Yes, I saw that error in one of my repros above. This is smaller though. |
@rustbot label +AsyncAwait-Triaged |
…jackh726 Add known-bug for rust-lang#95034 Couldn't fix the issue, since I am no type theorist and inference variables in universes above U0 scare me. But I at least wanted to add a known-bug test for it. cc rust-lang#95034 (does not fix)
…jackh726 Add known-bug for rust-lang#95034 Couldn't fix the issue, since I am no type theorist and inference variables in universes above U0 scare me. But I at least wanted to add a known-bug test for it. cc rust-lang#95034 (does not fix)
…jackh726 Add known-bug for rust-lang#95034 Couldn't fix the issue, since I am no type theorist and inference variables in universes above U0 scare me. But I at least wanted to add a known-bug test for it. cc rust-lang#95034 (does not fix)
Rollup of 7 pull requests Successful merges: - rust-lang#95102 (Add known-bug for rust-lang#95034) - rust-lang#95579 (Add `<[[T; N]]>::flatten{_mut}`) - rust-lang#95634 (Mailmap update) - rust-lang#95705 (Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts) - rust-lang#95761 (Kickstart the inner usage of `macro_metavar_expr`) - rust-lang#95782 (Windows: Increase a pipe's buffer capacity to 64kb) - rust-lang#95791 (hide an #[allow] directive from the Arc::new_cyclic doc example) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Fixed by #100980 |
Code
Compiled with the command
rustc --edition 2021 --crate-type lib repro.rs
. Surprisingly, It is not reproducible with--crate-type bin
!With any of the following changes, the code compiles fine:
or
Meta
The code compiles fine on v1.55.0. It was reproduced on v1.56.0 up to the current nightly with a similar error output.
Last good nightly:
1.56.0-nightly (b03ccace5 2021-08-24)
Regressed nightly:
1.56.0-nightly (0afc20860 2021-08-25)
rustc --version --verbose
:Error output
Output with backtrace
@rustbot label A-async-await A-generators regression-from-stable-to-stable
The text was updated successfully, but these errors were encountered: