jiebi/CodeConvo huggingface dataset:
Code change:
Let's say you have the following (simplified) code: () This results in the following error: The suggested fix will work, but already copies the data so the extra is wasteful. The error message should instead suggest . This is an error you can run into if was previously of type and you changed it to a slice after writing the rest of the code.
Note: this kind of improvement applies to too: Err:

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/issue-53692.rs:13:37 | LL |         let items_clone: Vec<i32> = ref_items.clone(); |                                     ^^^^^^^^^^^^^^^^^ |                                     | |                                     expected struct `std::vec::Vec`, found &[i32] |                                     help: try using a conversion method: `ref_items.to_vec()` | = note: expected type `std::vec::Vec<i32>` found type `&[i32]` error[E0308]: mismatched types --> $DIR/issue-53692.rs:19:30 | LL |         let string: String = s.clone(); |                              ^^^^^^^^^ |                              | |                              expected struct `std::string::String`, found &str |                              help: try using a conversion method: `s.to_string()` | = note: expected type `std::string::String` found type `&str` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
This example (reduced from ) either crashes LLVM or makes it emit an assertion: I suspect the loops aren't needed, but the control-flow there affects the bug in finicky ways. The name of the module appears to be important and tied to the fact that we end up emitting in a symbol name (because of the ), which gets mangled as (note the two dots). Among other things, changing the we use to mangle , to makes the bug go away. Assertion message (if LLVM assertions are enabled): Stack backtrace for SIGSEGV (if LLVM assertions are disabled): cc
Found the culprit in : LLVM implicitly assumes that cannot show up randomly in symbol names, and rustc breaks that assumption - but LLVM never checks it, so it shares part of the blame here, IMO. Probably the correct thing to do for LLVM is to split the string at the last , instead of the first.
Why are computers
The work around I introduced with the above commit is a proposition of and fixes this issue with the segfault.
Sanitizing to and adding a debug assertion would also be a good idea.

Related discussion:
text: // for ':' and '-' '-' | ':' => self.path.temp_buf.push('.'), <ins> // Avoid segmentation fault on some platforms, see #60925. 'm' if self.path.temp_buf.ends_with(".llv") => self.path.temp_buf.push_str("$6d$"), </ins> // These are legal symbols 'a'..='z' | 'A'..='Z' | '0'..='9' | '_' | '.' | '$' => self.path.temp_buf.push(c),
Code change:
This example (reduced from ) either crashes LLVM or makes it emit an assertion: I suspect the loops aren't needed, but the control-flow there affects the bug in finicky ways. The name of the module appears to be important and tied to the fact that we end up emitting in a symbol name (because of the ), which gets mangled as (note the two dots). Among other things, changing the we use to mangle , to makes the bug go away. Assertion message (if LLVM assertions are enabled): Stack backtrace for SIGSEGV (if LLVM assertions are disabled): cc
Found the culprit in : LLVM implicitly assumes that cannot show up randomly in symbol names, and rustc breaks that assumption - but LLVM never checks it, so it shares part of the blame here, IMO. Probably the correct thing to do for LLVM is to split the string at the last , instead of the first.
Why are computers
The work around I introduced with the above commit is a proposition of and fixes this issue with the segfault.
Sanitizing to and adding a debug assertion would also be a good idea.

Related discussion:
text: <ins> // compile-pass // This test is the same code as in ui/symbol-names/issue-60925.rs but this checks that the // reproduction compiles successfully and doesn't segfault, whereas that test just checks that the // symbol mangling fix produces the correct result. fn dummy() {} mod llvm { pub(crate) struct Foo; } mod foo { pub(crate) struct Foo<T>(T); impl Foo<::llvm::Foo> { pub(crate) fn foo() { for _ in 0..0 { for _ in &[::dummy()] { ::dummy(); ::dummy(); ::dummy(); } } } } pub(crate) fn foo() { Foo::foo(); Foo::foo(); } } pub fn foo() { foo::foo(); } fn main() {} </ins>
Code change:
This example (reduced from ) either crashes LLVM or makes it emit an assertion: I suspect the loops aren't needed, but the control-flow there affects the bug in finicky ways. The name of the module appears to be important and tied to the fact that we end up emitting in a symbol name (because of the ), which gets mangled as (note the two dots). Among other things, changing the we use to mangle , to makes the bug go away. Assertion message (if LLVM assertions are enabled): Stack backtrace for SIGSEGV (if LLVM assertions are disabled): cc
Found the culprit in : LLVM implicitly assumes that cannot show up randomly in symbol names, and rustc breaks that assumption - but LLVM never checks it, so it shares part of the blame here, IMO. Probably the correct thing to do for LLVM is to split the string at the last , instead of the first.
Why are computers
The work around I introduced with the above commit is a proposition of and fixes this issue with the segfault.
Sanitizing to and adding a debug assertion would also be a good idea.

Related discussion:
text: <ins> #![feature(rustc_attrs)] // This test is the same code as in ui/issue-53912.rs but this test checks that the symbol mangling // fix produces the correct result, whereas that test just checks that the reproduction compiles // successfully and doesn't segfault fn dummy() {} mod llvm { pub(crate) struct Foo; } mod foo { pub(crate) struct Foo<T>(T); impl Foo<::llvm::Foo> { #[rustc_symbol_name] //~^ ERROR _ZN11issue_609253foo36Foo$LT$issue_60925..llv$6d$..Foo$GT$3foo17h059a991a004536adE pub(crate) fn foo() { for _ in 0..0 { for _ in &[::dummy()] { ::dummy(); ::dummy(); ::dummy(); } } } } pub(crate) fn foo() { Foo::foo(); Foo::foo(); } } pub fn foo() { foo::foo(); } fn main() {} </ins>
Code change:
This example (reduced from ) either crashes LLVM or makes it emit an assertion: I suspect the loops aren't needed, but the control-flow there affects the bug in finicky ways. The name of the module appears to be important and tied to the fact that we end up emitting in a symbol name (because of the ), which gets mangled as (note the two dots). Among other things, changing the we use to mangle , to makes the bug go away. Assertion message (if LLVM assertions are enabled): Stack backtrace for SIGSEGV (if LLVM assertions are disabled): cc
Found the culprit in : LLVM implicitly assumes that cannot show up randomly in symbol names, and rustc breaks that assumption - but LLVM never checks it, so it shares part of the blame here, IMO. Probably the correct thing to do for LLVM is to split the string at the last , instead of the first.
Why are computers
The work around I introduced with the above commit is a proposition of and fixes this issue with the segfault.
Sanitizing to and adding a debug assertion would also be a good idea.

Related discussion:
text: <ins> error: symbol-name(_ZN11issue_609253foo36Foo$LT$issue_60925..llv$6d$..Foo$GT$3foo17h059a991a004536adE) --> $DIR/issue-60925.rs:16:9 | LL |         #[rustc_symbol_name] |         ^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:

Related discussion:
text: <ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>
Code change:
Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:

Related discussion:
text: <ins> // edition:2018 use std::sync::{Arc, Mutex}; pub async fn f(_: ()) {} pub async fn run() { let x: Arc<Mutex<()>> = unimplemented!(); f(*x.lock().unwrap()).await; } </ins>
Code change:
Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:

Related discussion:
text: <ins> // aux-build: issue_67893.rs // edition:2018 // dont-check-compiler-stderr // FIXME(#71222): Add above flag because of the difference of stderrs on some env. extern crate issue_67893; fn g(_: impl Send) {} fn main() { g(issue_67893::run()) //~^ ERROR: `std::sync::MutexGuard<'_, ()>` cannot be sent between threads safely } </ins>
Code change:
Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:

Related discussion:
text: <ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>
Code change:
Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:

Related discussion:
text: <ins> error[E0133]: use of extern static is unsafe and requires unsafe function or block --> $DIR/issue-28575.rs:8:5 | LL |     FOO() |     ^^^ use of extern static | = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior error: aborting due to previous error For more information about this error, try `rustc --explain E0133`. </ins>
Code change:
Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:

Related discussion:
text: <ins> pub static TEST_STR: &'static str = "Hello world"; </ins>
Code change:
Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:

Related discussion:
text: <ins> // aux-build: issue_24843.rs // check-pass extern crate issue_24843; static _TEST_STR_2: &'static str = &issue_24843::TEST_STR; fn main() {} </ins>
Code change:
This page: It's not obvious that reference equality is accomplished via implicit reference-pointer coercion plus . The docs mention this, but I would not look there to find reference equality. The reference primitive page is someplace I would look for info about reference equality. Update this page to discuss reference equality, and link to .
Can I help with this issue?
Still waiting for your reply
Sorry, it looks like got to this now, in

Related discussion:
text: /// `&mut T` references can be freely coerced into `&T` references with the same referent type, and /// references with longer lifetimes can be freely coerced into references with shorter ones. /// <ins> /// Reference equality by address, instead of comparing the values pointed to, is accomplished via /// implicit reference-pointer coercion and raw pointer equality via [`ptr::eq`], while /// [`PartialEq`] compares values. /// /// [`ptr::eq`]: ptr/fn.eq.html /// [`PartialEq`]: cmp/trait.PartialEq.html /// /// ``` /// use std::ptr; /// /// let five = 5; /// let other_five = 5; /// let five_ref = &five; /// let same_five_ref = &five; /// let other_five_ref = &other_five; /// /// assert!(five_ref == same_five_ref); /// assert!(five_ref == other_five_ref); /// /// assert!(ptr::eq(five_ref, same_five_ref)); /// assert!(!ptr::eq(five_ref, other_five_ref)); /// ``` /// </ins> /// For more information on how to use references, see [the book's section on "References and /// Borrowing"][book-refs]. /// /// [book-refs]: ../book/second-edition/ch04-02-references-and-borrowing.html /// <ins> /// # Trait implementations /// </ins> /// The following traits are implemented for all `&T`, regardless of the type of its referent: /// /// * [`Copy`]
Code change:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.

Related discussion:
text: match attr.parse_list(cx.parse_sess, |parser| parser.parse_path_allowing_meta(PathStyle::Mod)) { <del> Ok(ref traits) if traits.is_empty() => { cx.span_warn(attr.span, "empty trait list in `derive`"); false } </del> Ok(traits) => { result.extend(traits); true
Code change:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.

Related discussion:
text: <del> // compile-pass </del> <ins> #![deny(unused)] </ins> <del> #[derive()] //~ WARNING empty trait list in `derive` struct Bar; </del> <ins> #[derive()] //~ ERROR unused attribute struct _Bar; </ins> pub fn main() {}
Code change:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.

Related discussion:
text: <del> warning: empty trait list in `derive` </del> <ins> error: unused attribute </ins> --> $DIR/deriving-meta-empty-trait-list.rs:3:1 | LL | #[derive()] | ^^^^^^^^^^^ <ins> | note: lint level defined here --> $DIR/deriving-meta-empty-trait-list.rs:1:9 | LL | #![deny(unused)] |         ^^^^^^ = note: #[deny(unused_attributes)] implied by #[deny(unused)] error: aborting due to previous error </ins>
Code change:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.

Related discussion:
text: #[derive(Copy="bad")] //~ ERROR expected one of `)`, `,`, or `::`, found `=` struct Test2; <del> #[derive()] //~ WARNING empty trait list struct Test3; </del> #[derive] //~ ERROR malformed `derive` attribute input struct Test4;
Code change:
The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.

Related discussion:
text: LL | #[derive(Copy="bad")] |              ^ expected one of `)`, `,`, or `::` here <del> warning: empty trait list in `derive` --> $DIR/malformed-derive-entry.rs:7:1 | LL | #[derive()] | ^^^^^^^^^^^ </del> error: malformed `derive` attribute input <del> --> $DIR/malformed-derive-entry.rs:10:1 </del> <ins> --> $DIR/malformed-derive-entry.rs:7:1 </ins> | LL | #[derive] | ^^^^^^^^^ help: missing traits to be derived: `#[derive(Trait1, Trait2, ...)]`