jiebi/CodeConvo huggingface dataset:
Code change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.

Related discussion:
text: <ins> //! Previously, we tried to remove extra arg commas when providing extra arg removal suggestions. //! One of the edge cases is having to account for an arg that has a closing delimiter `)` //! following it. However, the previous suggestion code assumed that the delimiter is in fact //! exactly the 1-byte `)` character. This assumption was proven incorrect, because we recover //! from Unicode-confusable delimiters in the parser, which means that the ending delimiter could be //! a multi-byte codepoint that looks *like* a `)`. Subtracing 1 byte could land us in the middle of //! a codepoint, triggering a codepoint boundary assertion. //! //! issue: rust-lang/rust#128717 fn main() { // The following example has been modified from #128717 to remove irrelevant Unicode as they do // not otherwise partake in the right delimiter calculation causing the codepoint boundary // assertion. main(rahh）; //~^ ERROR unknown start of token //~| ERROR this function takes 0 arguments but 1 argument was supplied //~| ERROR cannot find value `rahh` in this scope } </ins>
Code change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.

Related discussion:
text: <ins> error: unknown start of token: u{ff09} --> $DIR/suggest-arg-comma-delete-ice.rs:15:14 | LL |     main(rahh）; |              ^^ | help: Unicode character '）' (Fullwidth Right Parenthesis) looks like ')' (Right Parenthesis), but it is not | LL |     main(rahh); |              ~ error[E0425]: cannot find value `rahh` in this scope --> $DIR/suggest-arg-comma-delete-ice.rs:15:10 | LL |     main(rahh）; |          ^^^^ not found in this scope error[E0061]: this function takes 0 arguments but 1 argument was supplied --> $DIR/suggest-arg-comma-delete-ice.rs:15:5 | LL |     main(rahh）; |     ^^^^ ---- unexpected argument | note: function defined here --> $DIR/suggest-arg-comma-delete-ice.rs:11:4 | LL | fn main() { |    ^^^^ help: remove the extra argument | LL -     main(rahh）; LL +     main(）; | error: aborting due to 3 previous errors Some errors have detailed explanations: E0061, E0425. For more information about an error, try `rustc --explain E0061`. </ins>
Code change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.

Related discussion:
text: fn parse_initializer(&mut self, eq_optional: bool) -> PResult<'a, Option<P<Expr>>> { let eq_consumed = match self.token.kind { token::BinOpEq(..) => { <del> // Recover `let x <op>= 1` as `let x = 1` </del> <ins> // Recover `let x <op>= 1` as `let x = 1` We must not use `+ BytePos(1)` here // because `<op>` can be a multi-byte lookalike that was recovered, e.g. `➖=` (the // `➖` is a U+2796 Heavy Minus Sign Unicode Character) that was recovered as a // `-=`. let extra_op_span = self.psess.source_map().start_point(self.token.span); </ins> self.dcx().emit_err(errors::CompoundAssignmentExpressionInLet { span: self.token.span, <del> suggestion: self.token.span.with_hi(self.token.span.lo() + BytePos(1)), </del> <ins> suggestion: extra_op_span, </ins> }); self.bump(); true
Code change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.

Related discussion:
text: <ins> //! Previously we would try to issue a suggestion for `let x <op>= 1`, i.e. a compound assignment //! within a `let` binding, to remove the `<op>`. The suggestion code unfortunately incorrectly //! assumed that the `<op>` is an exactly-1-byte ASCII character, but this assumption is incorrect //! because we also recover Unicode-confusables like `➖=` as `-=`. In this example, the suggestion //! code used a `+ BytePos(1)` to calculate the span of the `<op>` codepoint that looks like `-` but //! the mult-byte Unicode look-alike would cause the suggested removal span to be inside a //! multi-byte codepoint boundary, triggering a codepoint boundary assertion. //! //! issue: rust-lang/rust#128845 fn main() { // Adapted from #128845 but with irrelevant components removed and simplified. let x ➖= 1; //~^ ERROR unknown start of token: u{2796} //~| ERROR: can't reassign to an uninitialized variable } </ins>
Code change:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.

Related discussion:
text: <ins> error: unknown start of token: u{2796} --> $DIR/suggest-remove-compount-assign-let-ice.rs:13:11 | LL |     let x ➖= 1; |           ^^ | help: Unicode character '➖' (Heavy Minus Sign) looks like '-' (Minus/Hyphen), but it is not | LL |     let x -= 1; |           ~ error: can't reassign to an uninitialized variable --> $DIR/suggest-remove-compount-assign-let-ice.rs:13:11 | LL |     let x ➖= 1; |           ^^^ | = help: if you meant to overwrite, remove the `let` binding help: initialize the variable | LL -     let x ➖= 1; LL +     let x = 1; | error: aborting due to 2 previous errors </ins>
Code change:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.

Related discussion:
text: // gdb-command:run // gdb-command:print some <del> // gdb-check:$1 = core::option::Option<&u32>::Some(0x12345678) </del> <ins> // gdb-check:$1 = core::option::Option<&u32>::Some(0x[...]) </ins> // gdb-command:print none // gdb-check:$2 = core::option::Option<&u32>::None // gdb-command:print full <del> // gdb-check:$3 = option_like_enum::MoreFields::Full(454545, 0x87654321, 9988) </del> <ins> // gdb-check:$3 = option_like_enum::MoreFields::Full(454545, 0x[...], 9988) </ins> <del> // gdb-command:print empty_gdb.discr // gdb-check:$4 = (*mut isize) 0x1 </del> <ins> // gdb-command:print empty // gdb-check:$4 = option_like_enum::MoreFields::Empty </ins> // gdb-command:print droid <del> // gdb-check:$5 = option_like_enum::NamedFields::Droid{id: 675675, range: 10000001, internals: 0x43218765} </del> <ins> // gdb-check:$5 = option_like_enum::NamedFields::Droid{id: 675675, range: 10000001, internals: 0x[...]} </ins> <del> // gdb-command:print void_droid_gdb.internals // gdb-check:$6 = (*mut isize) 0x1 </del> <ins> // gdb-command:print void_droid // gdb-check:$6 = option_like_enum::NamedFields::Void </ins> // gdb-command:print nested_non_zero_yep // gdb-check:$7 = option_like_enum::NestedNonZero::Yep(10.5, option_like_enum::NestedNonZeroField {a: 10, b: 20, c: 0x[...]})
Code change:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.

Related discussion:
text: // lldb-command:run // lldb-command:v some <del> // lldb-check:[...] Some(&0x12345678) </del> <ins> // lldb-check:[...] Some(&0x[...]) </ins> // lldb-command:v none // lldb-check:[...] None // lldb-command:v full <del> // lldb-check:[...] Full(454545, &0x87654321, 9988) </del> <ins> // lldb-check:[...] Full(454545, &0x[...], 9988) </ins> // lldb-command:v empty // lldb-check:[...] Empty // lldb-command:v droid <del> // lldb-check:[...] Droid { id: 675675, range: 10000001, internals: &0x43218765 } </del> <ins> // lldb-check:[...] Droid { id: 675675, range: 10000001, internals: &0x[...] } </ins> // lldb-command:v void_droid // lldb-check:[...] Void
Code change:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.

Related discussion:
text: // contains a non-nullable pointer, then this value is used as the discriminator. // The test cases in this file make sure that something readable is generated for // this kind of types. <del> // If the non-empty variant contains a single non-nullable pointer than the whole // item is represented as just a pointer and not wrapped in a struct. // Unfortunately (for these test cases) the content of the non-discriminant fields // in the null-case is not defined. So we just read the discriminator field in // this case (by casting the value to a memory-equivalent struct). </del> enum MoreFields<'a> { Full(u32, &'a isize, i16),
Code change:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.

Related discussion:
text: let some_str: Option<&'static str> = Some("abc"); let none_str: Option<&'static str> = None; <del> let some: Option<&u32> = Some(unsafe { std::mem::transmute(0x12345678_usize) }); </del> <ins> let some: Option<&u32> = Some(&1234); </ins> let none: Option<&u32> = None; <del> let full = MoreFields::Full(454545, unsafe { std::mem::transmute(0x87654321_usize) }, 9988); </del> <ins> let full = MoreFields::Full(454545, &1234, 9988); </ins> let empty = MoreFields::Empty; <del> let empty_gdb: &MoreFieldsRepr = unsafe { std::mem::transmute(&MoreFields::Empty) }; </del> let droid = NamedFields::Droid { id: 675675, range: 10000001, <del> internals: unsafe { std::mem::transmute(0x43218765_usize) } </del> <ins> internals: &1234, </ins> }; let void_droid = NamedFields::Void; <del> let void_droid_gdb: &NamedFieldsRepr = unsafe { std::mem::transmute(&NamedFields::Void) }; let x = 'x'; </del> let nested_non_zero_yep = NestedNonZero::Yep( 10.5, NestedNonZeroField { a: 10, b: 20, <del> c: &x </del> <ins> c: &'x', </ins> }); let nested_non_zero_nope = NestedNonZero::Nope; zzz(); // #break
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. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

Related discussion:
text: .find_ancestor_inside(value.span) .map(|span| (value.span.with_hi(span.lo()), value.span.with_lo(span.hi()))), ast::ExprKind::Paren(ref expr) => { <del> expr.span.find_ancestor_inside(value.span).map(|expr_span| { </del> <ins> // For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, // the span should contains the attributes, or the suggestion will remove them. let expr_span_with_attrs = if let Some(attr_lo) = expr.attrs.iter().map(|attr| attr.span.lo()).min() { expr.span.with_lo(attr_lo) } else { expr.span }; expr_span_with_attrs.find_ancestor_inside(value.span).map(|expr_span| { </ins> (value.span.with_hi(expr_span.lo()), value.span.with_lo(expr_span.hi())) }) }
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. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

Related discussion:
text: <ins> //@ run-rustfix // Check the `unused_parens` suggestion for paren_expr with attributes. // The suggestion should retain attributes in the front. #![feature(stmt_expr_attributes)] #![deny(unused_parens)] pub fn foo() -> impl Fn() { let _ = #[inline] #[allow(dead_code)] || println!("Hello!"); //~ERROR unnecessary parentheses #[inline] #[allow(dead_code)] || println!("Hello!") //~ERROR unnecessary parentheses } fn main() { let _ = foo(); } </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. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

Related discussion:
text: <ins> //@ run-rustfix // Check the `unused_parens` suggestion for paren_expr with attributes. // The suggestion should retain attributes in the front. #![feature(stmt_expr_attributes)] #![deny(unused_parens)] pub fn foo() -> impl Fn() { let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); //~ERROR unnecessary parentheses (#[inline] #[allow(dead_code)] || println!("Hello!")) //~ERROR unnecessary parentheses } fn main() { let _ = foo(); } </ins>