jiebi/CodeConvo huggingface dataset:
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

Related discussion:
text: ] [[package]] <ins> name = "pretty_assertions" version = "1.2.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c89f989ac94207d048d92db058e4f6ec7342b0971fc58d1271ca148b799b3563" dependencies = [ "ansi_term", "ctor", "diff", "output_vt100", ] [[package]] </ins> name = "pretty_env_logger" version = "0.4.0" source = "registry+https://github.com/rust-lang/crates.io-index"
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

Related discussion:
text: checksum = "56dee185309b50d1f11bfedef0fe6d036842e3fb77413abef29f8f8d1c5d4c1c" [[package]] <ins> name = "ui_test" version = "0.1.0" dependencies = [ "colored", "crossbeam", "lazy_static", "pretty_assertions 1.2.1", "regex", "rustc_version", ] [[package]] </ins> name = "unic-char-property" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index"
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

Related discussion:
text: return; } <del> // # Run `cargo test` with `-Zmir-opt-level=4`. cargo.env("MIRIFLAGS", "-O -Zmir-opt-level=4"); if !try_run(builder, &mut cargo) { return; } </del> // # Done! builder.save_toolstate("miri", ToolState::TestPass); } else {
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

Related discussion:
text: <del> Subproject commit 22c97b33e470d0b7c085e98417bef8b362d43d4e </del> <ins> Subproject commit 065ff89e33b67b3527fcdd56cf8b432e593e32d4 </ins>
Code change:
See https://crater- This is a 1.62 regression, it seems, based on Crater. At the very least, it's a diagnostics issue that we're suggesting adding an already existing lifetime bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-04-01 to nightly-2022-05-31 regressed nightly: nightly-2022-05-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details, cc
The issue is that bound is causing the new wf check introduced in to fail. Regarding the diagnostics being weird, the issue is probably because we don't handle the case where a higher-ranked lifetime doesn't outlive itself. We just see a borrowck error, see that it's due to the binder's lifetime, and suggest adding it. Not sure if that needs fixed, personally think it's not worth it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
This got fixed on nightly by enabling nll by default
claim For the test

Related discussion:
text: <ins> // check-pass #[allow(unused)] fn test<T, F, U>(f: F) -> Box<dyn Fn(T) -> U + 'static> where F: 'static + Fn(T) -> U, for<'a> U: 'a, // < This is the problematic line, see #97607 { Box::new(move |t| f(t)) } fn main() {} </ins>
Code change:
Building a simple fuzz target using --cfg fuzzing -Cpasses=sancov-module -Cllvm-args=-sanitizer-coverage-level=4 -Cllvm-args=-sanitizer-coverage-inline-8bit-counters results in a linker error: {symbol} referenced in section {section} at {rcgu}: defined in discarded section {other section} of {other rcgu}. One possible workaround is to set -Ccodegen-units=1 (any higher value triggers the error). Alternatively, -Znew-llvm-pass-manager=no and -Cpasses=sancov (instead of -Cpasses=sancov-module) will also result in a successful build. Repro steps: : Note: The same error also occurs with rustc 1.61.0 (stable channel). : Note: GNU ld is the default linker on this system. On another system where the linker is LLD, a similar error occurs, the message is just worded a bit differently.
We somehow end up running sancov-module on an input that already has defined. For the example IR below, the following happens: We generate a new which has a numeric suffix (".19" in the error message above). This is part of the $sancov.modulector8bitcounters (no suffix) comdat. The suffixed is to which already mentions and the original (no suffix). The .initarray.2 that is generated from is mentioned in two comdat groups: f and sancov.modulector8bitcounters. If we subsequently link this object with another object which also has a sancov.modulector8bitcounters comdat group, the linker will preserve only one of the sancov.modulector8bitcounters comdat groups. The error message shown earlier happens when the linker discards the comdat group that contains but keeps the .initarray.2 that references that symbol. It can do this because that .initarray.2 is also mentioned in comdat group f. LLVM IR before sancov-module: Some relevant sections of the IR after : After machine code generation, : There is an assert in CreateInitCallsForSections: This assert will trigger when is created. Of course, that only happens in LLVM builds with asserts enabled. What I don't yet know is why the sancov-module pass is being run on a module it has already been run for. I can see the multiple runs in the output if I pass in -Cllvm-args=-print-before-all, one of which creates the suffixed function, but I do not know what causes the pass to be run multiple times on the same module.
Passes configured with should probably be included only in pre-link optimization stage in: Similarly to sanitizer passes configured a few lines earlier: Otherwise they will be executed multiple times with LTO (a thin local LTO is enabled by default when using multiple codegen units).
Thank you. I was thinking along the same lines. I have a patch that does this, which I will send for review once I've tested it. I am wondering if there is value in also being able to specify passes specifically for the LTO stage; perhaps with a new -Zlink-passes flag. What do you think?

Related discussion:
text: let llvm_selfprofiler = llvm_profiler.as_mut().map(|s| s as *mut _ as *mut c_void).unwrap_or(std::ptr::null_mut()); <del> let extra_passes = config.passes.join(","); </del> <ins> let extra_passes = if !is_lto { config.passes.join(",") } else { "".to_string() }; </ins> let llvm_plugins = config.llvm_plugins.join(",");
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: I expected the compiler to let me know that function signature was wrong with the Result<, B`. Once I changed this, it compiled fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I've come up a solution with which the output of this test case will be like the following: It is cumbersome for still having E0391 printed, but it seems not easy to remove this without a significant code changes. I think the first message E0121 "the placeholder is not allowed within types on item signatures for return types" should have told the user enough information how to fix the problem. Any comments/suggestions?
having an early return for when there's no generics on will solve this problem.
Thanks a lot for the advise! After the following code change, the faulty message has gone way, and correct output generated.
The output of the test case after the fix is correct:
great, now you can send a pull request :).
Thanks for your work

Related discussion:
text: } fn variances_of(tcx: TyCtxt<'_>, item_def_id: DefId) -> &[ty::Variance] { <ins> // Skip items with no generics - there's nothing to infer in them. if tcx.generics_of(item_def_id).count() == 0 { return &[]; } </ins> match tcx.def_kind(item_def_id) { DefKind::Fn | DefKind::AssocFn
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: I expected the compiler to let me know that function signature was wrong with the Result<, B`. Once I changed this, it compiled fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I've come up a solution with which the output of this test case will be like the following: It is cumbersome for still having E0391 printed, but it seems not easy to remove this without a significant code changes. I think the first message E0121 "the placeholder is not allowed within types on item signatures for return types" should have told the user enough information how to fix the problem. Any comments/suggestions?
having an early return for when there's no generics on will solve this problem.
Thanks a lot for the advise! After the following code change, the faulty message has gone way, and correct output generated.
The output of the test case after the fix is correct:
great, now you can send a pull request :).
Thanks for your work

Related discussion:
text: <ins> fn main() {} trait A { fn a(aa: B) -> Result<_, B> { //~^ ERROR: the placeholder `_` is not allowed within types on item signatures for return types [E0121] Ok(()) } } enum B {} </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: I expected the compiler to let me know that function signature was wrong with the Result<, B`. Once I changed this, it compiled fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I've come up a solution with which the output of this test case will be like the following: It is cumbersome for still having E0391 printed, but it seems not easy to remove this without a significant code changes. I think the first message E0121 "the placeholder is not allowed within types on item signatures for return types" should have told the user enough information how to fix the problem. Any comments/suggestions?
having an early return for when there's no generics on will solve this problem.
Thanks a lot for the advise! After the following code change, the faulty message has gone way, and correct output generated.
The output of the test case after the fix is correct:
great, now you can send a pull request :).
Thanks for your work

Related discussion:
text: <ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/issue-98260.rs:3:27 | LL |     fn a(aa: B) -> Result<_, B> { |                    -------^---- |                    |      | |                    |      not allowed in type signatures |                    help: replace with the correct return type: `Result<(), B>` error: aborting due to previous error For more information about this error, try `rustc --explain E0121`. </ins>
Code change:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.

Related discussion:
text: Self::with_capacity_in(capacity, Global) } <del> /// Creates a `Vec<T>` directly from the raw components of another vector. </del> <ins> /// Creates a `Vec<T>` directly from a pointer, a capacity, and a length. </ins> /// /// # Safety /// /// This is highly unsafe, due to the number of invariants that aren't /// checked: /// <del> /// * `ptr` needs to have been previously allocated via [`String`]/`Vec<T>` ///   (at least, it's highly likely to be incorrect if it wasn't). </del> /// * `T` needs to have the same alignment as what `ptr` was allocated with. ///   (`T` having a less strict alignment is not sufficient, the alignment really ///   needs to be equal to satisfy the [`dealloc`] requirement that memory must be
Code change:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.

Related discussion:
text: ///   to be the same size as the pointer was allocated with. (Because similar to ///   alignment, [`dealloc`] must be called with the same layout `size`.) /// * `length` needs to be less than or equal to `capacity`. <ins> /// * The first `length` values must be properly initialized values of type `T`. /// * `capacity` needs to be the capacity that the pointer was allocated with. /// * The allocated size in bytes must be no larger than `isize::MAX`. ///   See the safety documentation of [`pointer::offset`]. /// /// These requirements are always upheld by any `ptr` that has been allocated /// via `Vec<T>`. Other allocation sources are allowed if the invariants are /// upheld. </ins> /// /// Violating these may cause problems like corrupting the allocator's /// internal data structures. For example it is normally **not** safe
Code change:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.

Related discussion:
text: ///     assert_eq!(rebuilt, [4, 5, 6]); /// } /// ``` <ins> /// /// Using memory that was allocated elsewhere: /// /// ```rust /// #![feature(allocator_api)] /// /// use std::alloc::{AllocError, Allocator, Global, Layout}; /// /// fn main() { ///     let layout = Layout::array::<u32>(16).expect("overflow cannot happen"); /// ///     let vec = unsafe { ///         let mem = match Global.allocate(layout) { ///             Ok(mem) => mem.cast::<u32>().as_ptr(), ///             Err(AllocError) => return, ///         }; /// ///         mem.write(1_000_000); /// ///         Vec::from_raw_parts_in(mem, 1, 16, Global) ///     }; /// ///     assert_eq!(vec, &[1_000_000]); ///     assert_eq!(vec.capacity(), 16); /// } /// ``` </ins> #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub unsafe fn from_raw_parts(ptr: *mut T, length: usize, capacity: usize) -> Self {
Code change:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.

Related discussion:
text: /// /// [`String`]: crate::string::String /// [`dealloc`]: crate::alloc::GlobalAlloc::dealloc <ins> /// [*fit*]: crate::alloc::Allocator#memory-fitting </ins> /// /// # Examples ///