jiebi/CodeConvo huggingface dataset:
Code change:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

Related discussion:
text: self.substitutions .iter() <ins> .filter(|subst| { // Suggestions coming from macros can have malformed spans. This is a heavy // handed approach to avoid ICEs by ignoring the suggestion outright. let invalid = subst.parts.iter().any(|item| cm.is_valid_span(item.span).is_err()); if invalid { debug!("splice_lines: suggestion contains an invalid span: {:?}", subst); } !invalid }) </ins> .cloned() .map(|mut substitution| { // Assumption: all spans are in the same file, and all spans
Code change:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

Related discussion:
text: lo.line != hi.line } <del> pub fn span_to_lines(&self, sp: Span) -> FileLinesResult { debug!("span_to_lines(sp={:?})", sp); </del> <ins> pub fn is_valid_span(&self, sp: Span) -> Result<(Loc, Loc), SpanLinesError> { </ins> let lo = self.lookup_char_pos(sp.lo()); debug!("span_to_lines: lo={:?}", lo); let hi = self.lookup_char_pos(sp.hi()); debug!("span_to_lines: hi={:?}", hi); if lo.file.start_pos != hi.file.start_pos { return Err(SpanLinesError::DistinctSources(DistinctSources { begin: (lo.file.name.clone(), lo.file.start_pos), end: (hi.file.name.clone(), hi.file.start_pos), })); } <ins> Ok((lo, hi)) } pub fn span_to_lines(&self, sp: Span) -> FileLinesResult { debug!("span_to_lines(sp={:?})", sp); let (lo, hi) = self.is_valid_span(sp)?; </ins> assert!(hi.line >= lo.line); let mut lines = Vec::with_capacity(hi.line - lo.line + 1);
Code change:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.

Related discussion:
text: LL | const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:346:17 </del> <ins> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:356:17 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic
Code change:
Creating a stack closure which references an owned pointer and then transferring ownership of the owned box before invoking the stack closure results in a crash. For example, in Rust 0.6, this will compile and the resulting program will then crash with a SEGV
Does it still crash on the branch?
It dumps core for me, on incoming: Adding an xfailed test. We want this to fail compilation, I guess.
This bug could be fixed by the proposed solution in this post: (namely, bullet 1, not 2)
Dup of and more specifically .

Related discussion:
text: <ins> //xfail-test // Creating a stack closure which references an owned pointer and then // transferring ownership of the owned box before invoking the stack // closure results in a crash. fn twice(x: ~uint) -> uint { *x * 2 } fn invoke(f : &fn() -> uint) { f(); } fn main() { let x  : ~uint         = ~9; let sq : &fn() -> uint = || { *x * *x }; twice(x); invoke(sq); } </ins>  No newline at end of file
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: if self.regioncx.universal_regions().is_universal_region(r) { Some(r) } else { <del> let upper_bound = self.regioncx.universal_upper_bound(r); </del> <ins> // We just want something nameable, even if it's not // actually an upper bound. let upper_bound = self.regioncx.approx_universal_upper_bound(r); </ins> if self.regioncx.upper_bound_in_region_scc(r, upper_bound) { self.to_error_region_vid(upper_bound)
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: lub } <ins> /// Like `universal_upper_bound`, but returns an approximation more suitable /// for diagnostics. If `r` contains multiple disjoint universal regions /// (e.g. 'a and 'b in `fn foo<'a, 'b> { ... }`, we pick the lower-numbered region. /// This corresponds to picking named regions over unnamed regions /// (e.g. picking early-bound regions over a closure late-bound region). /// /// This means that the returned value may not be a true upper bound, since /// only 'static is known to outlive disjoint universal regions. /// Therefore, this method should only be used in diagnostic code, /// where displaying *some* named universal region is better than /// falling back to 'static. pub(in crate::borrow_check) fn approx_universal_upper_bound(&self, r: RegionVid) -> RegionVid { debug!("approx_universal_upper_bound(r={:?}={})", r, self.region_value_str(r)); // Find the smallest universal region that contains all other // universal regions within `region`. let mut lub = self.universal_regions.fr_fn_body; let r_scc = self.constraint_sccs.scc(r); let static_r = self.universal_regions.fr_static; for ur in self.scc_values.universal_regions_outlived_by(r_scc) { let new_lub = self.universal_region_relations.postdom_upper_bound(lub, ur); debug!("approx_universal_upper_bound: ur={:?} lub={:?} new_lub={:?}", ur, lub, new_lub); if ur != static_r && lub != static_r && new_lub == static_r { lub = std::cmp::min(ur, lub); } else { lub = new_lub; } } debug!("approx_universal_upper_bound: r={:?} lub={:?}", r, lub); lub } </ins> /// Tests if `test` is true when applied to `lower_bound` at /// `point`. fn eval_verify_bound(
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: { tcx.fold_regions(&ty, &mut false, |region, _| match *region { ty::ReVar(vid) => { <del> let upper_bound = self.universal_upper_bound(vid); </del> <ins> // Find something that we can name let upper_bound = self.approx_universal_upper_bound(vid); </ins> self.definitions[upper_bound].external_name.unwrap_or(region) } _ => region,
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: <ins> // edition:2018 // // Regression test for issue #67765 // Tests that we point at the proper location when giving // a lifetime error. fn main() {} async fn func<'a>() -> Result<(), &'a str> { let s = String::new(); let b = &s[..]; Err(b)?; //~ ERROR cannot return value referencing local variable `s` Ok(()) } </ins>
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: <ins> error[E0515]: cannot return value referencing local variable `s` --> $DIR/issue-67765-async-diagnostic.rs:13:11 | LL |     let b = &s[..]; |              - `s` is borrowed here LL | LL |     Err(b)?; |           ^ returns a value referencing data owned by the current function error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </ins>
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: fn main() { <del> [0].iter().flat_map(|a| [0].iter().map(|_| &a)); //~ ERROR `a` does not live long enough </del> <ins> [0].iter().flat_map(|a| [0].iter().map(|_| &a)); //~ ERROR closure may outlive </ins> }
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: <del> error[E0597]: `a` does not live long enough --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:49 </del> <ins> error[E0373]: closure may outlive the current function, but it borrows `a`, which is owned by the current function --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:44 </ins> | LL |     [0].iter().flat_map(|a| [0].iter().map(|_| &a)); <del> |                                             -   ^- ...but `a` will be dropped here, when the enclosing closure returns |                                             |   | |                                             |   `a` would have to be valid for `'_`... |                                             has type `&i32` </del> <ins> |                                            ^^^  - `a` is borrowed here |                                            | |                                            may outlive borrowed value `a` </ins> | <del> = note: functions cannot return a borrow to data owned within the function's scope, functions can only return borrows to data passed as arguments = note: to learn more, visit <https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html#dangling-references> </del> <ins> note: closure is returned here --> $DIR/unnamed-closure-doesnt-life-long-enough-issue-67634.rs:2:29 | LL |     [0].iter().flat_map(|a| [0].iter().map(|_| &a)); |                             ^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables), use the `move` keyword | LL |     [0].iter().flat_map(|a| [0].iter().map(move |_| &a)); |                                            ^^^^^^^^ </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0597`. </del> <ins> For more information about this error, try `rustc --explain E0373`. </ins>
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: <ins> // See https://github.com/rust-lang/rust/pull/67911#issuecomment-576023915 fn f<'a, 'b>(x: i32) -> (&'a i32, &'b i32) { let y = &x; (y, y) //~ ERROR cannot return } fn main() {} </ins>
Code change:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.

Related discussion:
text: <ins> error[E0515]: cannot return value referencing function parameter `x` --> $DIR/return-disjoint-regions.rs:4:5 | LL |     let y = &x; |             -- `x` is borrowed here LL |     (y, y) |     ^^^^^^ returns a value referencing data owned by the current function error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </ins>
Code change:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

Related discussion:
text: use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_middle::{ hir::place::PlaceBase, <del> mir::{self, ClearCrossCrate, Local, LocalDecl, LocalInfo, Location}, </del> <ins> mir::{self, ClearCrossCrate, Local, LocalDecl, LocalInfo, LocalKind, Location}, </ins> }; use rustc_span::source_map::DesugaringKind; use rustc_span::symbol::{kw, Symbol};
Code change:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

Related discussion:
text: match label { Some((true, err_help_span, suggested_code)) => { <del> err.span_suggestion( err_help_span, &format!( "consider changing this to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); </del> <ins> let (is_trait_sig, local_trait) = self.is_error_in_trait(local); if !is_trait_sig { err.span_suggestion( err_help_span, &format!( "consider changing this to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); } else if let Some(x) = local_trait { err.span_suggestion( x, &format!( "consider changing that to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); } </ins> } Some((false, err_label_span, message)) => { err.span_label(err_label_span, &message);
Code change:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

Related discussion:
text: err.buffer(&mut self.errors_buffer); } <ins> /// User cannot make signature of a trait mutable without changing the /// trait. So we find if this error belongs to a trait and if so we move /// suggestion to the trait or disable it if it is out of scope of this crate fn is_error_in_trait(&self, local: Local) -> (bool, Option<Span>) { if self.body.local_kind(local) != LocalKind::Arg { return (false, None); } let hir_map = self.infcx.tcx.hir(); let my_def = self.body.source.def_id(); let my_hir = hir_map.local_def_id_to_hir_id(my_def.as_local().unwrap()); let td = if let Some(a) = self.infcx.tcx.impl_of_method(my_def).and_then(|x| self.infcx.tcx.trait_id_of_impl(x)) { a } else { return (false, None); }; ( true, td.as_local().and_then(|tld| { let h = hir_map.local_def_id_to_hir_id(tld); match hir_map.find(h) { Some(Node::Item(hir::Item { kind: hir::ItemKind::Trait(_, _, _, _, items), .. })) => { let mut f_in_trait_opt = None; for hir::TraitItemRef { id: fi, kind: k, .. } in *items { let hi = fi.hir_id(); if !matches!(k, hir::AssocItemKind::Fn { .. }) { continue; } if hir_map.name(hi) != hir_map.name(my_hir) { continue; } f_in_trait_opt = Some(hi); break; } f_in_trait_opt.and_then(|f_in_trait| match hir_map.find(f_in_trait) { Some(Node::TraitItem(hir::TraitItem { kind: hir::TraitItemKind::Fn( hir::FnSig { decl: hir::FnDecl { inputs, .. }, .. }, _, ), .. })) => { let hir::Ty { span, .. } = inputs[local.index() - 1]; Some(span) } _ => None, }) } _ => None, } }), ) } </ins> // point to span of upvar making closure call require mutable borrow fn show_mutating_upvar( &self,
Code change:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

Related discussion:
text: <ins> use std::alloc::{GlobalAlloc, Layout}; struct Test(u32); unsafe impl GlobalAlloc for Test { unsafe fn alloc(&self, _layout: Layout) -> *mut u8 { self.0 += 1; //~ ERROR cannot assign 0 as *mut u8 } unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) { unimplemented!(); } } fn main() { } </ins>
Code change:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

Related discussion:
text: <ins> error[E0594]: cannot assign to `self.0` which is behind a `&` reference --> $DIR/issue-68049-1.rs:7:9 | LL |         self.0 += 1; |         ^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>
Code change:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///

Related discussion:
text: <ins> trait Hello { fn example(&self, input: &i32); // should suggest here } struct Test1(i32); impl Hello for Test1 { fn example(&self, input: &i32) { // should not suggest here *input = self.0; //~ ERROR cannot assign } } struct Test2(i32); impl Hello for Test2 { fn example(&self, input: &i32) { // should not suggest here self.0 += *input; //~ ERROR cannot assign } } fn main() { } </ins>