jiebi/CodeConvo huggingface dataset:
Change:
// make sure that the thing we are pointing out stays valid // for the lifetime `scope_r` of the resulting ptr: <del> let scope_r = ty_region(tcx, ex.span, ty::expr_ty(tcx, ex)); this.guarantee_valid(ex.id, ex.span, base_cmt, LoanMutability::from_ast_mutability(mutbl), scope_r); </del> <ins> let expr_ty = ty::expr_ty(tcx, ex); if !ty::type_is_bot(expr_ty) { let scope_r = ty_region(tcx, ex.span, expr_ty); this.guarantee_valid(ex.id, ex.span, base_cmt, LoanMutability::from_ast_mutability(mutbl), scope_r); } </ins> visit::walk_expr(this, ex, ()); }

Discussion:
(updated test case for bug) The following test inputs: or, more elaborately: yields the ICE failure: (original bug test case follows)
This may or may not be the same failure as which fails with .
Visited for triage. Was able to reproduce. Nominating for "maturity number 5 - production ready".
accepted for production-ready milestone
just a bug, removing milestone/nomination.
Both the smaller and the bigger versions still ICE as of
Change:
C_int(ccx, 0) // Placeholder for when not using a switch }; <del> let defaults = enter_default(else_cx, dm, m, col, val); </del> <ins> let defaults = enter_default(else_cx, dm, m, col, val, chk); </ins> let exhaustive = chk.is_none() && defaults.len() == 0u; let len = opts.len();

Discussion:
This should print , but prints . The problem seems to be the pattern, since if this is replaced by aokok_` is not important.)
Confirmed. Bugs where we actually generate the wrong code are pretty bad, so fixing this is probably decently high priority. Not sure it actually fits for a milestone, though?
OK, I've figured out what is going on. The problem is that the matcher is too strict when deciding what patterns are included in some condition. Essentially the problem is that it decides that the condition that are relevant are "length 1" and "length 0" and decides that [2, .. ] is the only pattern that matches "length 1", which is obviously bogus. Fixing this seems a bit tricky, since we need to be able to properly expand out the patterns while still properly handling bindings. Note that this seems like a degenerate case, since the last pattern could just be replaced with a , but there are more complicated and interesting things where this happens too.
Oh, no, there is a pretty simple solution to this. The trick is, when checking submatches generated by a vector length check, set it up so that if none of the subpatterns match, it goes to the next vector length check. I'm explaining it poorly, but it is a really simple fix.
Simple fix has problems, though. So have a more complex fix. Which also has problems. Still investigating.
OK, have it all fixed. Just trying to document it well at this point.
Change:
def bootstrap(): parser = argparse.ArgumentParser(description='Build rust') parser.add_argument('--config') <ins> parser.add_argument('--build') </ins> parser.add_argument('--clean', action='store_true') parser.add_argument('-v', '--verbose', action='store_true')

Discussion:
I tried to build a different ABI/triplet than the one rustbuild automatically guesses by using the command line option. As suggested in , But it didn't work and failed with: Setting "build" in works correctly. The script is responsible for downloading the stage0 compiler and building bootstrap (rustbuild), but it only checks which stage0 to download and use in It doesn't look at the command line at all for deciding this, which I think is the cause for this. See: .
Change:
<ins> use crate::sys::pipe::{anon_pipe, Pipes}; use crate::{thread, time}; /// Test the synchronous fallback for overlapped I/O. #[test] fn overlapped_handle_fallback() { // Create some pipes. `ours` will be asynchronous. let Pipes { ours, theirs } = anon_pipe(true, false).unwrap(); let async_readable = ours.into_handle(); let sync_writeable = theirs.into_handle(); thread::scope(|_| { thread::sleep(time::Duration::from_millis(100)); sync_writeable.write(b"hello world!").unwrap(); }); // The pipe buffer starts empty so reading won't complete synchronously unless // our fallback path works. let mut buffer = [0u8; 1024]; async_readable.read(&mut buffer).unwrap(); } </ins>

Discussion:
on windows. with and rename it back to git bash I expected to see this happen: my really long string gets printed twice, followed by a clean exit Instead, this happened: some amount of my really long string gets printed, followed by: The test case, while simple, does appear to have a minimum size requirement to trigger this crash. Shrinking the string will cause it to stop crashing. I'm using in the steps for simplicity, but we've observed this happening with other programs at the end of the pipe too. Redirecting to a file instead of a pipe seems to not trigger this crash. Using is not necessary to trigger the crash, running the built executable directly also crashes. This PR this new error condition: I am not the only one seeing this new error message: modify labels: +regression-from-stable-to-stable +O-windows
I believe this must be because git bash (cygwin? msys?) is opening pipes between processes with . In my original bug report, I suggested calling once if returned , since that will at least resolve the pending IO correctly in the case where the file is not being used for other IOs concurrently. This would cover this and other cases at least as well as the original code calling . This isn't perfect, since of course takes , so you can probably deadlock in a multi-threaded process in this async pipe configuration. But it would at least avoid the common case. However, it seems that this got missed from the actual change (sorry, I should have caught that). Is there a reason this was skipped?
Oh, hrm. That looks like an oversight on my part. I'll PR a fix asap.
Thanks for fixing the issue quickly. When the PR that fixes this issue is merged, will a patch release 1.62.1 be published? Or will we have to wait for a fix in 1.63?
PR was nominated and accepted for both beta and stable backport by T-libs. Leaving this open until those play out. Assigning P-high for the same reasons it was accepted for backports.
Change:
kind: mir::BorrowKind, borrowed_place: &mir::Place<'tcx>, ) -> bool { <del> let borrowed_ty = borrowed_place.ty(self.body, self.tcx).ty; // Zero-sized types cannot be mutated, since there is nothing inside to mutate. // // FIXME: For now, we only exempt arrays of length zero. We need to carefully // consider the effects before extending this to all ZSTs. if let ty::Array(_, len) = borrowed_ty.kind { if len.try_eval_usize(self.tcx, self.param_env) == Some(0) { return false; } } </del> match kind { mir::BorrowKind::Mut { .. } => true, | mir::BorrowKind::Shared | mir::BorrowKind::Shallow | mir::BorrowKind::Unique <del> => !borrowed_ty.is_freeze(self.tcx, self.param_env, DUMMY_SP), </del> <ins> => !borrowed_place .ty(self.body, self.tcx) .ty .is_freeze(self.tcx, self.param_env, DUMMY_SP), </ins> } } }

Discussion:
The following ICE's on nightly only: <details<summaryBacktrace:</summary</detailsThis ICE is the same as reported in , however the example given there currently runs fine without any errors.
cc
As the OP notes, this is closely related to . To fix that problem, zero-length arrays were special-cased so that they are never marked as indirectly mutable. However, this did not extend to projections of zero-length arrays. When compiling this code, the analysis sees a reference being taken to a place of type , which it cannot assume is . I should be able to make the validation passes agree in this particular case by checking the type of the target of each projection along the borrowed place, suppressing the indirectly mutable annotation for the base local if any of those types are a zero-sized array. It's unfortunate that we have to treat and differently here, but obviously backwards compatibility must be preserved. I wonder if there's a different way to handle this. It seems like should return for an empty array?
Change:
// With custom DSTS, this *will* execute user-defined code, but the same // happens at run-time so that's okay. match self.size_and_align_of(&base_meta, &field_layout)? { <del> Some((_, align)) => (base_meta, offset.align_to(align)), </del> <ins> Some((_, align)) => { // For packed types, we need to cap alignment. let align = if let ty::Adt(def, _) = base.layout().ty.kind() && let Some(packed) = def.repr().pack { align.min(packed) } else { align }; (base_meta, offset.align_to(align)) } </ins> None => { // For unsized types with an extern type tail we perform no adjustments. // NOTE: keep this in sync with `PlaceRef::project_field` in the codegen backend.

Discussion:
This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip
Change:
fluent_messages! { "../messages.ftl" } <ins> #[derive(Debug)] </ins> enum Weak { Yes, No,

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
searched nightlies: from nightly-2023-02-10 to nightly-2023-03-18 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: cc
Could you assign it to me, I am willing to try to solve the problem
Change:
/// `failure` describes the required ordering for the load operation that takes place when /// the comparison fails. Using [`Acquire`] as success ordering makes the store part /// of this operation [`Relaxed`], and using [`Release`] makes the successful load <del> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`] /// and must be equivalent to or weaker than the success ordering. </del> <ins> /// [`Relaxed`]. The failure ordering can only be [`SeqCst`], [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note:** This method is only available on platforms that support atomic /// operations on pointers.

Discussion:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.
Change:
impl<'a, 'b, 'tcx, O:DataFlowOperator> PropagationContext<'a, 'b, 'tcx, O> { fn walk_cfg(&mut self, cfg: &cfg::CFG, <ins> nodes_po: &[CFGIndex], </ins> in_out: &mut [usize]) { debug!("DataFlowContext::walk_cfg(in_out={}) {}", bits_to_string(in_out), self.dfcx.analysis_name); assert!(self.dfcx.bits_per_id > 0); <del> cfg.graph.each_node(|node_index, node| { </del> <ins> // Iterate over nodes in reverse postorder for &node_index in nodes_po.iter().rev() { let node = cfg.graph.node(node_index); </ins> debug!("DataFlowContext::walk_cfg idx={:?} id={} begin in_out={}", node_index, node.data.id(), bits_to_string(in_out));

Discussion:
See . Here is a chart giving time output from with of the lines of the form uncommented. n -------- With this gist I've tried to create a fairly minimal example. It's not as minimal as maybe it could be because it's a little tricky to figure out what's causing the slow compiles and I've spent as much time as I can on this right now. It's very sensitive to seemingly irrelevant changes in the code. If I remove the unused variable, compile times dramatically improve. If I remove the empty loop, compile times dramatically improve. On my actual project, I am getting compile times in excess of 20 minutes. To compile a few thousand lines of code.
cc
Umm this is not an expansion problem but rather a borrowck problem - dataflow somehow takes O(n) iterations to converge.
Change:
<ins> struct Struct { y: (typeof("hey"),), //~^ `typeof` is a reserved keyword but unimplemented } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc :smile:
This really should fail before rustdoc gets to it, unless rustdoc has a representation :thinking:
An (the?) interesting bit here is that it's a very recent regression, for instance does not produce an ICE:
claim
This regressed in cc
Hmm I don't know how that caused it.
Change:
#![feature(associated_type_bounds)] #![feature(rustc_attrs)] #![feature(control_flow_enum)] <del> #![cfg_attr(not(bootstrap), feature(trait_upcasting))] </del> <ins> #![feature(trait_upcasting)] </ins> #![feature(try_blocks)] #![feature(decl_macro)] #![feature(extract_if)]

Discussion:
hello everyone, I got this error when I bootstrap the current rust-beta branch: There was a lot of pushing and reverting changesets relevant to the c literals stabilization, I tried to get an overview of what backport might be missing here, but I failed and am at a loss. I am on linux x86_64, with musl as my libc, I doubt the later is causing the issues.
What are you using as your bootstrap compiler? We only support using the previous release.
I think I understand what is going on. If you try to bootstrap 1.77 from 1.76, it will fail. We were intending to have c-string literals stabilized in 1.76, but that got reverted. However, the revert did not include the appropriate parts of I can probably put something together to fix it.
Posted with a fix.
Change:
/// /// assert!(ecode.success()); /// ``` <ins> /// /// # Note /// /// Take note that there is no implementation of /// [`Drop`](../../core/ops/trait.Drop.html) for child processes, so if you /// do not ensure the `Child` has exited then it will continue to run, even /// after the `Child` handle to the child process has gone out of scope. /// /// Calling `wait` (or other functions that wrap around it) will make the /// parent process wait until the child has actually exited before continuing. </ins> #[stable(feature = "process", since = "1.0.0")] pub struct Child { handle: imp::Process,

Discussion:
It would be nice, if the would mention that the process is detached (and not joined) by default, when a object goes out of scope. Not having a impl is too subtile IMO.
Part of
I'd be happy to take this on. :smile:
Please do! :) On Jan 30, 2016, 11:59 -0500, Dirk , wrote:
Change:
F: FnMut(&T, &T) -> bool, { let len = v.len(); <del> // SAFETY: The unsafe operations below involves indexing without a bound check (`get_unchecked` and `get_unchecked_mut`) // and copying memory (`ptr::copy_nonoverlapping`). </del> <ins> // SAFETY: The unsafe operations below involves indexing without a bounds check (by offsetting a // pointer) and copying memory (`ptr::copy_nonoverlapping`). </ins> // // a. Indexing: //  1. We checked the size of the array to >=2.

Discussion:
Similar to I tried this code: I expected to see this happen: Miri does not detect UB Instead, this happened: Miri detects UB (experimentally) <!-- 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<summaryBacktrace</summary<p</p</details
cc
FWIW, I have now detected this bug through the tests in and .
Looks like the problem is in this line: re-borrows an on the entire slice, thus invalidation previously created pointers. So this is yet another instance of
Actually, just to be sure, are we interested in patching out all such instances of this in std/alloc/core? I know I personally would like the standard library to be clean against Miri with so that I can check libraries for stacked borrows issues. I just did a quick skim now that I understand the rules and I think I can spot a few other issues, so I'm not sure if these were deliberately left in, or if I'm just the first person to be looking this carefully.
So far we fixed various issues of this sort that people noticed, but there was never a concerted effort to find all of them. So they were not deliberately left in, just not found yet. Whether we want to fix them all is up to who ultimately decide about the std library implementation.
So far the fixes have been localized enough that it's been easy to take them (eg ). If anything comes up that requires drastic changes to fix then there might be a conversation about it, but for simple ones that don't increase maintenance burden I think they'll be happily accepted.
Change:
<ins> error[E0433]: failed to resolve: use of undeclared type `IntoIter` --> $DIR/issue-82956.rs:25:24 | LL |         let mut iter = IntoIter::new(self); |                        ^^^^^^^^ not found in this scope | help: consider importing one of these items | LL | use std::array::IntoIter; | LL | use std::collections::binary_heap::IntoIter; | LL | use std::collections::btree_map::IntoIter; | LL | use std::collections::btree_set::IntoIter; | and 8 other candidates error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </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:
fn main() { let item = stuff::Item::new(); println!("{}", check_ptr_exist!(item, name)); <del> //~^ ERROR field `name` of struct `CObj` is private </del> }

Discussion:
The code below yields two errors: field is private error in if expression because type is instead of This means a user can observe the type of a private field of a dependency in their error messages. It doesn't mean they can actually use that information, but it seems weird at least. Is this actually an issue? If you don't consider it one, feel free to close this. - - (originally seen )
I won't close the ticket as this deserves a conversation to be had, but I personally don't consider it to be a big problem. Parsing x.len as when we suggest that would be nice, but in this case it would lead to confusing errors if we don't annotate the compiler state with something along the lines of
Hi Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.
I agree, like you mentioned , there are some improvements we could make, but I think the current behaviour is fine.