jiebi/CodeConvo huggingface dataset:
Change:
.cloned() .collect() } <ins> /// Computes a hash representing the state of a repository/submodule and additional input. /// /// It uses `git diff` for the actual changes, and `git status` for including the untracked /// files in the specified directory. The additional input is also incorporated into the /// computation of the hash. /// /// # Parameters /// /// - `dir`: A reference to the directory path of the target repository/submodule. /// - `additional_input`: An additional input to be included in the hash. /// /// # Panics /// /// In case of errors during `git` command execution (e.g., in tarball sources), default values /// are used to prevent panics. pub fn generate_smart_stamp_hash(dir: &Path, additional_input: &str) -> String { let diff = Command::new("git") .current_dir(dir) .arg("diff") .output() .map(|o| String::from_utf8(o.stdout).unwrap_or_default()) .unwrap_or_default(); let status = Command::new("git") .current_dir(dir) .arg("status") .arg("--porcelain") .arg("-z") .arg("--untracked-files=normal") .output() .map(|o| String::from_utf8(o.stdout).unwrap_or_default()) .unwrap_or_default(); let mut hasher = sha2::Sha256::new(); hasher.update(diff); hasher.update(status); hasher.update(additional_input); hex::encode(hasher.finalize().as_slice()) } </ins>

Discussion:
I tried this code: I expected to see this happen: bootstrap rebuilds LLVM, since it's changed. Instead, this happened: bootstrap does nothing. The problem is that we 're using a stamp file and assume that if the commit hasn't changed then none of the files have changed either: I am not sure why we do that? Are we assuming that CMake rebuilds too frequently? That seems like something we should fix upstream ... cc I think this would make your lives easier. HEAD is branched from .
hmm, looks related. I am not sure why that would be the correct behavior? If CFLAGS has changed we should rebuild; I would expect distros to make sure CFLAGS matches between invocations of bootstrap.
The stamp checking for the "normal" case, when not building from a source tarball, has been there since the initial commit of bootstrap:
Are you trying to address the git "dirty" case, or the non-git case, or both?
Both, but primarily the git case since that's how most people are developing I think.
Ok, I agree the git case is where folks may actually be making changes, and I still think it's ok not to automatically "notice" changes in the non-git case. LLVM is big enough that checking for dirty git may not be cheap though. On my Linux system with NVME, it takes ~0.5s after dropping page caches, and ~0.15s cached. On systems with slower disks, virus scanners, etc., it may be a lot worse.
Yeah, I don't think this is particularly important. The main issue with making changes to LLVM is , which prevents the change from being picked up even if you do commit it.
Change:
<ins> // only-x86_64 #![feature(asm)] macro_rules! m { ($in:ident $out:ident $lateout:ident $inout:ident $inlateout:ident $const:ident $sym:ident $pure:ident $nomem:ident $readonly:ident $preserves_flags:ident $noreturn:ident $nostack:ident $att_syntax:ident $options:ident) => { unsafe { asm!("", $in(x) x, $out(x) x, $lateout(x) x, $inout(x) x, $inlateout(x) x, //~^ ERROR asm outputs are not allowed with the `noreturn` option const x, sym x, $options($pure, $nomem, $readonly, $preserves_flags, $noreturn, $nostack, $att_syntax)); //~^ ERROR the `nomem` and `readonly` options are mutually exclusive //~| ERROR the `pure` and `noreturn` options are mutually exclusive } }; } fn main() { m!(in out lateout inout inlateout const sym pure nomem readonly preserves_flags noreturn nostack att_syntax options); } </ins>

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
<ins> // run-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash trait T<const A: usize> { fn l<const N: bool>() -> usize; fn r<const N: bool>() -> bool; } struct S; impl<const N: usize> T<N> for S { fn l<const M: bool>() -> usize { N } fn r<const M: bool>() -> bool { M } } fn main() { assert_eq!(<S as T<123>>::l::<true>(), 123); assert!(<S as T<123>>::r::<true>()); } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
managed to reduce the test case a bit.
Also happens for this code using a function instead of an associated type:
claim
initial example fixed by , associated function fixed by instead
Change:
fn causes_ice(mut l: &mut Sexpression) { loop { match l { <del> &mut Sexpression::Num(ref mut n) => {}, &mut Sexpression::Cons(ref mut expr) => { //~ ERROR cannot borrow `l.0` l = &mut **expr; //~ ERROR cannot assign to `l` </del> <ins> &mut Sexpression::Num(ref mut n) => {}, //[mir]~ ERROR (Mir) [E0384] &mut Sexpression::Cons(ref mut expr) => { //[ast]~ ERROR [E0499] //[mir]~^ ERROR (Ast) [E0499] //[mir]~| ERROR (Mir) [E0506] //[mir]~| ERROR (Mir) [E0384] //[mir]~| ERROR (Mir) [E0499] l = &mut **expr; //[ast]~ ERROR [E0506] //[mir]~^ ERROR (Ast) [E0506] //[mir]~| ERROR (Mir) [E0506] //[mir]~| ERROR (Mir) [E0506] //[mir]~| ERROR (Mir) [E0499] //[mir]~| ERROR (Mir) [E0499] </ins> } }} }

Discussion:
MIR borrowck ICEs when an error involving a region whose EndRegion is missing occurs (this occurs when a region can never end within the function). Instead it should emit a correct diagnostic. This can occur for both free regions (e.g. issue-): And for infinite loops: Causing this ICE:
The ICE here is caused by the assert in this function, : This function finds the (location in the input source code) that a region ends. If you look at the error that the AST borrowck (i.e., older style borrowck) emits, we are basically computing the point where to write that "immutable borrow ends here" message: Right now, there is a kind of complicated assertion. It is saying that one of two things should be: We are in non-lexical mode. In that case, there are no end-regions at all, so we just return . This causes us not to write "immutable borrow ends here". We are in lexical mode, in which case we should have found an statement. These are special statements we insert into the MIR (only in lexical mode) that tell us where the various lexical lifetimes end. The problem is that in cases where the region never properly ends, we won't find an statement. I think what we want to do is rewrite the function a bit. If we are in NLL mode (), then we should always return . Otherwise, check the as we are doing and return if we find something in there, as we are doing now. Otherwise, we want to return the span for the end of the function. This is the new part. As it happens, we can get this by returning : is the MIR for the function we are checking is the span in the source code where the function is defined returning its end point should, I think, give us the behavior we want. So, when we are done, if is , this function should always return for some span, but sometimes it will be the end of the function.
Hi, I want to work on this bug.
Change:
<ins> // compile-flags: --edition=2018 pub use u32; </ins>

Discussion:
Hello, I was working on my toy project here: The project was compiling and running fine at this commit: However, I decided I wanted to move functionality out of and into , so I moved all of it except the declarations, and then tried to compile. This led to the compiler panic. The repro commit for this: I am using CLion, and the command I run is simply . I am pretty new to Rust so it might just be me doing something really wrong, but it'd be great if someone could look into this and advise. Thank you! With : With : EDIT: Updated with last working commit. EDIT2: Posted crash message with --verbose flag and clarified IDE. EDIT3: Added MSVC toolchain error.
I have a PR that will fix the underlying problem, but we need to come up with a reproduction case to avoid regressions in the future.
Removing nomination since a fix is already approved
Thank you so much for the super-fast response! However, I am not at all familiar with rust's compiler code, so if you could tell which part of the code the compiler trips upon, I can try isolating that part of the code to make a smaller reproducible example.
Reduced it down to two files: (replace obvisouly ^^) can be any primtive type as , , , . Haven't managed to get it down to one file sadly :/
is there a problem of adding the test in two files (with )? if not, I could try to work on this as a first issue.
No, that's totally fine. Go for it!
Change:
}; // We can recurse through this terminator. <del> let mut state = state.clone(); </del> <ins> let mut state = state(); </ins> if let Some(place_to_flood) = place_to_flood { state.flood_with(place_to_flood.as_ref(), self.map, ConditionSet::default()); }

Discussion:
File: season two auto-reduced (treereduce-rust): original: 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
cc
I cannot reproduce the original anymore, but does reproduce. The body is impossible because of the where clauses, so no MIR opts should ever run on it... I'll take a look.
I can still reproduce this with the original mvce when I use the flags that I listed.
bisected with searched nightlies: from nightly-2023-09-01 to nightly-2023-10-01 regressed nightly: nightly-2023-09-09 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.8 cc oli was right:
The bisection here isn't useful sadly, but thank you anyways. I took a look and yeah, the issue is what I suspected. () checks whether there are any impossible predicates (like here). It sadly has to filter out "non-global" predicates, which belongs to. It has to do this because of overflows as mentioned above. told me that the new trait solvers non-fatal handling of overflow will allow this to be fixed. But until then, there's nothing we can do. As for getting the code working, the solution here so to avoid these impossible bounds wherever possible. In the example here, that's easy to do, just delete it. In that's a bit more annoying, I don't really see a solution. We could try playing whack-a-mole by trying to make the MIR opts sorta-handle these cases that slip through, but I don't think that's very sustainable. Might work at least for the trivial cases like though, but I don't open PRs for that.
another one
I'm afraid that this has reached stable with 1.78. I couldn't reproduce it with the minimal example in the previous comment, but a crate of mine now fails on stable, but compiled fine on 1.77.2: <details<summaryfull output</summary</detailsThe code responsible for this is fairly simple: Removing that impl makes the crate compile again.

Will we still just wait for the new solver, now that it's a stable-stable regression?
I managed to minimize the example from : (, ICE in release mode)
Change:
<ins> # needs-git-hash include ../tools.mk all: $(BARE_RUSTC) --version --verbose | $(CGREP) -i -e "commit-hash: [0-9a-f]{40}" "commit-date: [0-9]{4}-[0-9]{2}-[0-9]{2}" $(BARE_RUSTDOC) --version --verbose | $(CGREP) -i -e "commit-hash: [0-9a-f]{40}" "commit-date: [0-9]{4}-[0-9]{2}-[0-9]{2}" </ins>

Discussion:
stable is fine: but beta and nightly are no longer showing commit-hash and commit-date information: ` <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
it's weird because the info is still displayed correctly in the very first oneliner-summary, but if there was some tool that reads the data by looking at or we still should display the right thing.
This appears to have been introduced by . The issue is that the macro uses CFGVERDATE/CFGVERHASH which is only set when compiling rustc. One option is to try to share some code with . Another option is to go the other way and get rustc to share some code with .
Mentoring instructions: set in (Maybe we should try to unify those functions so they don't duplicate so much code and problems like this don't happen in the future?)
I think it should be possible to write a run-make test ensuring this works properly.
claim
Hi im starting my journey of contributing to Rust, i found this issue a good starter for myself, do you think you would be open to let me take this chance to get familiar with the code base?
Hey! Go for it!
Alternatively, you could check out . I THINK that might be more straightforward. But I'll let you decide(:
claim
I tried doing this change in Then i did a and tried running this command on the stage2 rustodc But it appears that the commit-hash and commit-date is still unknown. Im wondering if the issue is that is passed as true in This is my first time making changes and testing in this project, please feel free to correct me if im testing / building in the wrong way.
I'd suggest changing to use instead of so it's easier to tell when these variables are unset without having to build a full stage 2 compiler.
Retagging as stable/stable regression, this already shipped in 1.67 as far as I can tell.
Are you still (interested in) working on this issue? I'd like to claim it otherwise.
please go ahead and claim it!
claim
Change:
LL |     if Some(3) == foo {} |                ^^ <del> error: aborting due to 5 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> Some errors have detailed explanations: E0308, E0425. For more information about an error, try `rustc --explain E0308`.

Discussion:
I thought this code would provide one of the nice suggestions that implemented in , but it doesn't. (By the way, making a reference to will give an ICE because of .) () Errors:
Reopening as per
This is fixed in beta now: It is still quite verbose (too many errors), but we lead people in the right direction.

: <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed in
Cc
Related: this code should probably have a suggestion for (): Currently it produces:
Minimized (): I think this might be caused by the lifetimes.
Never mind! This causes it too, with no lifetimes (): EDIT: removed the type aliases EDIT 2: changed to to make it clearer that they don't need to be the same type EDIT 3: shortened names, removed comment
Assigning and removing as .20.3D.20.2E.2E.2E.60.20expression.E2.80.A6) in the prioritization working group.
Further minimized to this (): Having be a or produces the ICE, but making it an owned does not produce the ICE.
causes the operands to be typechecked twice: I think this has side effects that are causing problems by being applied twice. Commenting out the second makes the ICE go away, but I'm not sure what the best approach for a proper fix is. The effect on the UI suite is rather low: (It still emits this error:)
I tried a couple of things but it seems to me that you hit the nail in the head and we just need to remove the branch. this is caused because one side is seen to be while the other is seen to be or (depending on the case). This is a problem because the left hand side expression should in reality be a pattern instead, but there's no utility to build a pattern from an expression: patterns are built during parsing (due to differences like, being a valid thing there). Because of that it'll be very hard to make the suggestion happen for those cases, much harder than for the ones we already handle.
I think I just found a smaller example (granted, it's not valid code any more, but how is one supposed to know that in case of ICE? ;-) ): (If that's not the same error I'm happy to open a new ICE issue, but to me it looks the same, with all the , the panic at and the conditional destructuring in a loop).
Change:
DefStatic(..) => cx.tcx.sess.span_bug(pat_span, "static pattern should've been rewritten"), DefVariant(_, id, _) if *constructor != Variant(id) => None, <del> DefVariant(..) | DefFn(..) | DefStruct(..) => { </del> <ins> DefVariant(..) | DefStruct(..) => { </ins> Some(match args { &Some(ref args) => args.iter().map(|p| &**p).collect(), &None => Vec::from_elem(arity, &DUMMY_WILD_PAT)

Discussion:
compiles fine (other than the dead code warning for ), but is not:
I hit this as well, I would love a fix :+1:
Change:
}; if parser.token != token::Eof { <del> parser.expect_one_of(&[], &[])?; unreachable!(); </del> <ins> return parser.unexpected(); </ins> } Ok(Assert { cond_expr, custom_message })

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
| Scope::Supertrait { ref s, .. } => { scope = *s; } <del> Scope::Root => bug!("In fn_like_elision without appropriate scope above"), </del> <ins> Scope::Root => { // See issue #83907. Just bail out from looking inside. self.tcx.sess.delay_span_bug( rustc_span::DUMMY_SP, "In fn_like_elision without appropriate scope above", ); return; } </ins> } }; // While not strictly necessary, we gather anon lifetimes *before* actually

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
From
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
<ins> // Copyright 2013 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. // xfail-fast // aux-build:issue-8259.rs extern mod other = "issue-8259"; static a: other::Foo<'static> = other::A; fn main() {} </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
Change:
<ins> // Copyright 2013 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. // xfail-fast // aux-build:issue-8259.rs extern mod other = "issue-8259"; static a: other::Foo<'static> = other::A; fn main() {} </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
Change:
<del> Subproject commit 47acece7aa25d7b5edfae0bfd4b94e6e55a7b4b0 </del> <ins> Subproject commit e54c5db4f0edbe51db42d2c3e63e9821537ed4f4 </ins>

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!
Oops, race condition! Noticed you self-assigned this right as I sent a PR for this. ^^
You can assign me if needed.