jiebi/CodeConvo huggingface dataset:
Change:
/// Checks whether the regions of memory starting at `src` and `dst` of size /// `count * size_of::<T>()` overlap. <ins> #[cfg(not(miri))] // Cannot compare with `>` across allocations in Miri </ins> fn overlaps<T>(src: *const T, dst: *const T, count: usize) -> bool { let src_usize = src as usize; let dst_usize = dst as usize;

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Change:
<ins> // compile-flags:--test // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // normalize-stdout-test "finished in d+.d+s" -> "finished in $$TIME" // check-pass /// ``` /// # #![cfg_attr(not(dox), deny(missing_abi, /// # non_ascii_idents))] /// /// pub struct Bar; /// ``` pub struct Bar; </ins>

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
} let mut restrict_type_params = false; <ins> let mut unsatisfied_bounds = false; </ins> if !unsatisfied_predicates.is_empty() { let def_span = |def_id| { self.tcx.sess.source_map().guess_head_span(self.tcx.def_span(def_id))

Discussion:
Given the following code (): The output on is: <details<summaryLong diagnostic</summary</details, , , and are suggested three times each: once for , once for , and once for . I'm not sure if this is a problem, but this seems incredibly verbose to me. Note that the output on stable 1.51 and beta 1.52 is different:
My mistake, each repetition is actually different in that two suggest taking a reference to : This still seems like a fairly massive diagnostic, though. I've updated the original post in light of this. Feel free to close if a diagnostic of this size is fine here.
cc
Might be a duplicate of , or at least fixed by the same PR that fixed it
Even if it was considered reasonable to suggest each and every possible type combination, there is no pressing reason for it to generate the intervening lines as well: rustc is a compiler, not a can of spam. This remains unpatched on nightly, and is thus a stable-to-beta diagnostic regression.
AFAICT, this is not present on beta, and is only present on nightly, so it's a stable-to-nightly regression. Please correct me if I misunderstood!
searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-09 searched commits: from to regressed commit: That is: so it’s . I guess has already been mentioned. label D-verbose
Yes, yes, I introduced this regression. Mea culpa, everybody. In my defense I keep flip-flopping between being too restrictive and too permissive for new suggestions and someone always ends up getting the short end of the stick. This week, I'm leaning towards "too permissive" and if the suggestion triggers too often, then detect the cases and make it more constrained, because the alternative is that the suggestion isn't shown when it could, and we'll never find out. This is IMO better, as long as regressions are caught in nightly, like it was in this case.&lt;/rantAnyways, fixes this.
Assigning and removing .
This now affects 1.53.0 beta. Updating the labels accordingly.
Still needs to be backported.
the beta backport for patch was approved, can this now be closed?

I think we should wait until it actually lands onto beta
This was merged in beta already, right?
Ah, so it was.
Change:
} (VarValue::Value(a), VarValue::Empty(_)) => { match *a { <del> ReLateBound(..) | ReErased | ReError(_) => { </del> <ins> // this is always on an error path, // so it doesn't really matter if it's shorter or longer than an empty region ReError(_) => false, ReLateBound(..) | ReErased => { </ins> bug!("cannot relate region: {:?}", a); }

Discussion:
<!-- 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 --
claim
are you working on this?
yes
Change:
// ignore-cloudabi spawning processes is not supported // ignore-emscripten spawning processes is not supported // ignore-openbsd no support for libbacktrace without filename <ins> // ignore-msvc issue #62844 </ins> // ignore-sgx no processes // compile-flags:-g

Discussion:
With the change in function shouldrunsuccessfully() of commit : RunPass =true, Ui == Some(PassMode::Run), RunPass | Ui =self.effectivepass_mode() == Some(PassMode::Run), The test cases under run-pass directory are tested for building only, the compiled test cases are not running any more. Does it work as design?
Oh. This is bad. Will fix today. cc (on vacation)
Fixed in
Change:
// The implementations of sift_up and sift_down use unsafe blocks in // order to move an element out of the vector (leaving behind a <del> // zeroed element), shift along the others and move it back into the // vector over the junk element. This reduces the constant factor // compared to using swaps, which involves twice as many moves. fn sift_up(&mut self, start: usize, mut pos: usize) { </del> <ins> // hole), shift along the others and move the removed element back into the // vector at the final location of the hole. // The `Hole` type is used to represent this, and make sure // the hole is filled back at the end of its scope, even on panic. // Using a hole reduces the constant factor compared to using swaps, // which involves twice as many moves. fn sift_up(&mut self, start: usize, pos: usize) { </ins> unsafe { <del> let new = replace(&mut self.data[pos], zeroed()); </del> <ins> // Take out the value at `pos` and create a hole. let mut hole = Hole::new(&mut self.data, pos); </ins> <del> while pos > start { let parent = (pos - 1) >> 1; if new <= self.data[parent] { break; } let x = replace(&mut self.data[parent], zeroed()); ptr::write(&mut self.data[pos], x); pos = parent; </del> <ins> while hole.pos() > start { let parent = (hole.pos() - 1) / 2; if hole.removed() <= hole.get(parent) { break } hole.move_to(parent); </ins> } <del> ptr::write(&mut self.data[pos], new); </del> } } fn sift_down_range(&mut self, mut pos: usize, end: usize) { <ins> let start = pos; </ins> unsafe { <del> let start = pos; let new = replace(&mut self.data[pos], zeroed()); </del> <ins> let mut hole = Hole::new(&mut self.data, pos); </ins> let mut child = 2 * pos + 1; while child < end { let right = child + 1; <del> if right < end && !(self.data[child] > self.data[right]) { </del> <ins> if right < end && !(hole.get(child) > hole.get(right)) { </ins> child = right; } <del> let x = replace(&mut self.data[child], zeroed()); ptr::write(&mut self.data[pos], x); pos = child; child = 2 * pos + 1; </del> <ins> hole.move_to(child); child = 2 * hole.pos() + 1; </ins> } <del> ptr::write(&mut self.data[pos], new); self.sift_up(start, pos); </del> <ins> pos = hole.pos; </ins> } <ins> self.sift_up(start, pos); </ins> } fn sift_down(&mut self, pos: usize) {

Discussion:
BinaryHeap is using and may not be exception safe. I.e. it is in an inconsistent state after being recovered after panic. See issue and others. Relevant code is cc
My immediate ideas are one of Use PPYP and set vector length to zero temporarily. Panicing in comparison functions will leak all elements in the heap Use more swaps
got the idea:
Long ago I suggested two other strategies: A two-pass phase where you do all comparisons first, then once you've found the Final Destination you actually do the swaps (which requires no untrusted code to run). A panic guard which on drop puts the "working" element back in the "uninit" location in the array
triage: I-nominated, T-libs
I'm trying gankro's panic guard idea.
Change:
//! unit-tested and separated from the Rust source and compiler data //! structures. <del> use rustc::mir::repr::{BinOp, BorrowKind, Field, Literal, Mutability, UnOp, ItemKind}; </del> <ins> use rustc::mir::repr::{BinOp, BorrowKind, Field, Literal, Mutability, UnOp, ItemKind, TypedConstVal}; </ins> use rustc::middle::const_eval::ConstVal; use rustc::middle::def_id::DefId; use rustc::middle::region::CodeExtent;

Discussion:
See and relevant FIXME in
As a side-note, would solve this problem quite neatly, if we were to adopt and implement it. :)
Change:
<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #[macro_export] macro_rules! foo { () => () } #[macro_export] macro_rules! bar { () => () } </ins>

Discussion:
Migrated from It's been mentioned/requested multiple times on the that should remove the statements when moving to Rust 2018. One of the big draws of Rust 2018's module system is that all of the "redundant" lines can finally be removed. It took some of the excitement away when I went through all of the steps and still saw them there. I think it will just be a better experience for users to see one of the tangible benefits of this change. As it is right now, they just see the in front of all of their local imports and they might not realize what a nice change the module system updates really are. After I manually removed the 's I did get my satisfying result , but let's give this to users on the first go around. If I understand correctly this should be implemented in the compiler under the lints, rather than itself. cc
I'm moving this forward up on the milestone list due to just having closed in favor of this issue, which was itself on the RC milestone.
Ok so I've some triaging of related lint issues, and I believe the current work items are: A rustfix-fixable suggestion for removing needs to be implemented. The implementation would . Currently the lint suggests switching to simply . While technically correct and handles lots of corner cases, this doesn't achieve the desired goal of actually removing annotations. We can't blanket remove all statements, for example is correctly warned to use a rather than deleting the statement outright. I'm testing out some ideas locally as well.
I believe this should be fixed by , I think the naive solution actually works well!
Change:
<ins> error[E0764]: mutable references are not allowed in the final value of constants --> $DIR/issue-76510.rs:5:29 | LL | const S: &'static mut str = &mut " hello "; |                             ^^^^^^^^^^^^^^ error[E0658]: mutation through a reference is not allowed in constants --> $DIR/issue-76510.rs:5:29 | LL | const S: &'static mut str = &mut " hello "; |                             ^^^^^^^^^^^^^^ | = note: see issue #57349 <https://github.com/rust-lang/rust/issues/57349> for more information = help: add `#![feature(const_mut_refs)]` to the crate attributes to enable error[E0596]: cannot borrow data in a `&` reference as mutable --> $DIR/issue-76510.rs:5:29 | LL | const S: &'static mut str = &mut " hello "; |                             ^^^^^^^^^^^^^^ cannot borrow as mutable error[E0080]: it is undefined behavior to use this value --> $DIR/issue-76510.rs:5:1 | LL | const S: &'static mut str = &mut " hello "; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered mutable reference in a `const` | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. = note: the raw bytes of the constant (size: 16, align: 8) { ╾───────alloc2────────╼ 07 00 00 00 00 00 00 00 │ ╾──────╼........ } error: aborting due to 4 previous errors Some errors have detailed explanations: E0080, E0596, E0658, E0764. For more information about an error, try `rustc --explain E0080`. </ins>

Discussion:
<!-- 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
A slightly more minimal example that does not use unsafe:
This bug was introduced in 1.46. Rustc 1.45.2 rightfully rejects the code, 37 - 1.44 ICEs with
Run cargo bisect on this: regression in Given that the panic is in , the likely culprit is PR because of the changes to
No longer ICEs since
Change:
<ins> // Regression test for #87414. // check-pass // compile-flags: -Zthir-unsafeck fn bad<T>() -> Box<dyn Iterator<Item = [(); { |x: u32| { x }; 4 }]>> { todo!() } fn foo() -> [(); { |x: u32| { x }; 4 }] { todo!() } fn bar() { let _: [(); { |x: u32| { x }; 4 }]; } // This one should not cause any errors either: unsafe fn unsf() {} fn bad2<T>() -> Box<dyn Iterator<Item = [(); { unsafe { || { unsf() } }; 4 }]>> { todo!() } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code with : I expected to see this happen: It compiles, as it does under the MIR checker Instead, this happened: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Reduced (either of the following two functions reproduces the issue): This is caused by the fact that closures are handled by their owner: claim
Change:
impl1_trait_ref, ) { Ok(impl1_trait_ref) => impl1_trait_ref, <del> Err(err) => { bug!("failed to fully normalize {:?}: {:?}", impl1_trait_ref, err); </del> <ins> Err(_errors) => { tcx.sess.delay_span_bug( tcx.def_span(impl1_def_id), format!("failed to fully normalize {impl1_trait_ref}"), ); impl1_trait_ref </ins> } };

Discussion:
The following code () produces
Triage: still ICEs
This ICEs since modify labels: +regression-from-stable-to-stable
Change:
use crate::cell::UnsafeCell; use crate::mem::MaybeUninit; <ins> use crate::sys::cvt_nz; </ins> pub struct Mutex { inner: UnsafeCell<libc::pthread_mutex_t>,

Discussion:
In libstd/sys/unix there are numerous cases where return code is checked for error using following pattern: That means, that error checking is performed only when compiled in non-optimized mode or after explicitly enabling debug assertions. This is a little bit worrying, especially when used on platforms where those functions can indeed fail and break safety.
(For anyone who was confused by the given example, pthreadmutexattrinit can fail with ENOMEM.)
On some platforms types like pthreadmutext, pthreadcondt, etc., are "fat" structures that have sufficient size to hold everything necessary and their initialization will never fail (unless initialized incorrectly). But on others they are opaque pointers to and require an additional memory allocation. Search for those typedefs in libc crate, gives a rough approximation of affected platforms. Sadly this also affects static mutexes, so even lock / unlock could potentially fail. Either way you could end up with a mutex which is not mutually exclusive at all.
When mutex initialization fails this leads to non-functioning mutex and unsoundness. The pthreadmutexlock might also fail for recursive mutexes used in std::io and cause a mismatch in the number of locks / unlocks, but one needs to go out of the way to cause that. modify labels: C-bug I-unsound
Change:
<ins> trait Trait<const N: usize> { const Assoc: usize; } impl<const N: usize> Trait<N> for () { const Assoc: usize = 1; } pub const fn foo<const N: usize>() where (): Trait<N> { let bar = [(); <()>::Assoc]; //~^ error: constant expression depends on a generic parameter } trait Trait2<const N: usize> { const Assoc2: usize; } impl<const N: usize> Trait2<N> for () { const Assoc2: usize = N - 1; } pub const fn foo2<const N: usize>() where (): Trait2<N> { let bar2 = [(); <()>::Assoc2]; //~^ error: constant expression depends on a generic parameter } fn main() { foo::<0>(); foo2::<0>(); } </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering the error <!-- 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
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
//    | //    = note: cannot satisfy `_: Tt` <ins> // Clear any more general suggestions in favor of our specific one err.clear_suggestions(); </ins> err.span_suggestion_verbose( span.shrink_to_hi(), &format!(

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
fn visit_operand(&mut self, operand: &Operand<'tcx>, location: Location) { match *operand { <del> Operand::Copy(ref place) | Operand::Move(ref place) => { </del> <ins> Operand::Copy(_) | Operand::Move(_) => { </ins> self.nest(|this| { this.super_operand(operand, location); this.try_consume(); }); // Mark the consumed locals to indicate later drops are noops. <del> if let Place::Local(local) = *place { self.local_needs_drop[local] = None; </del> <ins> if let Operand::Move(Place::Local(local)) = *operand { self.temp_qualif[local] = self.temp_qualif[local].map(|q| q - Qualif::NEEDS_DROP ); </ins> } } Operand::Constant(ref constant) => {

Discussion:
These currently compile, even if they can be used from compile-time code to trigger a drop: cc
Change:
}, } <ins> #[derive(Debug)] </ins> enum ModuleKind { /// An anonymous module; e.g., just a block. ///

Discussion:
Test example (): Only in the top level should say "cannot construct ... due to inaccessible fields", the other 3 errors should be "missing field ... in initializer", but it seems like it's treating the field as private (even though it inherits from the ). The "cannot construct ... due to inaccessible fields" error seems to be new in 1.48, as part of , and unmodified since. It's using which seems correct, but it's possible fields are incapable of giving the right result, if they don't track the 's own privacy (and they only know they inherit it, whatever it is). cc
I would also suspect
I ran into this too, but I couldn't make a repro. Thanks eddyb!
P-high: I've run into this a bunch of times and I imagine others have too. It's really annoying and confusing, likely even more so for newcomers!
searched nightlies: from nightly-2020-08-01 to nightly-2020-10-15 regressed nightly: nightly-2020-09-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Seems very likely that this is due to , as eddyb said. EDIT: Though, as jyn514 suggested, the underlying bug could be , which was then surfaced in .
Update: I've been reading the source code and print-debugging and I think the issue was not introduced in either of those two PRs, but rather that they surfaced a pre-existing issue.
Well, it took a while, but I think I fixed it!
Does this necessitate a 1.48.1 release or shall I wait for 1.49?
it will be in 1.50 unless backported:
Ok. Thank you for the quick reply.
Change:
| LL | fn foo<T, K, W: Default, Z: Default>(t: T, k: K) -> Foo<T, K, W, Z> { |                 ^^^^^^^ required by this bound in `foo` <del> help: consider giving `foo` an explicit type, where the type for type parameter `W` is specified | LL |     let foo: Foo<i32, &str, W, Z> = foo(1, ""); |            ++++++++++++++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     let foo = foo::<T, K, W, Z>(1, "");

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim