jiebi/CodeConvo huggingface dataset:
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: <ins> // run-rustfix struct S { field_name: (), } fn main() { match (S {field_name: ()}) { S {field_name: ref _foo} => {} //~ ERROR expected `,` } match (S {field_name: ()}) { S {field_name: mut _foo} => {} //~ ERROR expected `,` } match (S {field_name: ()}) { S {field_name: ref mut _foo} => {} //~ ERROR expected `,` } // Verify that we recover enough to run typeck. let _: usize = 3usize; //~ ERROR mismatched types } </ins>
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: <ins> // run-rustfix struct S { field_name: (), } fn main() { match (S {field_name: ()}) { S {ref field_name: _foo} => {} //~ ERROR expected `,` } match (S {field_name: ()}) { S {mut field_name: _foo} => {} //~ ERROR expected `,` } match (S {field_name: ()}) { S {ref mut field_name: _foo} => {} //~ ERROR expected `,` } // Verify that we recover enough to run typeck. let _: usize = 3u8; //~ ERROR mismatched types } </ins>
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: <ins> error: expected `,` --> $DIR/incorrect-placement-of-pattern-modifiers.rs:8:26 | LL |         S {ref field_name: _foo} => {} |         -                ^ |         | |         while parsing the fields for this pattern | help: the pattern modifiers belong after the `:` | LL -         S {ref field_name: _foo} => {} LL +         S {field_name: ref _foo} => {} | error: expected `,` --> $DIR/incorrect-placement-of-pattern-modifiers.rs:11:26 | LL |         S {mut field_name: _foo} => {} |         -                ^ |         | |         while parsing the fields for this pattern | help: the pattern modifiers belong after the `:` | LL -         S {mut field_name: _foo} => {} LL +         S {field_name: mut _foo} => {} | error: expected `,` --> $DIR/incorrect-placement-of-pattern-modifiers.rs:14:30 | LL |         S {ref mut field_name: _foo} => {} |         -                    ^ |         | |         while parsing the fields for this pattern | help: the pattern modifiers belong after the `:` | LL -         S {ref mut field_name: _foo} => {} LL +         S {field_name: ref mut _foo} => {} | error[E0308]: mismatched types --> $DIR/incorrect-placement-of-pattern-modifiers.rs:17:20 | LL |     let _: usize = 3u8; |            -----   ^^^ expected `usize`, found `u8` |            | |            expected due to this | help: change the type of the numeric literal from `u8` to `usize` | LL |     let _: usize = 3usize; |                     ~~~~~ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </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. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- 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</details
I realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.

Related discussion:
text: ) )] #[doc(alias = "?")] <ins> #[cfg_attr(not(bootstrap), lang = "try")] </ins> pub trait Try { /// The type of this value when viewed as successful. #[unstable(feature = "try_trait", issue = "42327")]
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. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- 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</details
I realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.

Related discussion:
text: AlignOffsetLangItem,         "align_offset",       align_offset_fn,         Target::Fn; TerminationTraitLangItem,    "termination",        termination,             Target::Trait; <ins> TryTraitLangItem,            "try",                try_trait,               Target::Trait; </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. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- 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</details
I realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.

Related discussion:
text: self.suggest_remove_reference(&obligation, &mut err, &trait_ref); self.suggest_semicolon_removal(&obligation, &mut err, span, &trait_ref); self.note_version_mismatch(&mut err, &trait_ref); <del> self.suggest_await_before_try(&mut err, &obligation, &trait_ref, span); </del> <ins> if Some(trait_ref.def_id()) == tcx.lang_items().try_trait() { self.suggest_await_before_try(&mut err, &obligation, &trait_ref, span); } </ins> if self.suggest_impl_trait(&mut err, span, &obligation, &trait_ref) { err.emit(); return;
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. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- 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</details
I realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.

Related discussion:
text: <ins> // edition:2018 // compile-flags:-Cincremental=tmp/issue-72442 use std::fs::File; use std::future::Future; use std::io::prelude::*; fn main() -> Result<(), Box<dyn std::error::Error>> { block_on(async { { let path = std::path::Path::new("."); let mut f = File::open(path.to_str())?; //~^ ERROR the trait bound let mut src = String::new(); f.read_to_string(&mut src)?; Ok(()) } }) } fn block_on<F>(f: F) -> F::Output where F: Future<Output = Result<(), Box<dyn std::error::Error>>>, { Ok(()) } </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. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- 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</details
I realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.

Related discussion:
text: <ins> error[E0277]: the trait bound `std::option::Option<&str>: std::convert::AsRef<std::path::Path>` is not satisfied --> $DIR/issue-72442.rs:12:36 | LL |             let mut f = File::open(path.to_str())?; |                                    ^^^^^^^^^^^^^ the trait `std::convert::AsRef<std::path::Path>` is not implemented for `std::option::Option<&str>` | ::: $SRC_DIR/libstd/fs.rs:LL:COL | LL |     pub fn open<P: AsRef<Path>>(path: P) -> io::Result<File> { |                    ----------- required by this bound in `std::fs::File::open` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
In I noticed this surprising spelling suggestion: To me and don't seem like they would be similar enough to meet the threshold for showing such a suggestion. Can we calibrate this better for short idents? For comparison, even doesn't assume you mean . rustc 1.45.0-nightly ( 2020-05-23) Mentioning who worked on suggestions most recently in .
I debugged it a bit. is selected as the candidate because the edit distance is just 2 to . The code to fix is likely in or around . I tried some quick tricks but got ICEs and failing tests and gave up. One thing I didn't try that could perhaps work is to consider edit distance between characters of different alphabets/logogram sets as infinite, rather than 1, which is the case right now.
Thank you for investigating! Independent of what we do with different logogram sets (your suggestion sounds plausible), an edit distance of 2 for a string of length 2 should not meet the threshold for showing a suggestion, even within a single logogram set.
I think edit distance of 1 for a string of length 1 is reasonable (a lot of existing UI tests relies on it), but maybe an edit distance of 2 for a string of length 2 is not reasonable indeed. As you point out, with regular chars, the edit distance is still 2 but is not suggested. So maybe there is a simpler fix to be made for than looking at what alphabets/logogram sets characters belong to.

Related discussion:
text: return Some(*c); } <del> let mut dist = dist.unwrap_or_else(|| cmp::max(lookup.len(), 3) / 3); </del> <ins> // `fn edit_distance()` use `chars()` to calculate edit distance, so we must // also use `chars()` (and not `str::len()`) to calculate length here. let lookup_len = lookup.chars().count(); let mut dist = dist.unwrap_or_else(|| cmp::max(lookup_len, 3) / 3); </ins> let mut best = None; // store the candidates with the same distance, only for `use_substring_score` current. let mut next_candidates = vec![];
Code change:
In I noticed this surprising spelling suggestion: To me and don't seem like they would be similar enough to meet the threshold for showing such a suggestion. Can we calibrate this better for short idents? For comparison, even doesn't assume you mean . rustc 1.45.0-nightly ( 2020-05-23) Mentioning who worked on suggestions most recently in .
I debugged it a bit. is selected as the candidate because the edit distance is just 2 to . The code to fix is likely in or around . I tried some quick tricks but got ICEs and failing tests and gave up. One thing I didn't try that could perhaps work is to consider edit distance between characters of different alphabets/logogram sets as infinite, rather than 1, which is the case right now.
Thank you for investigating! Independent of what we do with different logogram sets (your suggestion sounds plausible), an edit distance of 2 for a string of length 2 should not meet the threshold for showing a suggestion, even within a single logogram set.
I think edit distance of 1 for a string of length 1 is reasonable (a lot of existing UI tests relies on it), but maybe an edit distance of 2 for a string of length 2 is not reasonable indeed. As you point out, with regular chars, the edit distance is still 2 but is not suggested. So maybe there is a simpler fix to be made for than looking at what alphabets/logogram sets characters belong to.

Related discussion:
text: <ins> fn main() { // There shall be no suggestions here. In particular not `Ok`. let _ = 读文; //~ ERROR cannot find value `读文` in this scope } </ins>
Code change:
In I noticed this surprising spelling suggestion: To me and don't seem like they would be similar enough to meet the threshold for showing such a suggestion. Can we calibrate this better for short idents? For comparison, even doesn't assume you mean . rustc 1.45.0-nightly ( 2020-05-23) Mentioning who worked on suggestions most recently in .
I debugged it a bit. is selected as the candidate because the edit distance is just 2 to . The code to fix is likely in or around . I tried some quick tricks but got ICEs and failing tests and gave up. One thing I didn't try that could perhaps work is to consider edit distance between characters of different alphabets/logogram sets as infinite, rather than 1, which is the case right now.
Thank you for investigating! Independent of what we do with different logogram sets (your suggestion sounds plausible), an edit distance of 2 for a string of length 2 should not meet the threshold for showing a suggestion, even within a single logogram set.
I think edit distance of 1 for a string of length 1 is reasonable (a lot of existing UI tests relies on it), but maybe an edit distance of 2 for a string of length 2 is not reasonable indeed. As you point out, with regular chars, the edit distance is still 2 but is not suggested. So maybe there is a simpler fix to be made for than looking at what alphabets/logogram sets characters belong to.

Related discussion:
text: <ins> error[E0425]: cannot find value `读文` in this scope --> $DIR/non_ascii_ident.rs:3:13 | LL |     let _ = 读文; |             ^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </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. --reduced 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

Related discussion:
text: // As write_sub_paths, but does not process the last ident in the path (assuming it // will be processed elsewhere). See note on write_sub_paths about global. fn write_sub_paths_truncated(&mut self, path: &'tcx hir::Path<'tcx>) { <del> for seg in &path.segments[..path.segments.len() - 1] { if let Some(data) = self.save_ctxt.get_path_segment_data(seg) { self.dumper.dump_ref(data); </del> <ins> if let [segments @ .., _] = path.segments { for seg in segments { if let Some(data) = self.save_ctxt.get_path_segment_data(seg) { self.dumper.dump_ref(data); } </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. --reduced 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

Related discussion:
text: } } } <del> hir::ExprKind::Struct(hir::QPath::Resolved(_, path), ..) => { </del> <ins> hir::ExprKind::Struct(qpath, ..) => { let segment = match qpath { hir::QPath::Resolved(_, path) => path.segments.last().unwrap(), hir::QPath::TypeRelative(_, segment) => segment, }; </ins> match self.tables.expr_ty_adjusted(&hir_node).kind { ty::Adt(def, _) if !def.is_enum() => { <del> let sub_span = path.segments.last().unwrap().ident.span; </del> <ins> let sub_span = segment.ident.span; </ins> filter!(self.span_utils, sub_span); let span = self.span_from_span(sub_span); Some(Data::RefData(Ref {
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. --reduced 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

Related discussion:
text: } _ => { // FIXME <del> bug!(); </del> <ins> bug!("invalid expression: {:?}", expr); </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. --reduced 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

Related discussion:
text: <ins> // compile-flags: -Zsave-analysis use {self}; //~ ERROR E0431 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. --reduced 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

Related discussion:
text: <ins> error[E0431]: `self` import can only appear in an import list with a non-empty prefix --> $DIR/issue-73020.rs:2:6 | LL | use {self}; |      ^^^^ can only appear in an import list with a non-empty prefix error: aborting due to previous error For more information about this error, try `rustc --explain E0431`. </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. --reduced 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. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

Related discussion:
text: <ins> // build-pass // compile-flags: -Zsave-analysis enum Enum2 { Variant8 { _field: bool }, } impl Enum2 { fn new_variant8() -> Enum2 { Self::Variant8 { _field: true } } } fn main() {} </ins>