jiebi/CodeConvo huggingface dataset:
Change:
//! An analysis to determine which temporaries require allocas and //! which do not. <del> use rustc_data_structures::fnv::FnvHashSet; </del> <ins> use rustc_data_structures::bitvec::BitVector; </ins> use rustc::mir::repr as mir; use rustc::mir::visit::{Visitor, LvalueContext}; use trans::common::{self, Block};

Discussion:
In MIR we want values to be SSA, however ensuring that constraint in trans (i.e. in TempRef) is wrong, I think. Namely, for code like this: we will generate following MIR (graphviz version, because easier to visualise): ! which will result in Note how we assign twice, but the two branches are fully disjoint, and thus, for the purposes of data-flow is still SSA, but for the purposes of translator is assigned multiple times. If we want s to stay across translation of the whole function, we will need something like a in the MIR. cc
Another option would be to convert these temporaries into lvalues (i.e. variables). Could it be that the unfinished is supposed to do just that?
I am confused. We do not require temps to be SSA, either in Mir or trans... But in trans we optimize in those cases where we can (I.e., where temps are SSA). Right?
suggests they are SSA with borrowing and mutation possible. Might be me misinterpreting what SSA means, but what I mean is that these are not supposed to be assigned more than once, for some definitions of once.
I see. Yes, ok, I agree that comment was in error. I think though that you probably ought to update it in :) I would still expect temps to be "DSA" -- which afaik I just made up -- that is, no two writes can reach one another without exiting the "live scope" of the temporary, but I don't know that it's an important property. FWIW I think SSA usually implies that values are "pure values", i.e., you can't take their address and mutate them. But I know what you mean in any case.
er, ought to have updated it
I’ll keep updating the comment in mind in whatever PR that comes next.
Change:
filename = "rustc-{}-{}{}".format(rustc_channel, self.build, tarball_suffix) self._download_component_helper(filename, "rustc", tarball_suffix, stage0) <del> filename = "cargo-{}-{}{}".format(rustc_channel, self.build, tarball_suffix) self._download_component_helper(filename, "cargo", tarball_suffix) if not stage0: </del> <ins> # download-rustc doesn't need its own cargo, it can just use beta's. if stage0: filename = "cargo-{}-{}{}".format(rustc_channel, self.build, tarball_suffix) self._download_component_helper(filename, "cargo", tarball_suffix) self.fix_bin_or_dylib("{}/bin/cargo".format(bin_root)) else: </ins> filename = "rustc-dev-{}-{}{}".format(rustc_channel, self.build, tarball_suffix) self._download_component_helper( filename, "rustc-dev", tarball_suffix, stage0

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: x.py patches stage0/cargo Instead, this happened: x.py tries to patch ci-rustc/cargo, fails, and never patches stage0/cargo, causing a build failure. In particular, does not exist: and stage0/bin/cargo is never patched.
Hmm this seems to be related to caching somehow - if I delete stage0/ altogether it works properly.
I was not able to replicate this :( checking out without clearing the cache didn't reproduce the bug.
And now it broke again :/ maybe it only happens on completely fresh builds?
It did try to patch cargo this time, though:
Ok, this looks suspicious: it's downloading the component, but cargo does not show up in ci-rustc/bin/cargo. I think the issue is it successfully patches stage0 cargo, extracts ci-rustc cargo to the wrong folder, overwriting the patched version, and then tries to patch the correct folder. I think the fix is to just not try to download cargo for the ci-rustc toolchain, it's not necessary in the first place.
Change:
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #62411 <https://github.com/rust-lang/rust/issues/70861> <del> error: aborting due to 3 previous errors </del> <ins> error: function pointers and raw pointers not derived from integers in patterns behave unpredictably and should not be relied upon. See https://github.com/rust-lang/rust/issues/70861 for details. --> $DIR/issue-34784-match-on-non-int-raw-ptr.rs:36:9 | LL |         STR => {} |         ^^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #62411 <https://github.com/rust-lang/rust/issues/70861> error: aborting due to 4 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Got a scalar pair where a scalar was expected', 'error: internal compiler error: Got a scalar pair where a scalar was expected' File: --code: Version 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
Regression in nightly-2023-11-09 ping
Good catch, thanks! should fix this.
Change:
// version new_ty of its type where the anonymous region is replaced // with the named one. let (named, anon, anon_param_info, region_info) = if sub.has_name() <del> && self.tcx().is_suitable_region(sup).is_some() && self.find_param_with_region(sup, sub).is_some() </del> <ins> && let Some(region_info) = self.tcx().is_suitable_region(sup) && let Some(anon_param_info) = self.find_param_with_region(sup, sub) </ins> { <del> ( sub, sup, self.find_param_with_region(sup, sub).unwrap(), self.tcx().is_suitable_region(sup).unwrap(), ) </del> <ins> (sub, sup, anon_param_info, region_info) </ins> } else if sup.has_name() <del> && self.tcx().is_suitable_region(sub).is_some() && self.find_param_with_region(sub, sup).is_some() </del> <ins> && let Some(region_info) = self.tcx().is_suitable_region(sub) && let Some(anon_param_info) = self.find_param_with_region(sub, sup) </ins> { <del> ( sup, sub, self.find_param_with_region(sub, sup).unwrap(), self.tcx().is_suitable_region(sub).unwrap(), ) </del> <ins> (sup, sub, anon_param_info, region_info) </ins> } else { return None; // inapplicable };

Discussion:
The code below leads to the following compiler panic <details<summaryfull stderr</summary</details<details<summary<coderustc -Vv</code</summary</details label -needs-triage C-bug I-ICE T-compiler F-genericconstitems requires-incomplete-features claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
Change:
// length of the code to be substituted let snippet_len = span_end_pos as isize - span_start_pos as isize; // For multiple substitutions, use the position *after* the previous <del> // substitutions have happened. offset += full_sub_len - snippet_len; </del> <ins> // substitutions have happened, only when further substitutions are // located strictly after. offsets.push((span_end_pos, full_sub_len - snippet_len)); </ins> } row_num += 1; }

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
<ins> //@ edition: 2024 //@ compile-flags: -Z unstable-options #![feature(gen_blocks)] #![feature(async_closure)] async fn async_fn() { break; //~ ERROR `break` inside `async` function } gen fn gen_fn() { break; //~ ERROR `break` inside `gen` function } async gen fn async_gen_fn() { break; //~ ERROR `break` inside `async gen` function } fn main() { let _ = async { break; }; //~ ERROR `break` inside `async` block let _ = async || { break; }; //~ ERROR `break` inside `async` closure let _ = gen { break; }; //~ ERROR `break` inside `gen` block let _ = async gen { break; }; //~ ERROR `break` inside `async gen` block } </ins>

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
*[other] patterns `{$witness_1}`, `{$witness_2}`, `{$witness_3}` and {$remainder} more } not covered <ins> mir_build_privately_uninhabited = pattern `{$witness_1}` is currently uninhabited, but this variant contains private fields which may become inhabited in the future </ins> mir_build_pattern_not_covered = refutable pattern in {$origin} .pattern_ty = the matched value is of type `{$pattern_ty}`

Discussion:
The following code compiles on nightly (): But if the wrapper type is moved into a module to make the field private, then it does not: (): Making the field makes it compile again. Is this expected? I suppose I could understand if it is; the private fields could change to make actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like . If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an . label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve
label +F-exhaustive_patterns
are we sure this is actually a bug? As I said, I could understand how it's not:
I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics
This is definitely intentional. But yeah, it should have a better error message. Not currently I don't think. It would probably require us to add an trait, eg. something like: This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case. Alternatively, you could give an or method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:
Is supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).
If the type implementing really is uninhabited then there won't actually be any impure code in the match. The call to would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making -only like .

Making a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the in to make it depend on the module.
Change:
(iter, UnusedDelimsCtx::ForIterExpr, true, None, Some(body.span.lo()), true) } <del> Match(ref head, ..) if Self::LINT_EXPR_IN_PATTERN_MATCHING_CTX => { </del> <ins> Match(ref head, _, ast::MatchKind::Prefix) if Self::LINT_EXPR_IN_PATTERN_MATCHING_CTX => { </ins> let left = e.span.lo() + rustc_span::BytePos(5); (head, UnusedDelimsCtx::MatchScrutineeExpr, true, Some(left), None, true) }

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. --cc . I tried this code: I expected to see this happen: no warnings 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. --:
Change:
#![deny(rustc::untranslatable_diagnostic)] #![deny(rustc::diagnostic_outside_of_impl)] #![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")] <ins> #![cfg_attr(bootstrap, feature(c_str_literals))] </ins> #![doc(rust_logo)] #![feature(rustdoc_internals)] #![allow(internal_features)]

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:
fn get_parent_trait_ref( &self, code: &ObligationCauseCode<'tcx>, <del> ) -> Option<(String, Option<Span>)> { </del> <ins> ) -> Option<(Ty<'tcx>, Option<Span>)> { </ins> match code { ObligationCauseCode::BuiltinDerivedObligation(data) => { let parent_trait_ref = self.resolve_vars_if_possible(data.parent_trait_pred);

Discussion:
Type errors (and others) use and similar to write types that are too long to disk, so the cli output is easier to read. Trait bound errors do not do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I created . What was not visible in the tweet but that you will see when you build the repo, is that the types in the error notes are even longer. That's a shame because hidden in that noise the compiler gives the solution to the error (pin).
You can just create a gist with the error generating logic line highlighted. Much more helpful?
I can give more context too. I was implementing a K8s operator using . I start by creating a and then running it with . This returns a . That stream yields an item every time the reconcile loops reconciles an item or returns an error. For testing, I iterate over the stream to check that it reconciles items the way I expect. . The solution is to pin the stream returned by .
how would i go about solving this? claim
you can look at how we do it here You have to do the same thing but at the very least in the places we print out types to string here:
You also need to ensure that the type-shortening is conditional, based on whether the user wants verbose output or not (similar to the existing logic for type errors).
already checks whether is enabled or not before shortening.
into: by the looks: is the same as and i can call the method on it, but in the formatting (that returns a tuple) im not sure how to call those functions (as t is a string, and calling the function returns a string and pathbuf. in the closure should i just ignore ? or is that a bad approach?
Change:
} PointerOutOfBounds { ptr, msg, allocation_size } => write!( f, <del> "{} failed: pointer must be in-bounds at offset {},  </del> <ins> "{}pointer must be in-bounds at offset {},  </ins> but is outside bounds of {} which has size {}", msg, ptr.offset.bytes(), ptr.alloc_id, allocation_size.bytes() ), <del> DanglingIntPointer(_, CheckInAllocMsg::InboundsTest) => { write!(f, "null pointer is not allowed for this operation") </del> <ins> DanglingIntPointer(0, CheckInAllocMsg::InboundsTest) => { write!(f, "null pointer is not a valid pointer for this operation") </ins> } DanglingIntPointer(i, msg) => { <del> write!(f, "{} failed: 0x{:x} is not a valid pointer", msg, i) </del> <ins> write!(f, "{}0x{:x} is not a valid pointer", msg, i) </ins> } AlignmentCheckFailed { required, has } => write!( f,

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Some error message changes (cc ) broke Miri, but some "null pointer is not allowed for this operation" changes look... wrong? For example: (and many more) They are all not .
Yeah my patch makes no sense... working on a fix.
I don't think the toolstate is fixed: ! But it's just error message differences: claim
Change:
<ins> // edition:2018 // // Regression test for issue #67765 // Tests that we point at the proper location when giving // a lifetime error. fn main() {} async fn func<'a>() -> Result<(), &'a str> { let s = String::new(); let b = &s[..]; Err(b)?; //~ ERROR cannot return value referencing local variable `s` Ok(()) } </ins>

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
<ins> // check-pass // only-x86_64 // Checks that the compiler does not actually try to allocate 4 TB during compilation and OOM crash. fn foo() -> [u8; 4 * 1024 * 1024 * 1024 * 1024] { unimplemented!() } fn main() { foo(); } </ins>

Discussion:
The following ICEs on beta and nightly: () <details<summarygdb backtrace </summary</details
triage: P-high.

A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.
Change:
= note: each usage of a `const` item creates a new temporary = note: the mutable reference will refer to this temporary, not the original `const` item note: `const` item defined here <del> --> $DIR/lint-const-item-mutation.rs:12:1 </del> <ins> --> $DIR/lint-const-item-mutation.rs:13:1 </ins> | <del> LL | const MY_STRUCT: MyStruct = MyStruct { field: true, inner_array: ['a'] }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL | const MY_STRUCT: MyStruct = MyStruct { field: true, inner_array: ['a'], raw_ptr: 2 as *mut u8 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> warning: 6 warnings emitted

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 have quite a lot of MMIO in an embedded project, defined and used like this: (see a ) When I , I'm getting a whole host of warnings of the type: I expect no warnings, because I'm not assigning to a , I'm assigning to a dereferenced , aka a mutable u32. I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is , but it's pointing to a able . Dereferencing shouldn't care whether the pointer variable is . <!-- 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. --: No backtrace for this bug; it's a warning.
There's a... fine, I guess, workaround of in my case, since all the MMIO code is bundled into a module away from the rest.
cc
This will be fixed by
Awesome, thanks so much!