jiebi/CodeConvo huggingface dataset:
Code change:
() Output: Version: 1.34.0 1.35.0 2019-04-15 nightly () Expected: Original report:
26.0 is the first version that accepts this. 1.25.0 rejects it with:
(not really a regression since more code now compiles)
Adding T-compiler since is a built-in.
Opened —it should fix the issue.
triage: P-medium. I'm going to assume we don't need any future-compat machinery for a bug of this nature, unless the crater run on PR indicates that there are occurrences of this mis-use of in the wild.

Related discussion:
text: <ins> error: expected one of `,`, `.`, `?`, or an operator, found `some` --> $DIR/assert-trailing-junk.rs:6:18 | LL |     assert!(true some extra junk, "whatever"); |                  ^^^^ expected one of `,`, `.`, `?`, or an operator here error: expected one of `,`, `.`, `?`, or an operator, found `some` --> $DIR/assert-trailing-junk.rs:9:18 | LL |     assert!(true some extra junk); |                  ^^^^ expected one of `,`, `.`, `?`, or an operator here error: no rules expected the token `blah` --> $DIR/assert-trailing-junk.rs:12:30 | LL |     assert!(true, "whatever" blah); |                             -^^^^ no rules expected this token in macro call |                             | |                             help: missing comma here warning: unexpected string literal --> $DIR/assert-trailing-junk.rs:15:18 | LL |     assert!(true "whatever" blah); |                 -^^^^^^^^^^ |                 | |                 help: try adding a comma | = note: this is going to be an error in the future error: no rules expected the token `blah` --> $DIR/assert-trailing-junk.rs:15:29 | LL |     assert!(true "whatever" blah); |                            -^^^^ no rules expected this token in macro call |                            | |                            help: missing comma here warning: macro requires an expression as an argument --> $DIR/assert-trailing-junk.rs:19:5 | LL |     assert!(true;); |     ^^^^^^^^^^^^-^^ |                 | |                 help: try removing semicolon | = note: this is going to be an error in the future warning: unexpected string literal --> $DIR/assert-trailing-junk.rs:22:27 | LL |     assert!(false || true "error message"); |                          -^^^^^^^^^^^^^^^ |                          | |                          help: try adding a comma | = note: this is going to be an error in the future error: aborting due to 4 previous errors </ins>
Code change:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.

Related discussion:
text: let predicates_of = tcx.predicates_of(def_id); debug!("instantiate_opaque_types: predicates={:#?}", predicates_of,); let bounds = predicates_of.instantiate(tcx, substs); <ins> let param_env = tcx.param_env(def_id); let InferOk { value: bounds, obligations } = infcx.partially_normalize_associated_types_in(span, self.body_id, param_env, &bounds); self.obligations.extend(obligations); </ins> debug!("instantiate_opaque_types: bounds={:?}", bounds); let required_region_bounds = tcx.required_region_bounds(ty, bounds.predicates.clone());
Code change:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.

Related discussion:
text: &declared_ret_ty, decl.output.span(), ); <ins> debug!("check_fn: declared_ret_ty: {}, revealed_ret_ty: {}", declared_ret_ty, revealed_ret_ty); </ins> fcx.ret_coercion = Some(RefCell::new(CoerceMany::new(revealed_ret_ty))); fn_sig = fcx.tcx.mk_fn_sig( fn_sig.inputs().iter().cloned(),
Code change:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.

Related discussion:
text: <ins> // check-pass // edition:2018 #![feature(async_await)] // See issue 60414 trait Trait { type Assoc; } async fn foo<T: Trait<Assoc=()>>() -> T::Assoc { () } fn main() {} </ins>
Code change:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.

Related discussion:
text: <ins> // compile-fail // edition:2018 #![feature(async_await)] #![feature(existential_type)] #![feature(impl_trait_in_bindings)] //~^ WARNING the feature `impl_trait_in_bindings` is incomplete // See issue 60414 ///////////////////////////////////////////// // Reduction to `impl Trait` struct Foo<T>(T); trait FooLike { type Output; } impl<T> FooLike for Foo<T> { type Output = T; } mod impl_trait { use super::*; trait Trait { type Assoc; } /// `T::Assoc` can't be normalized any further here. fn foo_fail<T: Trait>() -> impl FooLike<Output=T::Assoc> { //~^ ERROR: type mismatch Foo(()) } } ///////////////////////////////////////////// // Same with lifetimes in the trait mod lifetimes { use super::*; trait Trait<'a> { type Assoc; } /// Missing bound constraining `Assoc`, `T::Assoc` can't be normalized further. fn foo2_fail<'a, T: Trait<'a>>() -> impl FooLike<Output=T::Assoc> { //~^ ERROR: type mismatch Foo(()) } } fn main() {} </ins>
Code change:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.

Related discussion:
text: <ins> warning: the feature `impl_trait_in_bindings` is incomplete and may cause the compiler to crash --> $DIR/bound-normalization-pass.rs:6:12 | LL | #![feature(impl_trait_in_bindings)] |            ^^^^^^^^^^^^^^^^^^^^^^ </ins>
Code change:
I was using nightly rust extensively for its async/await and specialization feature. After a recent update (nightly-2019-05-02), a new ICE introduced with following logs: After a quick search it seems like is the only in direct cause (stack frame 10). ~I cannot share the code or produce a minimal case because the code base is rather big.~
I've the minimal case for reproducing. Hope that would help!
Thanks! Looks like even this line is enough to trigger the ICE:
: rustc complains you should have variable mut although it is already mut.
That's and should be fixed in the next nightly
cc it looks like the desugaring may have broken in argument-position?
Oops, sorry. I'll take a look.
Denominating since already has a fix
Thanks guys! This is a super fast fix!

Related discussion:
text: visit::walk_generics(this, generics); // Walk the generated arguments for the `async fn`. <del> for a in arguments { </del> <ins> for (i, a) in arguments.iter().enumerate() { </ins> use visit::Visitor; if let Some(arg) = &a.arg { this.visit_ty(&arg.ty); <ins> } else { this.visit_ty(&decl.inputs[i].ty); </ins> } }
Code change:
I was using nightly rust extensively for its async/await and specialization feature. After a recent update (nightly-2019-05-02), a new ICE introduced with following logs: After a quick search it seems like is the only in direct cause (stack frame 10). ~I cannot share the code or produce a minimal case because the code base is rather big.~
I've the minimal case for reproducing. Hope that would help!
Thanks! Looks like even this line is enough to trigger the ICE:
: rustc complains you should have variable mut although it is already mut.
That's and should be fixed in the next nightly
cc it looks like the desugaring may have broken in argument-position?
Oops, sorry. I'll take a look.
Denominating since already has a fix
Thanks guys! This is a super fast fix!

Related discussion:
text: <ins> // compile-pass // edition:2018 #![feature(async_await)] // This is a regression test to ensure that simple bindings (where replacement arguments aren't // created during async fn lowering) that have their DefId used during HIR lowering (such as impl // trait) are visited during def collection and thus have a DefId. async fn foo(ws: impl Iterator<Item = ()>) {} fn main() {} </ins>
Code change:
Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:

Related discussion:
text: if !fail { return None; } <del> bug!("unexpected const parent path def {:?}", x); </del> <ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent path def {:?}", x ), ); tcx.types.err </ins> } } }
Code change:
Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:

Related discussion:
text: if !fail { return None; } <del> bug!("unexpected const parent path {:?}", x); </del> <ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent path {:?}", x ), ); tcx.types.err </ins> } } }
Code change:
Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:

Related discussion:
text: if !fail { return None; } <del> bug!("unexpected const parent in type_of_def_id(): {:?}", x); </del> <ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent in type_of_def_id(): {:?}", x ), ); tcx.types.err </ins> } } }
Code change:
Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:

Related discussion:
text: <ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash // We should probably be able to infer the types here. However, this test is checking that we don't // get an ICE in this case. It may be modified later to not be an error. struct Foo<const NUM_BYTES: usize>(pub [u8; NUM_BYTES]); fn main() { let _ = Foo::<3>([1, 2, 3]); //~ ERROR type annotations needed } </ins>
Code change:
Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:

Related discussion:
text: <ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/cannot-infer-type-for-const-param.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ error[E0282]: type annotations needed --> $DIR/cannot-infer-type-for-const-param.rs:10:19 | LL |     let _ = Foo::<3>([1, 2, 3]); |                   ^ cannot infer type for `{integer}` error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>
Code change:
Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:

Related discussion:
text: <ins> use std::convert::TryInto; struct S; fn main() { let _: u32 = 5i32.try_into::<32>().unwrap(); //~ ERROR wrong number of const arguments S.f::<0>(); //~ ERROR no method named `f` S::<0>; //~ ERROR  wrong number of const arguments } </ins>
Code change:
Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:

Related discussion:
text: <ins> error[E0107]: wrong number of const arguments: expected 0, found 1 --> $DIR/invalid-const-arg-for-type-param.rs:6:34 | LL |     let _: u32 = 5i32.try_into::<32>().unwrap(); |                                  ^^ unexpected const argument error[E0599]: no method named `f` found for type `S` in the current scope --> $DIR/invalid-const-arg-for-type-param.rs:7:7 | LL | struct S; | --------- method `f` not found for this ... LL |     S.f::<0>(); |       ^ error[E0107]: wrong number of const arguments: expected 0, found 1 --> $DIR/invalid-const-arg-for-type-param.rs:8:9 | LL |     S::<0>; |         ^ unexpected const argument error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0599. For more information about an error, try `rustc --explain E0107`. </ins>