jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass // // rust-lang/rust#74933: Lifetime error when indexing with borrowed index use std::ops::{Index, IndexMut}; struct S(V); struct K<'a>(&'a ()); struct V; impl<'a> Index<&'a K<'a>> for S { type Output = V; fn index(&self, _: &'a K<'a>) -> &V { &self.0 } } impl<'a> IndexMut<&'a K<'a>> for S { fn index_mut(&mut self, _: &'a K<'a>) -> &mut V { &mut self.0 } } impl V { fn foo(&mut self) {} } fn test(s: &mut S, k: &K<'_>) { s[k] = V; s[k].foo(); } fn main() { let mut s = S(V); let k = K(&()); test(&mut s, &k); } </ins>

Discussion:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
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
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing.

Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.
Change:
/// [`Err`]: ../../std/result/enum.Result.html#variant.Err /// [`panic`]: ../../std/macro.panic.html /// <ins> /// # Panics /// /// This function may panic on some platforms if a thread attempts to join /// itself or otherwise may create a deadlock with joining threads. /// </ins> /// # Examples /// /// ```

Discussion:
Considering following snippets: Currently on linux, the spawned thread will just panic at option unwrap which happen inside std library: It makes no sense to call join inside the associated thread, but a meaningless panic is sure not the good way to handle this situation. Maybe we should return an error which contains the join handle, so the caller can recover the failure. If panic is preferred, then a more friendly message should be good for users.
This seems like a reasonable-ish panic, though it would perhaps be better to have the error be returned within the result, though the current behavior is as documented, so I think it's reasonable.

Gives (on playground): There are two problems here: error message is absolutely terrible. the sake of safety, we might need to do something other than panic if this happens. This could affect crates which require that join() never returns early, like crossbeam.
Possibly in or otherwise, but this seems to have since been fixed -- this now deadlocks.
Change:
|             ^^^^ |             | |             not a type <del> |             help: try using the variant's enum: `Option` </del> <ins> |             help: try using the variant's enum: `std::option::Option` </ins> error: aborting due to 7 previous errors

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
ImplTraitContext::disallowed(), None, )); <del> let args = args.iter().map(|x| self.lower_expr(x)).collect(); </del> <ins> let args = self.lower_exprs(args); </ins> hir::ExprKind::MethodCall(hir_seg, seg.ident.span, args) } ExprKind::Binary(binop, ref lhs, ref rhs) => {

Discussion:
See:
for future reference: is referencing my PR which changed the r-value temporary rules with respect to the temporaries in the of
Even beside the part the loop desugaring is so complex. It would be nice to document what every employed trick changes compared to the naive desugaring.
PR itself was motivated (or at least spawned off of) PR . I'm actually trying to find out what the actual motivation for the described change was. The change, as described, was that the temporaries within would previously live until the end of the enclosing block. So if you consider the following code (): which, when it is accepted by the compiler (as written it requires NLL), it should print this: notably, we drop all of {, , } immediately after the for-statement, but before the at the end of the block. The breakage I would be concerned about, if we made for-loops no longer a terminating scope for their , is that all of the temps would live until the end of the block, and thus the drops of {, , } would happen after the "end of enclosing block", which would be an observable change. has relayed to me in private conversation that they tried examples like this under variants of their desugaring and did not witness any change in behavior. Our best guess as to why this is, is because the desugaring is, in the end, turning into a which is itself a terminating scope for the temporaries in the -input, and so you don't need to recreate such an effect by other means.
Note: it is nonetheless possible that the distinction here is more subtle and my above example isn't quite right. in particular, I'm a little worried that there may have been a reason that the example from PR puts the for-expression in the tail expression of a block, and that examples that don't take similar care might fail to pick up on a relevant distinction here...
Change:
// Getting this wrong can lead to ICE and unsoundness, so we assert it here. for arg in substs.iter() { let allowed_flags = ty::TypeFlags::MAY_NEED_DEFAULT_CONST_SUBSTS <del> | ty::TypeFlags::STILL_FURTHER_SPECIALIZABLE; </del> <ins> | ty::TypeFlags::STILL_FURTHER_SPECIALIZABLE | ty::TypeFlags::HAS_ERROR; </ins> assert!(!arg.has_type_flags(!allowed_flags)); } substs

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. --: Also tested on the playground: . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details modify labels: +A-const-generics +F-genericconstexprs +requires-nightly
Change:
<ins> trait Adapter { const LINKS: usize; } struct Foo<A: Adapter> { adapter: A, links: [u32; A::LINKS], // Shouldn't suggest bounds already there. //~^ ERROR: no associated item named `LINKS` found } fn main() {} </ins>

Discussion:
Given the following test and nightly 2020-01-12: I get that this is not supposed to work without const generics, but the error message suggestion is very funny: With const generics:
Weird suggestion is on current stable as well.
The ICE component is fixed by , the diagnostics issue remains ()
I think it's another example of now.
Change:
<ins> error[E0594]: cannot assign to `*foo`, which is behind a `&` reference --> $DIR/issue-92015.rs:6:5 | LL |     let foo = Some(&0).unwrap(); |         --- help: consider changing this to be a mutable reference: `&mut i32` LL |     *foo = 1; |     ^^^^^^^^ `foo` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This panic appears to be fixed in PR . Duplicate of ?
Perhaps worth adding a regression test for this issue in particular.
Sounds like a good idea- I'll get going on that
claim
Change:
let mut pcx = PatternContext::new(tcx, param_env_and_substs, tables); let result = pcx.lower_pattern(pat); if !pcx.errors.is_empty() { <del> span_bug!(pat.span, "encountered errors lowering pattern: {:?}", pcx.errors) </del> <ins> let msg = format!("encountered errors lowering pattern: {:?}", pcx.errors); tcx.sess.delay_span_bug(pat.span, &msg); </ins> } debug!("Pattern::from_hir({:?}) = {:?}", pat, result); result

Discussion:
I encountered an internal compiler error (on stable, beta and nightly) in my code and i could reduce it to this: . I would expect that this program won't compile because of the non-const fn in a const declaration. Nightly rightly gives an error message to that effect and panics, stable just panics. Stacktrace:
No ICE in current stable
But using a random non-const-fn ICEs: cc
Ah, CTFE errors are supposed to be silently ignored.
Change:
} } <del> let length = place.projections.len().min(truncated_length); place.projections.truncate(length); </del> place }

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 this happen: no error Instead, this happened: rustc 1.55.0-nightly 2018 edition rustc 1.55.0-nightly 2021 edition <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
); err.note( "for more information on higher-ranked polymorphism, visit  <del> https://doc.rust-lang.org/nomicon/hrtb.html", </del> <ins> https://doc.rust-lang.org/nomicon/hrtb.html", </ins> ); } _ => {}

Discussion:
In case there is an undeclared lifetime in an ADT deriving a wrong help message is emited causes the following error thx, bye
There are two things here: 1) the suggestion should try and identify spans coming from macro expansion and not suggest changes 2) in this case expands to the following: Note the param, which could avoid having any lifetimes and thing would work correctly. We can probably change the desugaring to not specify the lifetime and then we would avoid the second unnecessary duplicated error. would you happen to know if there's any clear negative in doing 2 above and if not, point me in the right direction in to make that change?
I believe that we can't remove the explicit lifetime here. This would allow for even if is only implemented for .
Change:
} PatternKind::Range { ref lo, ref hi, ref end } => { <del> match range_covered_by_constructor( </del> <ins> match constructor_covered_by_range( </ins> cx.tcx, pat.span, constructor, lo, hi, end.clone() ) { Ok(true) => Some(vec![]),

Discussion:
With rust nightly compiler, the result on the screen is even though the compiler warning that 11 case is unreachable. Link to rust playground:
Change:
} impl<'p, 'tcx> MatchVisitor<'_, 'p, 'tcx> { <del> fn check_patterns(&self, pat: &Pat<'_>) { </del> <ins> fn check_patterns(&self, pat: &Pat<'_>, rf: RefutableFlag) { </ins> pat.walk_always(|pat| check_borrow_conflicts_in_at_patterns(self, pat)); <del> check_for_bindings_named_same_as_variants(self, pat); </del> <ins> check_for_bindings_named_same_as_variants(self, pat, rf); </ins> } fn lower_pattern(

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 output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
t!(fs::create_dir_all(&out_dir)); // http://llvm.org/docs/CMake.html <del> let root = if self.emscripten { "src/llvm-emscripten" } else { "src/llvm-project/llvm" }; </del> let mut cfg = cmake::Config::new(builder.src.join(root)); let profile = match (builder.config.llvm_optimize, builder.config.llvm_release_debuginfo) {

Discussion:
fortunately: cc
Some potentially useful extra info:
backtrace from running under in details block: <details</details
hmm for some reason this system is using a with ; i wonder if that is relevant... but that should only affect the bootstrap behavior, not the number of codegen-units used in the final build, right? I guess I should double-check this against a nightly that I download via , just to be sure...
yeah okay this doesn't occur on a nightly I downloaded via , ... grr...
And unfortunately the debug does not replicate after I do a rebuild of LLVM with in the ... (I'll have to see if the problem was actually due to some other sort of staleness of my LLVM object files...?)
can't replicate anymore. :( I have a sneaking suspicion that this might be due to my build of LLVM being stale in some way? not sure. I sort of wish I had taken a snapshot of my directory structure at the time before I cleaned it as part of trying to test out alternate configurations...
Fwiw I have the same issue locally
It is LLVM, I had these failures (all segfaults, i.e. "signal 11"): And they were fixed by (LLVM rebuilt a few of its files). We should keep track of the fact that we don't detect LLVM needing a rebuild correctly. IMO should contain the git hash of the submodule. The rebuild is really fast, especially after small deltas, and it's better than weird crashes.
Same issue here, with two separate rustc checkouts. Currently rebuilding LLVM to see if that helps. (Deleting that file triggered a complete rebuild.)
Confirmed that rebuilding LLVM fixes the problem.

I've spent the past few hours looking through documentation for how to build rustc with a patched LLVM without success. Currently, the best I'm at is: And then build with: But even that doesn't rebuild anything unless I . Which completely loses incremental compilation results. Is there any way to make this development workflow better? Rebuilding from scratch at every change is… painful.
You need to modify to rebuild LLVM. (tagging this issue as a documentation problem.)
Thanks! Leaving open for the documentation problem :)

I Changed the submodule, commited the changes; Commited the submodule commit change in the rust repo; Built. Rustbuild did not seem to pick up on the submodule being changed.
LLVM rebuild is currently triggered only when contents of and stamps disagree (including being non-existent), so it's always manual. Full checking of something in LLVM being outdated is not performed because it's expensive thing to do on every build, but the submodule state check can be performed I guess.
Change:
<ins> // Regression test for issue #121424 #[repr(C)] struct MySlice<T: Copy>(bool, T); type MySliceBool = MySlice<[bool]>; const MYSLICE_GOOD: &MySliceBool = &MySlice(true, [false]); //~^ ERROR the trait bound `[bool]: Copy` is not satisfied //~| ERROR the trait bound `[bool]: Copy` is not satisfied fn main() {} </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

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: writeimmediatetomplace: invalid ScalarPair layout: TyAndLayout {', 'error: internal compiler error: writeimmediatetomplace: invalid ScalarPair layout: TyAndLayout {' File: --snippet: 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<!-- query stack: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Change:
[[package]] name = "measureme" <del> version = "9.1.2" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "78f7a41bc6f856a2cf0e95094ad5121f82500e2d9a0f3c0171d98f6566d8117d" dependencies = [ "log", "memmap2", "parking_lot 0.11.2", "perf-event-open-sys", "rustc-hash", "smallvec", ] [[package]] name = "measureme" </del> version = "10.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bd460fad6e55ca82fa0cd9dab0d315294188fd9ec6efbf4105e5635d4872ef9c"

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!
Probably a missing join (these tests are a bit random, now that we have preemption).
Change:
/// /// Example: /// <del> /// ``` </del> <ins> /// ```ignore(cannot-test-this-because-non-exported-macro) </ins> /// let letters = map!{"a" => "b", "c" => "d"}; /// ``` ///

Discussion:
At present, doctests aren't run on macros that are not annotated with . After , it will become possible to fix this problem. However, doing so will cause tests to run that were skipped previously to run, which will likely cause test failures and may mess up people's CI. It might be helpful to provide some form of warning period first. The relevant code is here: Fixing this issue technically just requires removing that special case. However, things are complicated by the fact that this will cause people's tests to suddenly fail. I'm not really sure how we should handle that. do you have any ideas? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also https://rust-
I think we should just change this; it's no different than in that the code was already broken before and we just didn't happen to run it. If you're really worried we can do a crater run but I would honestly be ok with just landing this.
label +E-easy +E-mentor
Looks like accidentally prevented these doctests from being run even if is passed :(
claim
FYI, rayon has an internal macro with an example that wasn't ready to be treated as a test: ... discovered by failing in a .
Hmm, I'm not even sure how to turn that into a working doctest, because the macro isn't exported. The in is also telling -- then what's the point?
Change:
cfg_if! { if #[cfg(target_pointer_width = "16")] { <del> let heap_buf = BufT::with_capacity(alloc_len); </del> <ins> let mut heap_buf = BufT::with_capacity(alloc_len); </ins> let scratch = heap_buf.as_uninit_slice_mut(); } else { // For small inputs 4KiB of stack storage suffices, which allows us to avoid

Discussion:
Run Or And you'll get this diagnostic (cargo miri setup makes it a warning, lol): I don't know what effect this has at runtime but it can't be good.
It's worse than one might think, because many AVR microarchitectures, including the atmega328 we nominally support, have only 2KiB of SRAM, which means that this line is literally impossible:
these targets should probably use some of the code in with perhaps a few more tweaks.
Good to know, 16-bit wasn't something we had in mind during development, in terms of less standard targets, we did test big endian with miri. I agree with the code in would be a better fit for such targets. What kind of tweaks did you have in mind?
There are other places in driftsort and ipnsort that use stack arrays, e.g: They are all size bound to <= 4KiB through various means, but still a poor fit for tiny chips.
I think that's necessary, I don't believe driftsort could ever meaningfully run on machines this small.
You already figured it out: dropping all the stack arrays to the absolute minimum. Note that you are not obligated to fix these targets, as usual.
I think it should be a single additional in the impl, so I don't mind doing it.
Yeah, we'd get CI failures way too often if we errored on warnings for tier 3 targets.
Related:
Who is using Tier 3 targets in CI?
Miri is, by running a test with . We should probably change that.
Thinking a bit more about it, is there any scenario where you'd compile Rust for 16-bit targets and don't want to use ? Independent of sort. I'd think that such targets are always binary-size limited and welcome any reduction of it.
Change:
<ins> #![feature(inline_const_pat)] //~^ WARN the feature `inline_const_pat` is incomplete fn uwu() {} fn main() { let x = []; match x[123] { const { uwu } => {} //~^ ERROR `fn() {uwu}` cannot be used in patterns _ => {} } } </ins>

Discussion:
(note: this is very similar to but it does appear to be a different ICE) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label +requires-nightly +F-inlineconstpat +requires-incomplete-features

<!-- 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 label +requires-nightly +F-inlineconstpat +requires-incomplete-features