jiebi/CodeConvo huggingface dataset:
Change:
LL | pub use half_public_import::HalfPublicImport; |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <ins> error: Public: pub, Exported: pub, Reachable: pub, ReachableFromImplTrait: pub --> $DIR/access_levels.rs:72:9 | LL | pub use half_public_import::HalfPublicImport; |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> error: Public: pub(crate), Exported: pub, Reachable: pub, ReachableFromImplTrait: pub --> $DIR/access_levels.rs:14:13 |

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see no output from the compiler. Instead, this happened: searched nightlies: from nightly-2022-09-22 to nightly-2022-09-27 regressed nightly: nightly-2022-09-25 searched commit range: regressed commit: This is a roll-up, seems the most likely culprit. cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority, probably a P-high since the lint malfunction is blocking valid code (iiuc) label -I-prioritize P-high T-compiler
any ideas how to address this or should I start digging in to it
In HIR desugars into two items (import in type namespace and import in value namespace). One of them is externally reachable and another is not (before both of them were incorrectly marked as externally reachable). Code in should somehow account for this desugaring and not report the as unnecessary if at least one of the imports is reachable.
I have been unable to fix this or apply a revert. can you look at implementing this before the beta cutoff?
Reverted in
Change:
<ins> // Check that we do not insert StorageDead at each target if StorageDead was never seen // EMIT_MIR issue_76432.test.SimplifyComparisonIntegral.diff use std::fmt::Debug; fn test<T: Copy + Debug + PartialEq>(x: T) { let v: &[T] = &[x, x, x]; match v { [ref v1, ref v2, ref v3] => [v1 as *const _, v2 as *const _, v3 as *const _], _ => unreachable!(), }; } fn main() { test(0u32); } </ins>

Discussion:
The following program runs fine in Miri on mir-opt-levels 0-2, but in level 3 it errors: The error is: Looks like something changes the liveness ranges of locals and it does so incorrectly. Cc
Could you describe affected rustc version and reproduction steps?
The rustc version is commit , but most likely a nightly will also do it. To reproduce, run this in a Miri checkout:
The SimplifyComparisonIntegral introduces StorageDead for a local which didn't have any markers before. Currently this also makes the local dead on the entry to the function. Related to the issue about semantics of StorageLive without matching StorageDead (this would be the reverse).
The LLVM docs for their version of (which the Rust thing translates to) So just introducing a without also having appropriate is pretty clearly wrong, I would say.
That is the doc for , not . The doc for is:
oops sorry, yeah. We'd have to check the MIR here to see if it makes any sense at all; however, currently I think not just Miri but also our dataflow framework assumes that variables with any liveness annotations are initially dead.
Diff for this case before/after SimplifyComparisonIntegral: Note the placed in both successors of the , when there was no to begin with. cc -- along the lines of , you could leave the as a copy in this case for later optimisation passes to clean up. This is definitely a case I can cover for .
Does this analysis ensure that is not used any more afterwards? As in, would it be sufficient to add a in the start block? (I am not saying that that's a good fix, just trying to feel out the design space here.) I guess I am also surprised that an "integral comparison simplification" pass touches storage liveness.
That part is my fault. I incorrectly assumed that there's a storagedead before the switch. Maybe there is one in some situations, idk, if there is, we should probably just not do the optimization instead of rewriting the storage markers.
Should this be marked as I-unsound?
Assigning as discussed as part of the . modify labels: +P-medium -I-prioritize
Error: Label P-medium can only be set by Rust team members Please let know if you're having trouble with this bot.
Change:
let mut err = match *error { SelectionError::Unimplemented => { <del> // If this obligation was generated as a result of well-formed checking, see if we // can get a better error message by performing HIR-based well formed checking. </del> <ins> // If this obligation was generated as a result of well-formedness checking, see if we // can get a better error message by performing HIR-based well-formedness checking. </ins> if let ObligationCauseCode::WellFormed(Some(wf_loc)) = root_obligation.cause.code.peel_derives() {

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
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly
Change:
let literal = constant.literal; match literal { ConstantKind::Ty(c) => match c.kind() { <del> ConstKind::Param(_) => {} </del> <ins> ConstKind::Param(_) | ConstKind::Error(_) => {} </ins> _ => bug!("only ConstKind::Param should be encountered here, got {:#?}", c), }, ConstantKind::Unevaluated(..) => self.required_consts.push(*constant),

Discussion:
Found with a <details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression in nightly-2022-09-18 from ( <details<summaryBisect info</summarysearched nightlies: from nightly-2022-09-04 to nightly-2022-11-07 regressed nightly: nightly-2022-09-18 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.4 Host triple: x86_64-apple-darwin </details
For the record, this isn't dependent on return type, which is a separate error. This also ICEs:
This don't ICE: I guess it's because terminated because the error type error.
Yeah, still needs to implement the trait in the -- this ICEs, for example:
I can take a look at this, unless you're already working on this
I think compiler-errors already submitted a PR to fix this, PR linked above, but he did not claim this issue.
Oh thanks, didn't see this.
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. use super::*; use super::B::S; pub struct T { i: i32 } </ins>

Discussion:
This code compiles: However, splitting the code into files causes compilation to fail: I am not sure whether or use is correct; regardless, replacing the latter with the former in produces a similar error:
cc
This appears to work now.
Change:
// gdbg-check:$3 = {pointer = [...], vtable = [...]} // gdbr-check:$3 = &unsized::Foo<dyn core::fmt::Debug> {pointer: [...], vtable: [...]} <ins> // gdb-command:print tuple_slice // gdbg-check:$4 = {data_ptr = [...], length = 2} // gdbr-check:$4 = &(i32, i32, [i32]) {data_ptr: [...], length: 2} // gdb-command:print tuple_dyn // gdbg-check:$5 = {pointer = [...], vtable = [...]} // gdbr-check:$5 = &(i32, i32, dyn core::fmt::Debug) {pointer: [...], vtable: [...]} </ins> // === CDB TESTS =================================================================================== // cdb-command: g

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. --code from <!-- 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
cc It looks like this might be related to
reports that this is regression in (which is indeed in PR ).
reports in zulip that this test case fails at that same injection point when combined with (aka ): ./src/test/run-pass-valgrind/dst-dtor-4.rs : <details<summaryContent of above file</summary</details
Files that reproduce the ice one way or another with : `
Thanks for the bug report, I'll look into it.
Looks like this should be an easy fix. The code just doesn't expect tuples to be unsized (which of course it should).
Change:
fn main() { // assigning to various global constants <del> None = Some(3); //~ ERROR cannot assign to immutable static item </del> foo = 6; //~ ERROR cannot assign to immutable static item }

Discussion:
When compiling the following code: I get the error: Compiled with:
I also just hit this today. An even simpler test case:
Reproduced with (both cases). Interestingly, rustc warns that X0 and X1 don't need to be mutable on the first case.
Similar ICE with structs:
The simplest case I think:
It's because assumes only one of will come but it met . So seems easy to fix, but what about tuples/structs? is also not allowed, right? I initially thought it is allowed because is. But previous discussions seem that it's not: , .
My impression is that isn't supposed to be allowed. That said, it would be kinda neat if it was. Right now I'm writing the same 3 lines over and over that look like and I'd love to be able to just say
I forgot to mention about mutability; currently is obsolete, and (heard from irc) it may be because it's confusing that immutable tuples are with . I don't know any previous discussion about it. anyone? If it is true, should be disallowed in the same manner, because is immutable while and are. Anyway, I agree with it's not cool to unpack manually.
Clearly something in the compiler is not checking that the LHS of an assignment is actually an lvalue. Kind of amusing. Rather surprising that this gets through borrowck, I'll have to look at that. It's probably assuming that an earlier pass would have caught such cases. Anyway, it'd be nice to permit , certainly, but it is not currently allowed. I think that'd be a post-Rust 1.0 sort of extension. I previously thought it would introduce horrible ambiguities into parsing, but I realize now that it would not, so long as you only have two cases: , which assigns to a pattern, and which always declares new bindings, and , which always overwrites existing lvalues.
Change:
#[feature(macro_rules, globs, struct_variant, managed_boxes)]; #[allow(unknown_features)]; // Note: remove it after a snapshot. <del> #[feature(quote_item, quote_expr)]; </del> <ins> #[feature(quote)]; </ins> extern mod extra; extern mod flate;

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .
Change:
/// get a line from the list of pre-computed line-beginnings /// <del> pub fn get_line(&self, line: int) -> String { </del> <ins> pub fn get_line(&self, line_number: uint) -> Option<String> { </ins> let lines = self.lines.borrow(); <del> let begin: BytePos = (*lines)[line as uint] - self.start_pos; let begin = begin.to_uint(); let slice = self.src.as_slice().slice_from(begin); match slice.find('n') { Some(e) => slice.slice_to(e).to_string(), None => slice.to_string() } </del> <ins> lines.get(line_number).map(|&line| { let begin: BytePos = line - self.start_pos; let begin = begin.to_uint(); let slice = self.src.as_slice().slice_from(begin); match slice.find('n') { Some(e) => slice.slice_to(e), None => slice }.to_string() }) </ins> } pub fn record_multibyte_char(&self, pos: BytePos, bytes: uint) {

Discussion:
When trying to build with I'm getting
Is there a temporary workaround? Thanks!
Most likely change the occurrences of (or ) to . Like .
I just tripped over this ICE in serde. I love c-reduce. It came up with the following code that reproduces the bug by reducing 203K down to this in 15 minutes: Here's the error:
Change:
} pub fn body(&self, id: BodyId) -> &'hir Body<'hir> { <del> self.tcx.hir_owner_nodes(id.hir_id.owner).bodies.get(&id.hir_id.local_id).unwrap() </del> <ins> self.tcx.hir_owner_nodes(id.hir_id.owner).unwrap().bodies.get(&id.hir_id.local_id).unwrap() </ins> } pub fn fn_decl_by_hir_id(&self, hir_id: HirId) -> Option<&'hir FnDecl<'hir>> {

Discussion:
As of rustc 1.43.0-nightly ( 2020-03-15) the Travis CI builds of are failing due to rustc crashing. The crash happens when building the crate, which is a dependency of one of quiche's subcrates. Unfortunately I wasn't able to reproduce this locally, so I can't try the latest master or try to prepare a minimal reproducer, but I can reproduce this realiably on Travis CI, see e.g. https://travis- https://travis- https://travis- https://travis- Could this have something to do with Travis CI specifically? As per above, I don't have specific code that reproduces this. I can only reproduce when building the crate as part of quiche on Travis CI. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FTR, the docopt crate was last updated almost a year ago, so this is not due to some new code there
Let's see if we can shrink the input to something suitable for a regression test. ping cleanup Also cc
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
This seems to be an issue with It could be we're calling with something that isn't an HIR owner, in which case it should be changed to return instead of panicking. It's odd that it can't be reproduced though.
I can reproduce it by on
I just realized I wasn't actually using rust nightly when I tried to reproduce locally :man_facepalming: so that explains that...
Minimized:
assign
Change:
visitor.visit_path(path, id); } } <ins> pub fn walk_attribute<'a, V: Visitor<'a>>(visitor: &mut V, attr: &'a Attribute) { visitor.visit_tts(attr.tokens.clone()); } pub fn walk_tt<'a, V: Visitor<'a>>(visitor: &mut V, tt: TokenTree) { match tt { TokenTree::Token(_, tok) => visitor.visit_token(tok), TokenTree::Delimited(_, delimed) => visitor.visit_tts(delimed.stream()), } } pub fn walk_tts<'a, V: Visitor<'a>>(visitor: &mut V, tts: TokenStream) { for tt in tts.trees() { visitor.visit_tt(tt); } } </ins>

Discussion:
This issue probably needs a better title, perhaps someone more familiar with the compiler's handling of macros can suggest a better one. Some kind of error message, at least. panic with exit code :
Simplified: Same ICE will happen if is changed to ///. Update: Panic happens at this line: has keys and , but the is .
Change:
<ins> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<const X: u32>; impl<const X: u32> S<{X}> { fn x() -> u32 { X } } fn main() { assert_eq!(S::<19>::x(), 19); } </ins>

Discussion:
produces: which is clearly incorrect.
What I believe is happening here is that is no longer treated as a parameter, because it's in brackets. It's a when it gets to rather than a parameter.
Change:
= note: macros cannot expand to enum variants error: unexpected token: `!` <del> --> $DIR/macro-expand-to-field.rs:34:12 </del> <ins> --> $DIR/macro-expand-to-field.rs:35:12 </ins> | LL |     variant!(recovers), |            ^ unexpected token after this

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
Regression in nightly-2023-08-05 Regression in cc
This is probably because it recovers from it and gives the field no name. We should probably give it the macro's name instead I believe this is the offending line:
An alternative approach would be to directly throw an error instead of allowing the parser to continue, imo.
label -needs-triage
Change:
env: RUST_BACKTRACE: 1 os: ubuntu-20.04-xl <ins> - name: x86_64-gnu-llvm-12-stage1 env: RUST_BACKTRACE: 1 os: ubuntu-20.04-xl </ins> - name: x86_64-gnu-nopt os: ubuntu-20.04-xl env: {}

Discussion:
Similar to , we expect contributors to run this frequently, so it should be tested in CI. suggested using the defaults in but I'm a little hesitant to do that because some of them are very wrong for CI (e.g. ) and others shouldn't affect tests but make the compiler slower (e.g. ). I do agree we should enable incremental for these tests, though. Not sure which builder to add these to - adding it to mingw-check would make it significantly slower, and I don't know which of the full builders has spare capacity. do you have suggestions? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
To be clear, I was mistakenly under the impression that only stage1 tests were ran for PR CI. But I could see how that may be an issue for tests (though, is it easy to only run those in stage2?).
ah yeah no, we currently run in PR CI. I think it might make sense to only run now that you mention it though! would be a lot faster and in practice there are very few tests that only fail in stage 2. not currently, no - I think it wouldn't be impossible to add to compiletest though, it already does filtering and parses the headers, so it should be possible to combine the two. That would mean we have to build the stage 2 compiler though, so if we switch to stage 1 I think it would be ok to only run those in a full bors merge, not in PR CI.
just add another builder, we have capacity for that.
If we do get another builder, can we have incremental enabled on it (or rather, whichever dev profile enables that)? Some codegen tests haven't been passing for a short while because of the difference, and might be good to be tracking something that strongly resembles local workflows.
Error: Parsing assign command in failed: ...'bot assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
What is the correct course of action here? Adding another builder?
Yes, adding another builder is enough.

I want to investigate running --stage 1 in PR CI instead of --stage 2 long term, but that's harder and shouldn't block testing this.
This would have caught , I assume?
Yes, despite not being filed as an issue, that's exactly the kind of test failure I was referencing in (it does require that we do enable incremental, not just test at stage 1).
Change:
} self.suggest_boxing_when_appropriate(err, expr, expected, expr_ty); self.suggest_missing_await(err, expr, expected, expr_ty); <ins> self.suggest_missing_parentheses(err, expr); </ins> self.note_need_for_fn_pointer(err, expected, expr_ty); }

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
let llcx = llvm::LLVMRustContextCreate(cgcx.fewer_names); let llmod_raw = parse_module(llcx, module_name, thin_module.data(), &diag_handler)? as *const _; let mut module = ModuleCodegen { <del> module_llvm: ModuleLlvm { llmod_raw, llcx, tm }, </del> <ins> module_llvm: ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(tm) }, </ins> name: thin_module.name().to_string(), kind: ModuleKind::Regular, };

Discussion:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with