jiebi/CodeConvo huggingface dataset:
Code change:
I was experimenting with some code on godbolt, when encountering this: with produces the expected assembly: However, when adding (into the same file) this function: The previous function's codegen changes to The issue: it stores the result on the stack, and then immediately discards that. (which it didn't do previously) The second potential issue I'm unsure about is, that here a function's codegen changes by just adding removing seemingly unrelated functions. I was told on discord this is because the two functions use the same , and adding the second one forces to be generalized to and as opposed to just . But I by far don't know enough to judge whether this is a problem or not, or what it's caused by, but I wanted to mention it.
label +A-codegen +I-slow +T-compiler
What's really weird is that on , it looks like this: But for , we get this:
The reason why the second call makes a difference is that IPSCCP is no longer able to propagate the slice length into various functions early.
I would probably blame this one a LoopDeletion/SROA interaction. LoopDeletion leaves behind this code: And SROA runs directly afterwards, before the phi has been folded, so we don't know that the GEPs actually access constant offsets. Possibly the backedge-breaking in LoopDeletion should also perform some folding, or we need a phase ordering change.
Or possibly IndVars should already be replacing the PHI. Just remembered that we have the replaceLoopPHINodesWithPreheaderValues() transform, which seems like it should be taking care of this.
and together should fix this.

Related discussion:
text: <ins> // min-llvm-version: 15.0.0 // compile-flags: -O #![crate_type = "lib"] #[no_mangle] pub fn u16_be_to_arch(mut data: [u8; 2]) -> [u8; 2] { // CHECK-LABEL: @u16_be_to_arch // CHECK: @llvm.bswap.i16 data.reverse(); data } #[no_mangle] pub fn u32_be_to_arch(mut data: [u8; 4]) -> [u8; 4] { // CHECK-LABEL: @u32_be_to_arch // CHECK: @llvm.bswap.i32 data.reverse(); data } </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

Related discussion:
text: let size = u64::try_from(self.force_bits(size, pointer_size)?).unwrap(); let align = vtable.read_ptr_sized(pointer_size * 2)?.check_init()?; let align = u64::try_from(self.force_bits(align, pointer_size)?).unwrap(); <ins> let align = Align::from_bytes(align) .map_err(|e| err_ub_format!("invalid vtable: alignment {}", e))?; </ins> if size >= self.tcx.data_layout.obj_size_bound() { throw_ub_format!(
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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

Related discussion:
text: size is bigger than largest supported object" ); } <del> Ok((Size::from_bytes(size), Align::from_bytes(align).unwrap())) </del> <ins> Ok((Size::from_bytes(size), align)) </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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

Related discussion:
text: <ins> // This test contains code with incorrect vtables in a const context: // - from issue 86132: a trait object with invalid alignment caused an ICE in const eval, and now //   triggers an error // - a similar test that triggers a previously-untested const UB error: emitted close to the above //   error, it checks the correctness of the size trait Trait {} const INVALID_VTABLE_ALIGNMENT: &dyn Trait = unsafe { std::mem::transmute((&92u8, &[0usize, 1usize, 1000usize])) }; //~^ ERROR any use of this value will cause an error //~| WARNING this was previously accepted by the compiler //~| invalid vtable: alignment `1000` is not a power of 2 const INVALID_VTABLE_SIZE: &dyn Trait = unsafe { std::mem::transmute((&92u8, &[1usize, usize::MAX, 1usize])) }; //~^ ERROR any use of this value will cause an error //~| WARNING this was previously accepted by the compiler //~| invalid vtable: size is bigger than largest supported object fn main() {} </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

Related discussion:
text: <ins> error: any use of this value will cause an error --> $DIR/ub-incorrect-vtable.rs:10:14 | LL | / const INVALID_VTABLE_ALIGNMENT: &dyn Trait = LL | |     unsafe { std::mem::transmute((&92u8, &[0usize, 1usize, 1000usize])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- |                | |                invalid vtable: alignment `1000` is not a power of 2 | = note: `#[deny(const_err)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: any use of this value will cause an error --> $DIR/ub-incorrect-vtable.rs:16:14 | LL | / const INVALID_VTABLE_SIZE: &dyn Trait = LL | |     unsafe { std::mem::transmute((&92u8, &[1usize, usize::MAX, 1usize])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- |                | |                invalid vtable: size is bigger than largest supported object | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: aborting due to 2 previous errors </ins>
Code change:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)

Related discussion:
text: } w.write_str(")"); } <del> w.write_str("</code></div>"); </del> <ins> w.write_str("</code>"); render_stability_since(w, variant, it, cx.tcx()); w.write_str("</div>"); </ins> document(w, cx, variant, Some(it)); document_non_exhaustive(w, variant);
Code change:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)

Related discussion:
text: w.write_str("</div></div>"); toggle_close(w); } <del> render_stability_since(w, variant, it, cx.tcx()); </del> } } let def_id = it.def_id.expect_real();
Code change:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)

Related discussion:
text: background: transparent; } <ins> .small-section-header { display: flex; justify-content: space-between; position: relative; } </ins> .small-section-header:hover > .anchor { display: initial; }
Code change:
Yet another soundness bug in Zip's TRA specialization. Line 300 is not called when line 298 panics. This leaves outdated, which results in calling with an invalid index in line 242. Here is a that demonstrates creating two mutable references to the same memory location without unsafe code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How close is this to ?
The same functions are involved but the aspects that interact to cause unsafety are quite different. claim
I agree, this is much closer to .

Related discussion:
text: let sz_a = self.a.size(); if A::MAY_HAVE_SIDE_EFFECT && sz_a > self.len { for _ in 0..sz_a - self.len { <ins> self.a_len -= 1; </ins> self.a.next_back(); } <del> self.a_len = self.len; </del> <ins> debug_assert_eq!(self.a_len, self.len); </ins> } let sz_b = self.b.size(); if B::MAY_HAVE_SIDE_EFFECT && sz_b > self.len {
Code change:
Yet another soundness bug in Zip's TRA specialization. Line 300 is not called when line 298 panics. This leaves outdated, which results in calling with an invalid index in line 242. Here is a that demonstrates creating two mutable references to the same memory location without unsafe code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How close is this to ?
The same functions are involved but the aspects that interact to cause unsafety are quite different. claim
I agree, this is much closer to .

Related discussion:
text: } #[test] <ins> #[cfg(panic = "unwind")] fn test_zip_trusted_random_access_next_back_drop() { use std::panic::catch_unwind; use std::panic::AssertUnwindSafe; let mut counter = 0; let it = [42].iter().map(|e| { let c = counter; counter += 1; if c == 0 { panic!("bomb"); } e }); let it2 = [(); 0].iter(); let mut zip = it.zip(it2); catch_unwind(AssertUnwindSafe(|| { zip.next_back(); })) .unwrap_err(); assert!(zip.next().is_none()); assert_eq!(counter, 1); } #[test] </ins> fn test_double_ended_zip() { let xs = [1, 2, 3, 4, 5, 6]; let ys = [1, 2, 3, 7];
Code change:
Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for

Related discussion:
text: use rustc_span::symbol::{kw, sym, Symbol}; use rustc_span::Span; <del> use crate::clean::{self, Attributes, AttributesExt, FakeDefId, GetDefId, ToSource}; </del> <ins> use crate::clean::{ self, Attributes, AttributesExt, FakeDefId, GetDefId, NestedAttributesExt, ToSource, Type, }; </ins> use crate::core::DocContext; use crate::formats::item_type::ItemType;
Code change:
Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for

Related discussion:
text: if trait_.def_id() == tcx.lang_items().deref_trait() { super::build_deref_target_impls(cx, &trait_items, ret); } <ins> // Return if the trait itself or any types of the generic parameters are doc(hidden). let mut stack: Vec<&Type> = trait_.iter().collect(); stack.push(&for_); while let Some(ty) = stack.pop() { if let Some(did) = ty.def_id() { if cx.tcx.get_attrs(did).lists(sym::doc).has_word(sym::hidden) { return; } } if let Some(generics) = ty.generics() { stack.extend(generics); } } </ins> if let Some(trait_did) = trait_.def_id() { record_extern_trait(cx, trait_did); }
Code change:
Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for

Related discussion:
text: <ins> #[doc(hidden)] pub enum HiddenType {} #[doc(hidden)] pub trait HiddenTrait {} </ins>
Code change:
Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for

Related discussion:
text: <ins> // Issue #86448: test for cross-crate `doc(hidden)` #![crate_name = "foo"] // aux-build:cross-crate-hidden-impl-parameter.rs extern crate cross_crate_hidden_impl_parameter; pub use ::cross_crate_hidden_impl_parameter::{HiddenType, HiddenTrait}; // OK, not re-exported pub enum MyLibType {} // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CHiddenType%3E"]' 'impl From<HiddenType> for MyLibType' impl From<HiddenType> for MyLibType { fn from(it: HiddenType) -> MyLibType { match it {} } } pub struct T<T>(T); // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CT%3CT%3CT%3CT%3CHiddenType%3E%3E%3E%3E%3E"]' 'impl From<T<T<T<T<HiddenType>>>>> for MyLibType' impl From<T<T<T<T<HiddenType>>>>> for MyLibType { fn from(it: T<T<T<T<HiddenType>>>>) -> MyLibType { todo!() } } // @!has foo/enum.MyLibType.html '//*[@id="impl-HiddenTrait"]' 'impl HiddenTrait for MyLibType' impl HiddenTrait for MyLibType {} // @!has foo/struct.T.html '//*[@id="impl-From%3CMyLibType%3E"]' 'impl From<MyLibType> for T<T<T<T<HiddenType>>>>' impl From<MyLibType> for T<T<T<T<HiddenType>>>> { fn from(it: MyLibType) -> T<T<T<T<HiddenType>>>> { match it {} } } </ins>
Code change:
Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for

Related discussion:
text: <ins> // test for `doc(hidden)` with impl parameters in the same crate. #![crate_name = "foo"] #[doc(hidden)] pub enum HiddenType {} #[doc(hidden)] pub trait HiddenTrait {} pub enum MyLibType {} // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CHiddenType%3E"]' 'impl From<HiddenType> for MyLibType' impl From<HiddenType> for MyLibType { fn from(it: HiddenType) -> MyLibType { match it {} } } pub struct T<T>(T); // @!has foo/enum.MyLibType.html '//*[@id="impl-From%3CT%3CT%3CT%3CT%3CHiddenType%3E%3E%3E%3E%3E"]' 'impl From<T<T<T<T<HiddenType>>>>> for MyLibType' impl From<T<T<T<T<HiddenType>>>>> for MyLibType { fn from(it: T<T<T<T<HiddenType>>>>) -> MyLibType { todo!() } } // @!has foo/enum.MyLibType.html '//*[@id="impl-HiddenTrait"]' 'impl HiddenTrait for MyLibType' impl HiddenTrait for MyLibType {} // @!has foo/struct.T.html '//*[@id="impl-From%3CMyLibType%3E"]' 'impl From<MyLibType> for T<T<T<T<HiddenType>>>>' impl From<MyLibType> for T<T<T<T<HiddenType>>>> { fn from(it: MyLibType) -> T<T<T<T<HiddenType>>>> { match it {} } } </ins>