jiebi/CodeConvo huggingface dataset:
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> // Test that dyn Foo<Bar = T> is invariant with respect to T. // Failure to enforce invariance here can be weaponized, see #71550 for details. trait Foo { type Bar; } fn make() -> Box<dyn Foo<Bar = &'static u32>> { panic!() } fn take<'a>(_: &'a u32) { let _: Box<dyn Foo<Bar = &'a u32>> = make(); //~^ ERROR mismatched types [E0308] } fn main() {} </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: <ins> error[E0308]: mismatched types --> $DIR/variance-associated-types2.rs:13:42 | LL |     let _: Box<dyn Foo<Bar = &'a u32>> = make(); |                                          ^^^^^^ lifetime mismatch | = note: expected trait object `dyn Foo<Bar = &'a u32>` found trait object `dyn Foo<Bar = &'static u32>` note: the lifetime `'a` as defined on the function body at 12:9... --> $DIR/variance-associated-types2.rs:12:9 | LL | fn take<'a>(_: &'a u32) { |         ^^ = note: ...does not necessarily outlive the static lifetime error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
despite it being usable in . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hi there. Are you still working on this? :)
couldn't find the time to look into this deeper, sorry. Feel free to pick it up.
The target features for a particular architecture are taken from llvm in line 341. The seems to be a rust-specific target feature that is not present in llvm feature table, I think its the only one right now. I have made a basic naive pr which just prints it out since I'm hoping to get feedback for improving it

Related discussion:
text: printf("Available features for this target:n"); for (auto &Feature : FeatTable) printf("    %-*s - %s.n", MaxFeatLen, Feature.Key, Feature.Desc); <ins> printf("nRust-specific features:n"); printf("    %-*s - %s.n", MaxFeatLen, "crt-static", "Enables libraries with C Run-time Libraries(CRT) to be statically linked" ); </ins> printf("n"); printf("Use +feature to enable a feature, or -feature to disable it.n"
Code change:
The first impl block with a constant is not collapsible like the second impl block with a function. !
As far as I can tell, this is the desired behaviour (not to hide associated impl constant). So unless I'm missing something, there is nothing to fix here? cc
Why are they not hidden? It felt surprising to me, as they are part of the impl block. Also because if an impl block contains both constants and methods, both the constants and the methods are hidden when the impl block is collapsed (and this I expected).
For example  contains constants, and it is collapsible, with both the constants and the methods hidden on collapse.
It seems weird to me as well but I wasn't the one enforcing it and I don't remember the reason. Let's wait to hear from first.
It seems odd to me that they're not treated equivalently.

Related discussion:
text: if (!next) { return; } <del> if (next.getElementsByClassName("method").length > 0 && hasClass(e, "impl")) { </del> <ins> if (hasClass(e, "impl") && (next.getElementsByClassName("method").length > 0 || next.getElementsByClassName("associatedconstant").length > 0)) { </ins> insertAfter(toggle.cloneNode(true), e.childNodes[e.childNodes.length - 1]); } };
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. --Command: This code is from <!-- 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. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)

Related discussion:
text: use crate::middle::cstore::{ExternCrate, ExternCrateSource}; <del> use crate::mir::interpret::{sign_extend, truncate, AllocId, ConstValue, Pointer, Scalar}; </del> <ins> use crate::mir::interpret::{ sign_extend, truncate, AllocId, ConstValue, GlobalAlloc, Pointer, Scalar, }; </ins> use crate::ty::layout::IntegerExt; use crate::ty::subst::{GenericArg, GenericArgKind, Subst}; use crate::ty::{self, DefIdTree, ParamConst, Ty, TyCtxt, TypeFoldable};
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. --Command: This code is from <!-- 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. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)

Related discussion:
text: }, _, ), <del> ) => { let byte_str = self .tcx() .global_alloc(ptr.alloc_id) .unwrap_memory() .get_bytes(&self.tcx(), ptr, Size::from_bytes(*data)) .unwrap(); p!(pretty_print_byte_str(byte_str)); } </del> <ins> ) => match self.tcx().get_global_alloc(ptr.alloc_id) { Some(GlobalAlloc::Memory(alloc)) => { if let Ok(byte_str) = alloc.get_bytes(&self.tcx(), ptr, Size::from_bytes(*data)) { p!(pretty_print_byte_str(byte_str)) } else { p!(write("<too short allocation>")) } } // FIXME: for statics and functions, we could in principle print more detail. Some(GlobalAlloc::Static(def_id)) => p!(write("<static({:?})>", def_id)), Some(GlobalAlloc::Function(_)) => p!(write("<function>")), None => p!(write("<dangling pointer>")), }, </ins> // Bool (Scalar::Raw { data: 0, .. }, ty::Bool) => p!(write("false")), (Scalar::Raw { data: 1, .. }, ty::Bool) => p!(write("true")),
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. --Command: This code is from <!-- 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. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)

Related discussion:
text: )?; } (Scalar::Ptr(ptr), ty::FnPtr(_)) => { <ins> // FIXME: this can ICE when the ptr is dangling or points to a non-function. // We should probably have a helper method to share code with the "Byte strings" // printing above (which also has to handle pointers to all sorts of things). </ins> let instance = self.tcx().global_alloc(ptr.alloc_id).unwrap_fn(); self = self.typed_value( |this| this.print_value_path(instance.def_id(), instance.substs),
Code change:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".

Related discussion:
text: } debug!("note_type_err(diag={:?})", diag); <ins> enum Mismatch<'a> { Variable(ty::error::ExpectedFound<Ty<'a>>), Fixed(&'static str), } </ins> let (expected_found, exp_found, is_simple_error) = match values { <del> None => (None, None, false), </del> <ins> None => (None, Mismatch::Fixed("type"), false), </ins> Some(values) => { let (is_simple_error, exp_found) = match values { ValuePairs::Types(exp_found) => {
Code change:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".

Related discussion:
text: ) .report(diag); <del> (is_simple_err, Some(exp_found)) </del> <ins> (is_simple_err, Mismatch::Variable(exp_found)) </ins> } <del> _ => (false, None), </del> <ins> ValuePairs::TraitRefs(_) => (false, Mismatch::Fixed("trait")), _ => (false, Mismatch::Fixed("type")), </ins> }; let vals = match self.values_str(&values) { Some((expected, found)) => Some((expected, found)),
Code change:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".

Related discussion:
text: } }; if let Some((expected, found)) = expected_found { <del> let expected_label = exp_found.map_or("type".into(), |ef| ef.expected.prefix_string()); let found_label = exp_found.map_or("type".into(), |ef| ef.found.prefix_string()); </del> <ins> let expected_label = match exp_found { Mismatch::Variable(ef) => ef.expected.prefix_string(), Mismatch::Fixed(s) => s.into(), }; let found_label = match exp_found { Mismatch::Variable(ef) => ef.found.prefix_string(), Mismatch::Fixed(s) => s.into(), }; let exp_found = match exp_found { Mismatch::Variable(exp_found) => Some(exp_found), Mismatch::Fixed(_) => None, }; </ins> match (&terr, expected == found) { (TypeError::Sorts(values), extra) => { let sort_string = |ty: Ty<'tcx>| match (extra, &ty.kind) {
Code change:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".

Related discussion:
text: } } } <ins> let exp_found = match exp_found { Mismatch::Variable(exp_found) => Some(exp_found), Mismatch::Fixed(_) => None, }; </ins> if let Some(exp_found) = exp_found { self.suggest_as_ref_where_appropriate(span, &exp_found, diag); }
Code change:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".

Related discussion:
text: <ins> trait DynEq {} impl<'a> PartialEq for &'a (dyn DynEq + 'static) { fn eq(&self, _other: &Self) -> bool { true } } impl Eq for &dyn DynEq {} //~ ERROR E0308 fn main() { } </ins>
Code change:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/E0308-2.rs:9:6 | LL | impl Eq for &dyn DynEq {} |      ^^ lifetime mismatch | = note: expected trait `std::cmp::PartialEq` found trait `std::cmp::PartialEq` note: the lifetime `'_` as defined on the impl at 9:13... --> $DIR/E0308-2.rs:9:13 | LL | impl Eq for &dyn DynEq {} |             ^ = note: ...does not necessarily outlive the static lifetime error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
and all interfaces directly with the file-system should probably use rather than trying to coerce to handle these cases. (Similar issue to .)
nominating feature-complete
Accepted for backwards-compatible
My last referenced commit is a month old, but I'm still working on this issue (currently finishing up the support for Windows paths).
The issues here of dealing with filesystems that are not utf8 seem related to , at least tangentially.

Related discussion:
text: pub mod c_str; pub mod os; pub mod path; <ins> pub mod path2; </ins> pub mod rand; pub mod run; pub mod sys;
Code change:
When changing a pattern binding from something like to something like it's easy to end up with which yields an unhelpful syntax error message (). I don't believe it's obvious why and are valid, but is not. The same holds for bindings, of course. It would be nice if rustc's parser accepted the invalid syntax and provided one of its helpful "did you mean to write ?" error messages.
Current output:

Related discussion:
text: // check that a comma comes after every field if !ate_comma { <del> let err = ExpectedCommaAfterPatternField { span: self.token.span } </del> <ins> let mut err = ExpectedCommaAfterPatternField { span: self.token.span } </ins> .into_diagnostic(&self.sess.span_diagnostic); if let Some(mut delayed) = delayed_err { delayed.emit(); } <ins> self.recover_misplaced_pattern_modifiers(&fields, &mut err); </ins> return Err(err); } ate_comma = false;
Code change:
When changing a pattern binding from something like to something like it's easy to end up with which yields an unhelpful syntax error message (). I don't believe it's obvious why and are valid, but is not. The same holds for bindings, of course. It would be nice if rustc's parser accepted the invalid syntax and provided one of its helpful "did you mean to write ?" error messages.
Current output:

Related discussion:
text: Ok((fields, etc)) } <ins> /// If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest /// the correct code. fn recover_misplaced_pattern_modifiers( &self, fields: &ThinVec<PatField>, err: &mut DiagnosticBuilder<'a, ErrorGuaranteed>, ) { if let Some(last) = fields.iter().last() && last.is_shorthand && let PatKind::Ident(binding, ident, None) = last.pat.kind && binding != BindingAnnotation::NONE && self.token == token::Colon // We found `ref mut? ident:`, try to parse a `name,` or `name }`. && let Some(name_span) = self.look_ahead(1, |t| t.is_ident().then(|| t.span)) && self.look_ahead(2, |t| { t == &token::Comma || t == &token::CloseDelim(Delimiter::Brace) }) { let span = last.pat.span.with_hi(ident.span.lo()); // We have `S { ref field: name }` instead of `S { field: ref name }` err.multipart_suggestion( "the pattern modifiers belong after the `:`", vec![ (span, String::new()), (name_span.shrink_to_lo(), binding.prefix_str().to_string()), ], Applicability::MachineApplicable, ); } } </ins> /// Recover on `...` or `_` as if it were `..` to avoid further errors. /// See issue #46718. fn recover_bad_dot_dot(&self) {