jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

Related discussion:
text: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71382.rs:15:23 | LL |     fn test<const FN: fn()>(&self) { |                       ^^^^ error: aborting due to previous error </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

Related discussion:
text: <ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

Related discussion:
text: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-71611.rs:4:21 | LL | fn func<A, const F: fn(inner: A)>(outer: A) { |                     ^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

Related discussion:
text: <ins> #![feature(const_generics)] #![allow(incomplete_features)] use std::ffi::{CStr, CString}; unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { //~^ ERROR: using function pointers as const generic parameters is forbidden F(CStr::from_ptr(ptr)) } fn safely_do_the_thing(s: &CStr) -> usize { s.to_bytes().len() } fn main() { let baguette = CString::new("baguette").unwrap(); let ptr = baguette.as_ptr(); println!("{}", unsafe { unsafely_do_the_thing::<safely_do_the_thing>(ptr) }); } </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":

Related discussion:
text: <ins> error: using function pointers as const generic parameters is forbidden --> $DIR/issue-72352.rs:6:42 | LL | unsafe fn unsafely_do_the_thing<const F: fn(&CStr) -> usize>(ptr: *const i8) -> usize { |                                          ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.

Related discussion:
text: }; } <del> let binding = if let Some(module) = module { self.resolve_ident_in_module( module, ident, ns, parent_scope, record_used, path_span, ) } else if ribs.is_none() || opt_ns.is_none() || opt_ns == Some(MacroNS) { let scopes = ScopeSet::All(ns, opt_ns.is_none()); self.early_resolve_ident_in_lexical_scope( ident, scopes, parent_scope, record_used, record_used, path_span, ) } else { let record_used_id = if record_used { crate_lint.node_id().or(Some(CRATE_NODE_ID)) } else { None }; match self.resolve_ident_in_lexical_scope( ident, ns, parent_scope, record_used_id, path_span, &ribs.unwrap()[ns], ) { // we found a locally-imported or available item/module Some(LexicalScopeBinding::Item(binding)) => Ok(binding), // we found a local variable or type param Some(LexicalScopeBinding::Res(res)) if opt_ns == Some(TypeNS) || opt_ns == Some(ValueNS) => { record_segment_res(self, res); return PathResult::NonModule(PartialRes::with_unresolved_segments( res, path.len() - 1, )); </del> <ins> enum FindBindingResult<'a> { Binding(Result<&'a NameBinding<'a>, Determinacy>), PathResult(PathResult<'a>), } let find_binding_in_ns = |this: &mut Self, ns| { let binding = if let Some(module) = module { this.resolve_ident_in_module( module, ident, ns, parent_scope, record_used, path_span, ) } else if ribs.is_none() || opt_ns.is_none() || opt_ns == Some(MacroNS) { let scopes = ScopeSet::All(ns, opt_ns.is_none()); this.early_resolve_ident_in_lexical_scope( ident, scopes, parent_scope, record_used, record_used, path_span, ) } else { let record_used_id = if record_used { crate_lint.node_id().or(Some(CRATE_NODE_ID)) } else { None }; match this.resolve_ident_in_lexical_scope( ident, ns, parent_scope, record_used_id, path_span, &ribs.unwrap()[ns], ) { // we found a locally-imported or available item/module Some(LexicalScopeBinding::Item(binding)) => Ok(binding), // we found a local variable or type param Some(LexicalScopeBinding::Res(res)) if opt_ns == Some(TypeNS) || opt_ns == Some(ValueNS) => { record_segment_res(this, res); return FindBindingResult::PathResult(PathResult::NonModule( PartialRes::with_unresolved_segments(res, path.len() - 1), )); } _ => Err(Determinacy::determined(record_used)), </ins> } <del> _ => Err(Determinacy::determined(record_used)), } </del> <ins> }; FindBindingResult::Binding(binding) }; let binding = match find_binding_in_ns(self, ns) { FindBindingResult::PathResult(x) => return x, FindBindingResult::Binding(binding) => binding, </ins> }; match binding { Ok(binding) => { if i == 1 {
Code change:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.

Related discussion:
text: } else if i == 0 { (format!("use of undeclared type or module `{}`", ident), None) } else { <del> (format!("could not find `{}` in `{}`", ident, path[i - 1].ident), None) </del> <ins> let mut msg = format!("could not find `{}` in `{}`", ident, path[i - 1].ident); if ns == TypeNS || ns == ValueNS { let ns_to_try = if ns == TypeNS { ValueNS } else { TypeNS }; if let FindBindingResult::Binding(Ok(binding)) = find_binding_in_ns(self, ns_to_try) { let mut found = |what| { msg = format!( "expected {}, found {} `{}` in `{}`", ns.descr(), what, ident, path[i - 1].ident ) }; if binding.module().is_some() { found("module") } else { match binding.res() { def::Res::<NodeId>::Def(kind, id) => found(kind.descr(id)), _ => found(ns_to_try.descr()), } } }; } (msg, None) </ins> }; return PathResult::Failed { span: ident.span,
Code change:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.

Related discussion:
text: <ins> use std::sync::mpsc; fn main() { let (tx, rx) = mpsc::channel::new(1); //~^ ERROR expected type, found function `channel` in `mpsc` } </ins>
Code change:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.

Related discussion:
text: <ins> error[E0433]: failed to resolve: expected type, found function `channel` in `mpsc` --> $DIR/issue-71406.rs:4:26 | LL |     let (tx, rx) = mpsc::channel::new(1); |                          ^^^^^^^ expected type, found function `channel` in `mpsc` error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>
Code change:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

Related discussion:
text: &b.item_def_id, ))) } else { <del> let ty = relation.relate(&a.ty, &b.ty)?; let substs = relation.relate(&a.substs, &b.substs)?; </del> <ins> let ty = relation.relate_with_variance(ty::Invariant, &a.ty, &b.ty)?; let substs = relation.relate_with_variance(ty::Invariant, &a.substs, &b.substs)?; </ins> Ok(ty::ExistentialProjection { item_def_id: a.item_def_id, substs, ty }) } }
Code change:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

Related discussion:
text: LL |     let _ = Box::new(|x| (x as u8)): Box<dyn Fn(i32) -> _>; |             ^^^^^^^^^^^^^^^^^^^^^^^ expected trait object `dyn std::ops::Fn`, found closure | <del> = note: expected struct `std::boxed::Box<dyn std::ops::Fn(i32) -> _>` </del> <ins> = note: expected struct `std::boxed::Box<dyn std::ops::Fn(i32) -> u8>` </ins> found struct `std::boxed::Box<[closure@$DIR/coerce-expect-unsized-ascribed.rs:26:22: 26:35]>` error: aborting due to 14 previous errors
Code change:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

Related discussion:
text: <del> error[E0277]: the size for values of type `dyn std::iter::Iterator<Item = &mut u8>` cannot be known at compilation time </del> <ins> error[E0277]: the size for values of type `dyn std::iter::Iterator<Item = &'a mut u8>` cannot be known at compilation time </ins> --> $DIR/issue-20605.rs:2:17 | LL |     for item in *things { *item = 0 } |                 ^^^^^^^ doesn't have a size known at compile-time | <del> = help: the trait `std::marker::Sized` is not implemented for `dyn std::iter::Iterator<Item = &mut u8>` </del> <ins> = help: the trait `std::marker::Sized` is not implemented for `dyn std::iter::Iterator<Item = &'a mut u8>` </ins> = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait> = note: required by `std::iter::IntoIterator::into_iter`
Code change:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).

Related discussion:
text: <ins> error: lifetime may not live long enough --> $DIR/variance-associated-types2.rs:13:12 | LL | fn take<'a>(_: &'a u32) { |         -- lifetime `'a` defined here LL |     let _: Box<dyn Foo<Bar = &'a u32>> = make(); |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^ type annotation requires that `'a` must outlive `'static` | = help: consider replacing `'a` with `'static` error: aborting due to previous error </ins>