jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: struct_span_err!(sess, sp, E0004, "{}", &error_message) } <ins> #[derive(PartialEq)] enum RefutableFlag { Irrefutable, Refutable, } use RefutableFlag::*; </ins> struct MatchVisitor<'a, 'p, 'tcx> { tcx: TyCtxt<'tcx>, typeck_results: &'a ty::TypeckResults<'tcx>,
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: hir::LocalSource::AssignDesugar(_) => ("destructuring assignment binding", None), }; self.check_irrefutable(&loc.pat, msg, sp); <del> self.check_patterns(&loc.pat); </del> <ins> self.check_patterns(&loc.pat, Irrefutable); </ins> } fn visit_param(&mut self, param: &'tcx hir::Param<'tcx>) { intravisit::walk_param(self, param); self.check_irrefutable(&param.pat, "function argument", None); <del> self.check_patterns(&param.pat); </del> <ins> self.check_patterns(&param.pat, Irrefutable); </ins> } }
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: } impl<'p, 'tcx> MatchVisitor<'_, 'p, 'tcx> { <del> fn check_patterns(&self, pat: &Pat<'_>) { </del> <ins> fn check_patterns(&self, pat: &Pat<'_>, rf: RefutableFlag) { </ins> pat.walk_always(|pat| check_borrow_conflicts_in_at_patterns(self, pat)); <del> check_for_bindings_named_same_as_variants(self, pat); </del> <ins> check_for_bindings_named_same_as_variants(self, pat, rf); </ins> } fn lower_pattern(
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: } fn check_let(&mut self, pat: &'tcx hir::Pat<'tcx>, expr: &hir::Expr<'_>, span: Span) { <del> self.check_patterns(pat); </del> <ins> self.check_patterns(pat, Refutable); </ins> let mut cx = self.new_cx(expr.hir_id); let tpat = self.lower_pattern(&mut cx, pat, &mut false); check_let_reachability(&mut cx, pat.hir_id, tpat, span);
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: for arm in arms { // Check the arm for some things unrelated to exhaustiveness. <del> self.check_patterns(&arm.pat); </del> <ins> self.check_patterns(&arm.pat, Refutable); </ins> if let Some(hir::Guard::IfLet(ref pat, _)) = arm.guard { <del> self.check_patterns(pat); </del> <ins> self.check_patterns(pat, Refutable); </ins> let tpat = self.lower_pattern(&mut cx, pat, &mut false); check_let_reachability(&mut cx, pat.hir_id, tpat, tpat.span()); }
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: } } <del> fn check_for_bindings_named_same_as_variants(cx: &MatchVisitor<'_, '_, '_>, pat: &Pat<'_>) { </del> <ins> fn check_for_bindings_named_same_as_variants( cx: &MatchVisitor<'_, '_, '_>, pat: &Pat<'_>, rf: RefutableFlag, ) { </ins> pat.walk_always(|p| { if let hir::PatKind::Binding(_, _, ident, None) = p.kind { if let Some(ty::BindByValue(hir::Mutability::Not)) =
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: variant.ident == ident && variant.ctor_kind == CtorKind::Const }) { <ins> let variant_count = edef.variants.len(); </ins> cx.tcx.struct_span_lint_hir( BINDINGS_WITH_VARIANT_NAME, p.hir_id, p.span, |lint| { let ty_path = cx.tcx.def_path_str(edef.did); <del> lint.build(&format!( </del> <ins> let mut err = lint.build(&format!( </ins> "pattern binding `{}` is named the same as one  <del> of the variants of the type `{}`", </del> <ins> of the variants of the type `{}`", </ins> ident, ty_path <del> )) .code(error_code!(E0170)) .span_suggestion( p.span, "to match on the variant, qualify the path", format!("{}::{}", ty_path, ident), Applicability::MachineApplicable, ) .emit(); </del> <ins> )); err.code(error_code!(E0170)); // If this is an irrefutable pattern, and there's > 1 variant, // then we can't actually match on this. Applying the below // suggestion would produce code that breaks on `check_irrefutable`. if rf == Refutable || variant_count == 1 { err.span_suggestion( p.span, "to match on the variant, qualify the path", format!("{}::{}", ty_path, ident), Applicability::MachineApplicable, ); } err.emit(); </ins> }, ) }
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: <ins> #![allow(unused, nonstandard_style)] #![deny(bindings_with_variant_name)] // If an enum has two different variants, // then it cannot be matched upon in a function argument. // It still gets a warning, but no suggestions. enum Foo { C, D, } fn foo(C: Foo) {} //~ERROR fn main() { let C = Foo::D; //~ERROR } </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case

Related discussion:
text: <ins> error[E0170]: pattern binding `C` is named the same as one of the variants of the type `Foo` --> $DIR/issue-88730.rs:12:8 | LL | fn foo(C: Foo) {} |        ^ | note: the lint level is defined here --> $DIR/issue-88730.rs:2:9 | LL | #![deny(bindings_with_variant_name)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0170]: pattern binding `C` is named the same as one of the variants of the type `Foo` --> $DIR/issue-88730.rs:15:9 | LL |     let C = Foo::D; |         ^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0170`. </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)

Related discussion:
text: if self.not_enough_args_provided() { self.suggest_adding_args(err); } else if self.too_many_args_provided() { <ins> self.suggest_moving_args_from_assoc_fn_to_trait(err); </ins> self.suggest_removing_args_or_generics(err); } else { unreachable!();
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)

Related discussion:
text: --> $DIR/invalid-const-arg-for-type-param.rs:6:23 | LL |     let _: u32 = 5i32.try_into::<32>().unwrap(); <del> |                       ^^^^^^^^------ help: remove these generics |                       | |                       expected 0 generic arguments </del> <ins> |                       ^^^^^^^^ expected 0 generic arguments </ins> | note: associated function defined here, with 0 generic parameters --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn try_into(self) -> Result<T, Self::Error>; |        ^^^^^^^^ <ins> help: consider moving this generic argument to the `TryInto` trait, which takes up to 1 argument | LL |     let _: u32 = TryInto::<32>::try_into(5i32).unwrap(); |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ help: remove these generics | LL -     let _: u32 = 5i32.try_into::<32>().unwrap(); LL +     let _: u32 = 5i32.try_into().unwrap(); | </ins> error[E0599]: no method named `f` found for struct `S` in the current scope --> $DIR/invalid-const-arg-for-type-param.rs:9:7
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)

Related discussion:
text: <ins> use std::convert::TryInto; trait A<T> { fn foo() {} } trait B<T, U> { fn bar() {} } struct S; impl<T> A<T> for S {} impl<T, U> B<T, U> for S {} fn main() { let _ = A::foo::<S>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving this generic argument let _ = B::bar::<S, S>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving these generic arguments let _ = A::<S>::foo::<S>(); //~^ ERROR //~| HELP remove these generics let _ = 42.into::<Option<_>>(); //~^ ERROR //~| HELP remove these generics //~| HELP consider moving this generic argument } </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. --When compiling on an Apple M1 processor: <!-- 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
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

Related discussion:
text: } impl<'tcx> FieldDef { <del> /// Returns the type of this field. The `subst` is typically obtained /// via the second field of `TyKind::AdtDef`. </del> <ins> /// Returns the type of this field. The resulting type is not normalized. The `subst` is /// typically obtained via the second field of `TyKind::AdtDef`. </ins> pub fn ty(&self, tcx: TyCtxt<'tcx>, subst: SubstsRef<'tcx>) -> Ty<'tcx> { tcx.type_of(self.did).subst(tcx, subst) }
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. --When compiling on an Apple M1 processor: <!-- 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
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

Related discussion:
text: variant.fields.iter().enumerate().filter_map(move |(i, field)| { let ty = field.ty(cx.tcx, substs); <ins> // `field.ty()` doesn't normalize after substituting. let ty = cx.tcx.normalize_erasing_regions(cx.param_env, ty); </ins> let is_visible = adt.is_enum() || field.vis.is_accessible_from(cx.module, cx.tcx); let is_uninhabited = cx.is_uninhabited(ty);
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. --When compiling on an Apple M1 processor: <!-- 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
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.

Related discussion:
text: write!(f, "{}", hi) } IntRange(range) => write!(f, "{:?}", range), // Best-effort, will render e.g. `false` as `0..=0` <del> Wildcard | Missing { .. } | NonExhaustive => write!(f, "_"), </del> <ins> Wildcard | Missing { .. } | NonExhaustive => write!(f, "_ : {:?}", self.ty), </ins> Or => { for pat in self.iter_fields() { write!(f, "{}{:?}", start_or_continue(" | "), pat)?;