jiebi/CodeConvo huggingface dataset:
Code change:
Impl 1: Impl 2: Godbolt: These functions should be equivalent, but the second function generates one more if than the first one. This also happens when using and then doing the slicing manually. I expected the impls to generate the same code.
Quoting myself on Zulip:
This is a metadata preservation failure during SimplifyCFG speculation: Preserving here used to be illegal, but thanks to we are allowed to preserve it now. Only need to drop .
Upstream patch:
Fixed by , needs codegen test.

Related discussion:
text: <ins> //@ compile-flags: -O // This regress since Rust version 1.72. //@ min-llvm-version: 18.1.4 #![crate_type = "lib"] use std::convert::TryInto; const N: usize = 24; #[no_mangle] // CHECK-LABEL: @example // CHECK-NOT: unwrap_failed pub fn example(a: Vec<u8>) -> u8 { if a.len() != 32 { return 0; } let a: [u8; 32] = a.try_into().unwrap(); a[15] + a[N] } </ins>
Code change:
Impl 1: Impl 2: Godbolt: These functions should be equivalent, but the second function generates one more if than the first one. This also happens when using and then doing the slicing manually. I expected the impls to generate the same code.
Quoting myself on Zulip:
This is a metadata preservation failure during SimplifyCFG speculation: Preserving here used to be illegal, but thanks to we are allowed to preserve it now. Only need to drop .
Upstream patch:
Fixed by , needs codegen test.

Related discussion:
text: <ins> //@ compile-flags: -O //@ min-llvm-version: 17 #![crate_type = "lib"] // CHECK-LABEL: @write_u8_variant_a // CHECK: getelementptr // CHECK-NEXT: icmp ugt #[no_mangle] pub fn write_u8_variant_a( bytes: &mut [u8], buf: u8, offset: usize, ) -> Option<&mut [u8]> { let buf = buf.to_le_bytes(); bytes .get_mut(offset..).and_then(|bytes| bytes.get_mut(..buf.len())) } </ins>
Code change:
Impl 1: Impl 2: Godbolt: These functions should be equivalent, but the second function generates one more if than the first one. This also happens when using and then doing the slicing manually. I expected the impls to generate the same code.
Quoting myself on Zulip:
This is a metadata preservation failure during SimplifyCFG speculation: Preserving here used to be illegal, but thanks to we are allowed to preserve it now. Only need to drop .
Upstream patch:
Fixed by , needs codegen test.

Related discussion:
text: <ins> // in Rust 1.73, -O and opt-level=3 optimizes differently //@ compile-flags: -C opt-level=3 //@ min-llvm-version: 17 #![crate_type = "lib"] use std::cmp::max; #[no_mangle] // CHECK-LABEL: @foo // CHECK-NOT: slice_start_index_len_fail // CHECK-NOT: unreachable pub fn foo(v: &mut Vec<u8>, size: usize)-> Option<&mut [u8]> { if v.len() > max(1, size) { let start = v.len() - size; Some(&mut v[start..]) } else { None } } </ins>
Code change:
Impl 1: Impl 2: Godbolt: These functions should be equivalent, but the second function generates one more if than the first one. This also happens when using and then doing the slicing manually. I expected the impls to generate the same code.
Quoting myself on Zulip:
This is a metadata preservation failure during SimplifyCFG speculation: Preserving here used to be illegal, but thanks to we are allowed to preserve it now. Only need to drop .
Upstream patch:
Fixed by , needs codegen test.

Related discussion:
text: <ins> //@ compile-flags: -O //@ min-llvm-version: 18 #![crate_type = "lib"] // CHECK-LABEL: @div2 // CHECK: ashr i32 %a, 1 // CHECK-NEXT: ret i32 #[no_mangle] pub fn div2(a: i32) -> i32 { a.div_euclid(2) } </ins>
Code change:
Impl 1: Impl 2: Godbolt: These functions should be equivalent, but the second function generates one more if than the first one. This also happens when using and then doing the slicing manually. I expected the impls to generate the same code.
Quoting myself on Zulip:
This is a metadata preservation failure during SimplifyCFG speculation: Preserving here used to be illegal, but thanks to we are allowed to preserve it now. Only need to drop .
Upstream patch:
Fixed by , needs codegen test.

Related discussion:
text: <ins> //@ compile-flags: -O #![crate_type = "lib"] const N: usize = 3; pub type T = u8; #[no_mangle] // CHECK-LABEL: @split_mutiple // CHECK-NOT: unreachable pub fn split_mutiple(slice: &[T]) -> (&[T], &[T]) { let len = slice.len() / N; slice.split_at(len * N) } </ins>
Code change:
Impl 1: Impl 2: Godbolt: These functions should be equivalent, but the second function generates one more if than the first one. This also happens when using and then doing the slicing manually. I expected the impls to generate the same code.
Quoting myself on Zulip:
This is a metadata preservation failure during SimplifyCFG speculation: Preserving here used to be illegal, but thanks to we are allowed to preserve it now. Only need to drop .
Upstream patch:
Fixed by , needs codegen test.

Related discussion:
text: <ins> //@ compile-flags: -O //@ min-llvm-version: 17 #![crate_type = "lib"] #[no_mangle] // CHECK-LABEL: @foo // CHECK: {{.*}}: // CHECK: ret // CHECK-NOT: unreachable pub fn foo(arr: &mut [u32]) { for i in 0..arr.len() { for j in 0..i { assert!(j < arr.len()); } } } </ins>
Code change:
Impl 1: Impl 2: Godbolt: These functions should be equivalent, but the second function generates one more if than the first one. This also happens when using and then doing the slicing manually. I expected the impls to generate the same code.
Quoting myself on Zulip:
This is a metadata preservation failure during SimplifyCFG speculation: Preserving here used to be illegal, but thanks to we are allowed to preserve it now. Only need to drop .
Upstream patch:
Fixed by , needs codegen test.

Related discussion:
text: <ins> //@ compile-flags: -O //@ min-llvm-version: 18 #![crate_type = "lib"] use std::ptr::NonNull; // CHECK-LABEL: @slice_ptr_len_1 // CHECK: {{.*}}: // CHECK-NEXT: ret i64 %ptr.1 #[no_mangle] pub fn slice_ptr_len_1(ptr: *const [u8]) -> usize { let ptr = ptr.cast_mut(); if let Some(ptr) = NonNull::new(ptr) { ptr.len() } else { // We know ptr is null, so we know ptr.wrapping_byte_add(1) is not null. NonNull::new(ptr.wrapping_byte_add(1)).unwrap().len() } } </ins>
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: resolve_module_only = visibility must resolve to a module <ins> resolve_macro_expected_found = expected {$expected}, found {$found} `{$macro_path}` resolve_remove_surrounding_derive = remove from the surrounding `derive()` resolve_add_as_non_derive = add as non-Derive macro `#[{$macro_path}]` </ins>
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: #[derive(Diagnostic)] #[diag(resolve_module_only)] pub(crate) struct ModuleOnly(#[primary_span] pub(crate) Span); <ins> #[derive(Diagnostic, Default)] #[diag(resolve_macro_expected_found)] pub(crate) struct MacroExpectedFound<'a> { #[primary_span] pub(crate) span: Span, pub(crate) found: &'a str, pub(crate) expected: &'a str, pub(crate) macro_path: &'a str, #[subdiagnostic] pub(crate) remove_surrounding_derive: Option<RemoveSurroundingDerive>, #[subdiagnostic] pub(crate) add_as_non_derive: Option<AddAsNonDerive<'a>>, } #[derive(Subdiagnostic)] #[help(resolve_remove_surrounding_derive)] pub(crate) struct RemoveSurroundingDerive { #[primary_span] pub(crate) span: Span, } #[derive(Subdiagnostic)] #[help(resolve_add_as_non_derive)] pub(crate) struct AddAsNonDerive<'a> { pub(crate) macro_path: &'a str, } </ins>
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: //! A bunch of methods and structures more or less related to resolving macros and //! interface provided by `Resolver` to macro expander. <ins> use crate::errors::{AddAsNonDerive, MacroExpectedFound, RemoveSurroundingDerive}; </ins> use crate::Namespace::*; use crate::{BuiltinMacroState, Determinacy}; use crate::{DeriveData, Finalize, ParentScope, ResolutionError, Resolver, ScopeSet};
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: }; if let Some((article, expected)) = unexpected_res { let path_str = pprust::path_to_string(path); <del> let msg = format!("expected {}, found {} `{}`", expected, res.descr(), path_str); self.tcx .sess .struct_span_err(path.span, &msg) .span_label(path.span, format!("not {} {}", article, expected)) .emit(); </del> <ins> let mut err = MacroExpectedFound { span: path.span, expected, found: res.descr(), macro_path: &path_str, ..Default::default() // Subdiagnostics default to None }; // Suggest moving the macro out of the derive() if the macro isn't Derive if !path.span.from_expansion() && kind == MacroKind::Derive && ext.macro_kind() != MacroKind::Derive { err.remove_surrounding_derive = Some(RemoveSurroundingDerive { span: path.span }); err.add_as_non_derive = Some(AddAsNonDerive { macro_path: &path_str }); } let mut err = self.tcx.sess.create_err(err); err.span_label(path.span, format!("not {} {}", article, expected)); err.emit(); </ins> return Ok((self.dummy_ext(kind), Res::Err)); }
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: | LL | #[derive(inline)] |          ^^^^^^ not a derive macro <ins> | help: remove from the surrounding `derive()` --> $DIR/macro-path-prelude-fail-4.rs:1:10 | LL | #[derive(inline)] |          ^^^^^^ = help: add as non-Derive macro `#[inline]` </ins> error: aborting due to previous error
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: <ins> #[derive(Clone, Debug)] // OK struct S; #[derive(Debug, inline)] //~ ERROR expected derive macro, found built-in attribute `inline` struct T; #[derive(inline, Debug)] //~ ERROR expected derive macro, found built-in attribute `inline` struct U; fn main() {} </ins>
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: <ins> error: expected derive macro, found built-in attribute `inline` --> $DIR/macro-path-prelude-fail-5.rs:4:17 | LL | #[derive(Debug, inline)] |                 ^^^^^^ not a derive macro | help: remove from the surrounding `derive()` --> $DIR/macro-path-prelude-fail-5.rs:4:17 | LL | #[derive(Debug, inline)] |                 ^^^^^^ = help: add as non-Derive macro `#[inline]` error: expected derive macro, found built-in attribute `inline` --> $DIR/macro-path-prelude-fail-5.rs:7:10 | LL | #[derive(inline, Debug)] |          ^^^^^^ not a derive macro | help: remove from the surrounding `derive()` --> $DIR/macro-path-prelude-fail-5.rs:7:10 | LL | #[derive(inline, Debug)] |          ^^^^^^ = help: add as non-Derive macro `#[inline]` error: aborting due to 2 previous errors </ins>
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: | LL | #[derive(my_macro_attr)] |          ^^^^^^^^^^^^^ not a derive macro <ins> | help: remove from the surrounding `derive()` --> $DIR/macro-namespace-reserved-2.rs:53:10 | LL | #[derive(my_macro_attr)] |          ^^^^^^^^^^^^^ = help: add as non-Derive macro `#[my_macro_attr]` </ins> error: can't use a procedural macro from the same crate that defines it --> $DIR/macro-namespace-reserved-2.rs:56:10
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: | LL | #[derive(crate::my_macro)] |          ^^^^^^^^^^^^^^^ not a derive macro <ins> | help: remove from the surrounding `derive()` --> $DIR/macro-namespace-reserved-2.rs:50:10 | LL | #[derive(crate::my_macro)] |          ^^^^^^^^^^^^^^^ = help: add as non-Derive macro `#[crate::my_macro]` </ins> error: cannot find macro `my_macro_attr` in this scope --> $DIR/macro-namespace-reserved-2.rs:28:5
Code change:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable

Related discussion:
text: | LL | #[derive(rustfmt::skip)] |          ^^^^^^^^^^^^^ not a derive macro <ins> | help: remove from the surrounding `derive()` --> $DIR/tool-attributes-misplaced-2.rs:1:10 | LL | #[derive(rustfmt::skip)] |          ^^^^^^^^^^^^^ = help: add as non-Derive macro `#[rustfmt::skip]` </ins> error: expected macro, found tool attribute `rustfmt::skip` --> $DIR/tool-attributes-misplaced-2.rs:5:5