jiebi/CodeConvo huggingface dataset:
Change:
// know much about the memory management here so we err on the side of being // save and persist everything with the original module. let mut serialized_bitcode = Vec::new(); <ins> let mut linker = Linker::new(llmod); </ins> for (bc_decoded, name) in serialized_modules { info!("linking {:?}", name); <del> time(cgcx.time_passes, &format!("ll link {:?}", name), || unsafe { </del> <ins> time(cgcx.time_passes, &format!("ll link {:?}", name), || { </ins> let data = bc_decoded.data(); <del> if llvm::LLVMRustLinkInExternalBitcode(llmod, data.as_ptr() as *const libc::c_char, data.len() as libc::size_t) { Ok(()) } else { </del> <ins> linker.add(&data).map_err(|()| { </ins> let msg = format!("failed to load bc of {:?}", name); <del> Err(write::llvm_err(&diag_handler, msg)) } </del> <ins> write::llvm_err(&diag_handler, msg) }) </ins> })?; timeline.record(&format!("link {:?}", name)); serialized_bitcode.push(bc_decoded); } <ins> drop(linker); </ins> cgcx.save_temp_bitcode(&module, "lto.input"); // Internalize everything that *isn't* in our whitelist to help strip out

Discussion:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet
Change:
32_000_000 // 32MB on other platforms }; rustc_driver::set_sigpipe_handler(); <del> env_logger::init(); </del> <ins> env_logger::init_from_env("RUSTDOC_LOG"); </ins> let res = std::thread::Builder::new().stack_size(thread_stack_size).spawn(move || { get_args().map(|args| main_args(&args)).unwrap_or(1) }).unwrap().join().unwrap_or(rustc_driver::EXIT_FAILURE);

Discussion:
Because is the 's default for application-level logging and should not affect the output of the tools.
eh, it's only recently we've shifted away from using it for tools -- but seems like the trend is definitely to do so. I've filed
Change:
pub unsafe fn as_unsafe_cell(&self) -> &UnsafeCell<T> { &self.value } <ins> /// Returns a mutable reference to the underlying data. /// /// This call borrows `RefCell` mutably (at compile-time) so there is no /// need for dynamic checks. #[inline] #[unstable(feature = "cell_get_mut", issue="33444")] pub fn get_mut(&mut self) -> &mut T { unsafe { &mut *self.value.get() } } </ins> } #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
These methods allow one to obtain a mutable reference to the interior of these cells if you have a mutable reference to the cells themselves.
As stated in , I think that a better name for these methods would be .
This issue is now entering its final comment period for stabilization The libs team was unfortunately a little late on stabilizations this cycle, but we're thinking of probably doing a backport of stabilizations partway through the beta cycle. This API also follows existing conventions so should be an easy stabilization!
Looking through the naming convention again, it seems that is only used for conversions or functions that are not cheap or free, e.g. accessing elements of containers, slices, checking the poisoning state of a mutex and returning the element (with the exception of , which isn't stabilized yet). However, is often used for this kind of conversion, e.g. . I don't think fits here.
Ah yes I forgot to mention, but the libs team did indeed discuss the name and concluded that is the convention here. The prefix is used for containers such as vectors, maps, I/O wrappers, synchronization primitives, etc. The prefix is intended for conversions. Because these are "containers" and these methods aren't performing conversions, we concluded the appropriate name was
The libs team discussed this issue during triage yesterday and the decision was to stabilize. We realize that the FCP for this issue was pretty short, however, so please comment with any objections you might have! We're very willing to backport an un-stabilization for the few APIs we have this cycle.
Change:
#![feature(alloc_layout_extra)] #![feature(array_chunks)] <del> #![feature(array_from_ref)] </del> #![feature(array_methods)] #![feature(array_map)] #![feature(array_windows)]

Discussion:
Tracking issue for which adds the following methods [x] Implementation: [ ] FCP [ ] Stabilization PR
Nvm, it's a typo in the issue description, the actual method is named . What is blocking stabilization, it seems like there aren't any open questions/controversies. Shall I make a 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.
: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. The RFC will be merged soon.
Has anyone proposed to stabilize these? Could I just open a PR to start that? :)
I've proposed. In fact, they were already stabilized :)
Since and has been stablized, could we now add , and to libcore? These impls should be easy to implement (just one-liners) and ergonomic to use.
Feel free to create a pull request! I would imagine it would be accepted.
Adding could conflict with downstream . Similarly, since and are "fundamental" and behave like their pointee for coherence purposes, downstream impls of etc are also currently allowed, such that adding would also conflict. Adding another candidate for also was pointed out as possibly being .
Change:
<ins> // build-pass pub const fn f<T, const N: usize>(_: [std::mem::MaybeUninit<T>; N]) {} pub struct Blubb<T>(*const T); pub const fn g<T, const N: usize>(_: [Blubb<T>; N]) {} pub struct Blorb<const N: usize>([String; N]); pub const fn h(_: Blorb<0>) {} pub struct Wrap(Blorb<0>); pub const fn i(_: Wrap) {} fn main() {} </ins>

Discussion:
I tried this code: I expected it to compile successfully. Instead, this happened: It most recently worked on 1.72 Regressed in cc Originally reported in cc modify labels: +regression-from-stable-to-beta -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
fn visit_f32() -> bool { self.write::<f32>() } fn visit_f64() -> bool { self.write::<f64>() } <del> fn visit_char() -> bool { self.write::<uint>() } </del> <ins> fn visit_char() -> bool { self.write::<u32>() } </ins> // Type no longer exists, vestigial function. fn visit_str() -> bool { fail; }

Discussion:
Test case: Expected output: . Example output (changes on every run): . Output from Output with valgrind:
I found this in : That should probably be .
Fixed.
Change:
} impl CoverageSpans { <ins> /// Extracts coverage-relevant spans from MIR, and associates them with /// their corresponding BCBs. /// /// Returns `None` if no coverage-relevant spans could be extracted. </ins> pub(super) fn generate_coverage_spans( mir_body: &mir::Body<'_>, fn_sig_span: Span, body_span: Span, basic_coverage_blocks: &CoverageGraph, <del> ) -> Self { </del> <ins> ) -> Option<Self> { </ins> let coverage_spans = CoverageSpansGenerator::generate_coverage_spans( mir_body, fn_sig_span,

Discussion:
The immediate symptoms of were fixed by , but some users reported that their builds now encounter another coverage-related ICE:
label +T-compiler +A-code-coverage
This ICE does not occur on current stable/beta, but does occur on nightly. label +regression-from-stable-to-nightly
(This will be fixed by , which is awaiting review.)
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<ins> // Test the parse error for an overflowing recursion_limit #![recursion_limit = "999999999999999999999999"] //~^ ERROR `recursion_limit` must be a non-negative integer //~| `recursion_limit` is too large fn main() {} </ins>

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct
Change:
debug!("pat_ty(pat={:?}) found adjusted ty `{:?}`", pat, first_ty); return Ok(*first_ty); } <ins> } else if let PatKind::Ref(subpat, _) = pat.kind && self.cx.typeck_results().skipped_ref_pats().contains(pat.hir_id) { return self.pat_ty_adjusted(subpat); </ins> } self.pat_ty_unadjusted(pat)

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 --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim
Change:
pub mod c_str; pub mod os; pub mod path; <ins> pub mod path2; </ins> pub mod rand; pub mod run; pub mod sys;

Discussion:
Given the following code: The current output is: Ideally the output should look like: Right now, cargo and rustc operate basically independently of each other. The summary ("aborting ..." and "could not compile ...") is repeated twice, and both have different, incompatible ways to get more info about what went wrong. There's no reason to repeat these twice; we could include all the same information in half the space if we can get cargo and rustc to cooperate. I suggest the way this be implemented is by keeping rustc's output the same when run standalone, but omitting "aborting due to ..." and "for more information ..." when run with . Then cargo can aggregate the info it used to print into its own errors by using the JSON output. cc (meta note: I thought of this while working on , which has fully 12 lines of "metadata" after the 5 line error. Most builds are not that bad in comparison, but I do think it shows that it needs support from all the tools in the stack to keep the verbosity down.)
I'm not sure whether making the decision on the error format scheme is the right way to go. I can't think of any reason not to do it, unless the implementation is messy, so
Change:
#debug("  bin: %s", ct); // FIXME: need libstd fs::copy or something run::run_program("cp", [ct, c.bindir]); <ins> if c.opts.mode == system_mode { install_one_crate_to_sysroot(ct, "bin"); } </ins> } else { #debug("  lib: %s", ct); run::run_program("cp", [ct, c.libdir]); <ins> if c.opts.mode == system_mode { install_one_crate_to_sysroot(ct, libdir()); } } } } fn install_one_crate_to_sysroot(ct: str, target: str) { alt os::get_exe_path() { some(_path) { let path = [_path, "..", target]; check vec::is_not_empty(path); let target_dir = fs::normalize(fs::connect_many(path)); let p = run::program_output("cp", [ct, target_dir]); if p.status != 0 { warn(#fmt["Copying %s to %s is failed", ct, target_dir]); } </ins> } <ins> none { } </ins> } }

Discussion:
There's some code for this in cargo now, but it doesn't quite do the right thing. See .
Also worth considering the difference between sysroot and the install prefix - they are not the same. For instance, I never install cargo, always running it out of the build directory, in which case the build directory is sysroot.
I think this is resolved.
Change:
fn f() { |[](* } //~^ ERROR expected one of `,` or `:`, found `(` <del> //~| ERROR expected one of `&`, `(`, `)`, `-`, `...`, `..=`, `..`, `[`, `_`, `box`, `const`, `mut`, `ref`, `|`, identifier, or path, found `*` </del> <ins> //~| ERROR expected one of `&`, `(`, `)`, `-`, `...`, `..=`, `..`, `[`, `_`, `box`, `mut`, `ref`, `|`, identifier, or path, found `*` </ins>

Discussion:
As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this: That gives errors: So I am not sure if this is a bug report or an enhancement request.
Note that this does work in expressions ():
Support for ranges in patterns ( or ) needs to be separately, to and respectively.
Ohh I've just realized that we had this issue opened, I've fixed this in Going to adjust description of the PR accordingly so it closes this issue when merged.
Change:
<ins> // check-pass pub trait Archive { type Archived; } impl<T> Archive for Option<T> { type Archived = (); } pub type Archived<T> = <T as Archive>::Archived; pub trait Deserialize<D> {} const ARRAY_SIZE: usize = 32; impl<__D> Deserialize<__D> for () where Option<[u8; ARRAY_SIZE]>: Archive, Archived<Option<[u8; ARRAY_SIZE]>>: Deserialize<__D>, { } fn main() {} </ins>

Discussion:
Prior to Rust 1.56, I could use values when defining rkyv structs. However, in Rust 1.56, this is no longer allowed. I tried this code: I expected to see this happen: Prior to Rust 1.56, this compiled. Instead, this happened: The following error appears: It most recently worked on: Rust 1.55 : <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Further information: This is using the crate. We use an older , however this still occurs with the latest version.
Bisected to . label +E-needs-mcve
Reproducer without macros, but still dependent on rkyv:
Reduced: Also, if you remove one of the lines, the code still compiles on 1.55 but the error on 1.56 changes to: label regression-from-stable-to-stable (not sure what happened with rustbot and the labels above)
label -E-needs-mcve
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Ok, I know what is the problem and have a fix. Apparently when looking for implementation for compiler considers candidates: one for top-level impl and two s. Before was using that was enough to discard the two s. But changed it to use instead, which is pessimistic, so now the compiler drops the global impl instead (because is not sure) and then can't decide between the two s.
Funny thing is it seems like it's fixed already in the master branch... Trying to bisect what fixed it to better understand if my change is needed after all.
also fixes it.
Change:
<ins> union U { a: &'static i32, b: usize, } fn fun(U { a }: U) { //~^ ERROR access to union field is unsafe dbg!(*a); } fn main() { fun(U { b: 0 }); let closure = |U { a }| { //~^ ERROR access to union field is unsafe dbg!(*a); }; closure(U { b: 0 }); } </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: . I expected to see this happen: rustc rejecting this code. We are transmuting arbitrary types without unsafe, this is clearly unsound. Instead, this happened: rustc accepted this code, and it SIGSEGVs at runtime. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to have regressed between 1.76 and 1.77. In 1.76 (and below) it gave: It's probably related to the THIR unsafeck which in .
I'll take a look at this. I think I may have found out what's going on. claim
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening for beta nomination.
Fix backported via
Change:
// See if the `Type::function(val)` where `function` wasn't found corresponds to a // `Trait` that is imported directly, but `Type` came from a different version of the // same crate. <del> let rcvr_ty = self.tcx.type_of(def_id).instantiate_identity(); </del> <ins> let rcvr_ty = self.node_ty_opt(ty.hir_id); </ins> trait_in_other_version_found = self.detect_and_explain_multiple_crate_versions( err, assoc.def_id,

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic:
Change:
AstFragmentKind::Pat if macro_ident.name == sym::vec => { suggest_slice_pat(&mut e, site_span, parser); } <ins> // Try a statement if an expression is wanted but failed and suggest adding `;` to call. AstFragmentKind::Expr => match parse_ast_fragment(orig_parser, AstFragmentKind::Stmts) { Err(mut err) => err.cancel(), Ok(_) => { e.note( "the macro call doesn't expand to an expression, but it can expand to a statement", ); e.span_suggestion_verbose( site_span.shrink_to_hi(), "add `;` to interpret the expansion as a statement", ";".to_string(), Applicability::MaybeIncorrect, ); } }, </ins> _ => annotate_err_with_kind(&mut e, kind, site_span), }; e.emit();

Discussion:
This is a regression from stable to beta and nightly. This code is wrong (missing semicolons): Stable prints: Beta and nightly both print: Notice that not only is all the useful information gone, but the compiler aborts after the first error instead of finding the rest. It does not matter whether is on or off. cc
cc me
So this fell through the cracks, and was a stable to nightly/beta regression. It still is a regression, in a way, but only of diagnostics. Could you take a look?
Nominating for prioritization.
So this part of the (previous) stable message: feels like a bug to me anyhow. This part: is sort of good. It'd be nice to preserve a backtrace, at least. And ideally we'd suggest adding a .
Given how much time has past, we're going to call this P-medium for now. However, will try to write up some mentoring instructions (or maybe fix it). He has a plan. =) triage: P-medium
I think the best path forward here is to try parsing an expression macro expansion as a statement before emitting an error. If the macro expansion parses as a statement successfully, we can emit a more helpful error suggesting that the user add a semicolon to the macro invocation.
I'm interested in this but I need informations to understand what to do :)
Current output:
Diagnostics meeting triage: lowering priority as the current error is pretty good, even if not ideal yet.
Current output: (Notice that we recover -- it's not a fatal error now.)
Change:
promoted: &Body<'tcx>, ty, san_ty| { <del> if let Err(terr) = verifier.cx.eq_types( ty, san_ty, location.to_locations(), ConstraintCategory::Boring, ) { </del> <ins> if let Err(terr) = verifier.cx.eq_types(ty, san_ty, locations, ConstraintCategory::Boring) { </ins> span_mirbug!( verifier, promoted,

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. 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 ( , regressed in the past week) output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --The desired result can be achieved by swapping the order of the two statements and . <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-07 to nightly-2022-06-08 regressed nightly: nightly-2022-06-08 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 are you working on this? I'll probably be investigating this due to it being related to the recent removal of the borrowck migration mode.
I've been working on it a bit, but please feel free to take over this issue!
This actually looks like a particularly difficult issue. I think it's either a bug in , or something weird with the that is convincing us that the correct source for this region error is through the on line 12 of the example. It may also be notable that we end up going thru a when emitting this error. This issue seems to be out of my area of expertise, so I won't claim it. if you can't find a solution then it may be best to hand off to someone with mir-borrowck expertise.
Actually, what I said was totally wrong.

This is definitely because we're passing in the wrong when . I think I have a fix for this, though I probably want to eliminate other dummy locations we're passing around mir borrowck... cc sorry for all the pings, but don't keep wasting time on this unless you've made significant progress :stuckout_tongue: claim