jiebi/CodeConvo huggingface dataset:
Change:
/// If the resulting alignment differs from the type's alignment, /// the argument will be copied to an alloca with sufficient alignment, /// either in the caller (if the type's alignment is lower than the byval alignment) <del> /// or in the callee† (if the type's alignment is higher than the byval alignment), </del> <ins> /// or in the callee (if the type's alignment is higher than the byval alignment), </ins> /// to ensure that Rust code never sees an underaligned pointer. <del> /// /// † This is currently broken, see <https://github.com/rust-lang/rust/pull/122212>. </del> pub fn make_indirect_byval(&mut self, byval_align: Option<Align>) { assert!(!self.layout.is_unsized(), "used byval ABI for unsized layout"); self.make_indirect();

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: I expected to see this happen: Alignment requirements are upheld. Instead, this happened: is clearly not as we indicate. This is unsound. label I-unsound A-ffi This issue is somewhat similar to . The fix for that issue, , made this problem worse by causing Rust and alignments to differ in more cases. (That change is correct, because the Rust and alignment must differ to satisfy the ABI. It just uncovered this issue in more cases.) This is also similar to . However, unlike that one, this issue is practical (and easy) to fix. pointers are not exposed to Rust code, so we can just make a copy of the argument into a higher-aligned alloca, without breaking Rust semantics. In fact, we already do this in the reverse situation, when the Rust alignment is lower than the alignment (): <!-- 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. --:
I will open a fix for this shortly.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
.run_unchecked(); out.assert_stdout_contains("lfoo"); out.assert_stdout_contains("lbar"); <ins> assert!(out.stdout_utf8().ends_with('n')); </ins> }

Discussion:
Running with doesn't include a trailing so the next shell prompt gets smooshed on: I can't imagine this is intentional since all other options seem to include the newline. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +E-easy +A-cli +T-compiler -needs-triage
claim
Change:
<ins> //@ build-fail struct Bar<const BITS: usize>; impl<const BITS: usize> Bar<BITS> { const ASSERT: bool = { let b = std::convert::identity(1); ["oops"][b]; //~ ERROR evaluation of `Bar::<0>::ASSERT` failed true }; fn assert() { let val = Self::ASSERT; if val { std::convert::identity(val); } } } fn main() { Bar::<0>::assert(); } </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. --I encountered an ICE while playing with 's that has to do with its comptime assertions. I have not been able to reproduce the ICE when inlining the constant value in which the checks are performed. Perhaps it is related with the fact that originally there was a crate boundary? I have an inkling const blocks' merger might be to blame. <!-- 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
It would be useful to have a minimal example that doesn't involve the entire tagged_ptr crate.
Reduced: , needs This bisects to cc label A-monomorphization S-has-mcve -E-needs-mcve
ye olde "compiler must not crash on invalid code" problem
PR with a fix is up. Thanks for catching this before the bug hit beta
No, thanks to you all for not only fixing it, but running this amazing project every day. I hope I have more time in the future so that I can spend it here and be a part of this.
Change:
error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. <del> thread '$DIR/failed-doctest-output.rs - OtherStruct (line 17)' panicked at 'couldn't compile the test', src/librustdoc/test.rs:310:13 </del> <ins> thread '$DIR/failed-doctest-output.rs - OtherStruct (line 17)' panicked at 'couldn't compile the test', src/librustdoc/test.rs:319:13 </ins> note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ---- $DIR/failed-doctest-output.rs - SomeStruct (line 11) stdout ----

Discussion:
Doc test with missing closing back quotes fail without any explanation. rust /// let x = 7; /// asserteq!(x, a()); /// // <- HERE /// fn a() -i32 { 7 } rustc 1.35.0-nightly ( 2019-03-22) binary: rustc commit-hash: commit-date: 2019-03-22 host: x8664-unknown-linux-gnu release: 1.35.0-nightly LLVM version: 8.0 rustc 1.33.0 ( 2019-02-28) binary: rustc commit-hash: commit-date: 2019-02-28 host: x86_64-unknown-linux-gnu release: 1.33.0 LLVM version: 8.0
~I believe this is related to . The second <coderust</codeline is unable to be lexed, so the lexer bails with an unbuffered fatal error.~ I was wrong. I have a fix incoming.
Oh hey, this looks to be related to and , cc
Change:
<ins> use std::alloc::{GlobalAlloc, Layout}; struct Test(u32); unsafe impl GlobalAlloc for Test { unsafe fn alloc(&self, _layout: Layout) -> *mut u8 { self.0 += 1; //~ ERROR cannot assign 0 as *mut u8 } unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) { unimplemented!(); } } fn main() { } </ins>

Discussion:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///
Change:
<ins> // compile-flags: -O #![crate_type = "lib"] pub fn foo(t: &mut Vec<usize>) { // CHECK-NOT: __rust_dealloc let mut taken = std::mem::take(t); taken.pop(); *t = taken; } </ins>

Discussion:
With this code Stable produces Whereas beta/nightly produces searched nightlies: from nightly-2022-07-02 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu </details label +regression-from-stable-to-nightly +A-mir-opt-inlining
Godbolt: Result IR can be further optimized by GVN, so this might be addressable on the LLVM side.
Looks like this got a bit worse on LLVM main because an additional assume is being preserved: Anyway, there is a phase ordering problem here. MemCpyOpt runs after GVN, and only at that point do we convert the memcpy into a memset, which makes the following load from it easy to fold. An easy fix would probably be to support memset in InstCombine load store forwarding. But this is no longer going to fix this issue due to the aforementioned assume issue. Ugh.
Upstream patch for InstCombine: An alternative solution would be to move MemCpyOpt prior to GVN, but I'm not sure whether that would cause other issues.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Upstream patch for SimplifyCFG: Together these produce the following final IR: Ignoring the opportunity to form a , this is optimal.
Nightly now compiles to
Needs codegen test.
Would just work?
Sounds reasonable.
Reopening because it working on nightly is not really reliable behavior. and both change vec field order and in each case it breaks the test.
I'm no longer having issues with the codegen test, LLVM 16 upgrade seems to have made it more reliable.
Change:
impl OpenOptions { pub fn new() -> OpenOptions { OpenOptions { <del> flags: 0, </del> <ins> flags: libc::O_CLOEXEC, </ins> read: false, write: false, mode: 0o666,

Discussion:
After lands we will be setting on all file descriptors on unix in the standard library. Currently we do so in a nonatomic fashion, however, so it's possible to continue to leak file descriptors into children if a thread is concurrently forking. Many platforms have methods of creating file descriptors atomically, but many of the APIs are quite new and they need to be properly detected at runtime. For example, the current instances of that need to be migrated are listed below. A reminder of our minimum platform requirements are linux 2.6.18 and OSX 10.7. [x] - this should specify the flag. This flag was in linux 2.6.23 and appears to exist on OSX 10.7. [x] - this should be specify the flag in the argument (second). This flag was only in linux 2.6.27 and does not exist on OSX. [x] - this should be replaced with a call to . This system call was only in linux 2.6.28 and does not exist on OSX. [x] - this should be replaced with (linux 2.6.27, not on OSX) or (linux 2.6.24, appears to exist on OSX 10.7). [x] - this could be replaced with on linux 2.6.27 and perhaps on OSX (not confirmed). The hard part about this bug is figuring out if it's possible to avoid compile-time detection of these functions (and instead rely on runtime detection).
cc
I know this is closed, but I just have to comment on how well thought out and organised the original description was - how clearly the problem is captured and then it's solution tracked. Well done everyone.
Change:
} fn post(&self, s: &mut pprust::State<'_>, node: pprust::AnnNode<'_>) { match node { <ins> pprust::AnnNode::Crate(_) | </ins> pprust::AnnNode::Ident(_) | pprust::AnnNode::Name(_) => {},

Discussion:
E.g. becomes Specifically, the syntax contexts of and are linked (the s refer to the same identifier, even with hygiene) but this is not represented in the output at all, so one might interpret them as being distinct identifiers.
There is no more pretty=hygene, was it replaced with something?
Closing. is apparently no longer a thing, and the output looks sufficiently different with that I don't think it's the same.
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Looks like is a thing though so reopening... output today is below. I'm not completely sure whether this is fixed or not --- the output looks the same for the two s, I guess? Not sure which are being referred to either...
Change:
<ins> #![feature(reentrant_lock)] use std::sync::ReentrantLock; use std::cell::Cell; // ReentrantLockGuard<Cell<i32>> must not be Sync, that would be unsound. fn test_sync<T: Sync>(_t: T) {} fn main() { let m = ReentrantLock::new(Cell::new(0i32)); let guard = m.lock(); test_sync(guard); //~^ ERROR `Cell<i32>` cannot be shared between threads safely [E0277] } </ins>

Discussion:
I tried running this code in miri: I expected to see this happen: compile error Instead, this happened: compiled successfully and miri reported a data race this is because the automatic is incorrect: 'a,+T%3E ReentrantLock's tracking issue:
label I-unsound
label requires-nightly
Change:
use smallvec::{smallvec, SmallVec}; use rustc_span::source_map::{respan, Spanned}; <ins> use std::assert_matches::debug_assert_matches; </ins> use std::collections::{hash_map::Entry, BTreeSet}; use std::mem::{replace, take};

Discussion:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.
Change:
<ins> fn main() { for i in { //~^ ERROR missing expression to iterate on in `for` loop } } </ins>

Discussion:
Spot the bug: Unfortunately, instead of pointing to the missing iterator, rust points to the 1: I'd love it to instead say 'missing iterator for loop': Other variants of this with less than ideal errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Well, it thinks the block is the iterator.
Yes, I understand, but a) is not an iterator, and b) since there's no body of the loop I was hoping the parser could recover somehow and understand that the block expression was intended to be the body.
Yes, I just wanted to make sure we were on the same page :)
I could have sworn there was an old ticket for this already but I can't find it
claim
Change:
/// # Examples /// /// ```rust <del> /// #![feature(nonnull_slice_from_raw_parts)] /// </del> /// use std::ptr::NonNull; /// /// // create a slice pointer when starting out with a pointer to the first element

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization PR
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
// If this is a default rule, this is an additional constraint placed on // its run. Generally something like compiler docs being enabled. <del> is_really_default: bool, </del> <ins> is_really_default: ReallyDefault<'a>, </ins> } impl<'a> ShouldRun<'a> {

Discussion:
introduced some checks which execute 4 times. They run unconditionally when executing , even if it is just to run tidy. On my system the wall time exceeds that of running tidy itself. I'll look into whether the checks themselves can be made be less wasteful. But if there are suggestions how to completely eliminate them or defer them while preserving their original purpose that would be great too. ! CC can you explain the purpose of running this in rather than erroring in ?
To know beforehand if the test should unconditionally be run or not. If the test is run and the npm package isn't installed, we panic. To be noted that we could make it go down to 2 by switching the order of : currently we check both "local" and "global". Switching the two of them will divide the number of calls by two. cc
I don't have installed, so it'll fail and no short-circuiting will happen regardless of order.
In case you don't have it it'll check 4 times indeed.
Hm, this does seem annoying. It's possible we could add some lazily-evaluated default condition so that this never runs if we're not considering default-on steps (if defaults are on, then these npm lists are likely quite fast in comparison to the rest of the logic).
Change:
<ins> //@ aux-build:block-on.rs //@ edition:2021 //@ run-pass #![feature(async_closure)] extern crate block_on; pub trait Trait { fn callback(&mut self); } impl Trait for (i32,) { fn callback(&mut self) { println!("hi {}", self.0); self.0 += 1; } } async fn call_once(f: impl async FnOnce()) { f().await; } async fn run(mut loader: Box<dyn Trait>) { let f = async move || { loader.callback(); loader.callback(); }; call_once(f).await; } fn main() { block_on::block_on(async { run(Box::new((42,))).await; }); } </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</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!
Change:
<ins> // check-pass // compile-flags: -Z validate-mir struct Foo<'a>(&'a mut u32); impl<'a> Drop for Foo<'a> { fn drop(&mut self) { *self.0 = 0; } } fn and() { let mut foo = 0; // This used to compile also before the fix if true && *Foo(&mut foo).0 == 0 && ({ foo = 0; true}) {} // This used to fail before the fix if *Foo(&mut foo).0 == 0 && ({ foo = 0; true}) {} println!("{foo}"); } fn or() { let mut foo = 0; // This used to compile also before the fix if false || *Foo(&mut foo).0 == 1 || ({ foo = 0; true}) {} // This used to fail before the fix if *Foo(&mut foo).0 == 1 || ({ foo = 0; true}) {} println!("{foo}"); } fn main() { and(); or(); } </ins>

Discussion:
If you consider the following program: It will print "2,3,4,1," four times. The issue occurs on recent nightly as well as all the way back to 1.0.0. This is a bit weird IMO, and makes && and chains non-associative. IMO it's a bug that should be fixed to print "1,2,3,4,". IDK how much we can do about this at the current point, given backwards compatibility concerns. It might not stop programs from compiling, but programs might differ in their runtime output. There is with the name "Stabilize drop order" but if you read the text, it only concerns the drop order of structs, vecs, tuples, etc. Also, after the merge, the RFC author themself made a PR to add regression tests in , and mentioned that that PR was enough for getting the RFC tested. The RFC didn't include anything about && chains. I think the language should not be interpreted too generally. It took a long time until in which we we got some further drop order tests for "established" language constructs, while there have been many PRs with drop order tests for let-else. Originally I've discovered this in: , but given that it's so visible, I'm sure that someone else has already complained about this. Maybe one can just implement the change to "1,2,3,4," and make a crater run for it? cc label T-lang
Change:
<ins> // Copyright 2015 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. struct A { pub x: u32, pub y: u32, } fn main() { let mut a = A { x: 1, y: 1 }; a = A { x: a.y * 2, y: a.x * 2 }; assert_eq!(a.x, 2); assert_eq!(a.y, 2); } </ins>

Discussion:
Assigning to a mutable vector causes it to be modified in-place even if the right side of the assignment references it. On IRC, pointed me to , which might be related.
Nominating. This may not be a 1.0 backcompat-lang issue though as it seems fairly rare.
Same thing with structs:
OK, same thing happens with enums, which is a bit more serious since it now affects memory safety.
I believe this problem is in trans -- it is supposed to used a temporary buffer for these sorts of cases, but obviously that check is not working correctly.
Team believes this to be a miscompilation issue (and not, as we feared at first, a failure of the borrow-checker to reject an incorrect program). That is, these programs should be compilable; the problem is that the generated code is wrong. P-high, not 1.0.
All of the code examples from this ticket seem to work now: So I think this just needs regression tests.
Change:
<ins> // issue #100631, make sure `TyCtxt::get_attr` only called by case that compiler // can reasonably deal with multiple attributes. // `repr` will use `TyCtxt::get_attrs` since it's `DuplicatesOk`. #[repr(C)] //~ ERROR: unsupported representation for zero-variant enum [E0084] #[repr(C)] enum Foo {} fn main() {} </ins>

Discussion:
currently happily ignores any additional attributes in case there are more than one. While this is fine for attributes which don't care about duplicates or emit a warning/error in case there are more than one, this isn't currently checked in the compiler, potentially causing bugs. similar to the check in we should check that the attr declaration in has an acceptable way of dealing with duplicates. in case there are any questions on how to implement this, feel free to open a thread on zulip and pinging me there. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim