jiebi/CodeConvo huggingface dataset:
Change:
<del> Subproject commit 8fbb23f2549e75b89967f09b9293607bd3bb96a6 </del> <ins> Subproject commit fc5d0cc583cb1cd35d58fdb7f3e0cfa12dccd6c0 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and nominating for compiler team prioritization.
[triagebot] I never answer to pings from issues like this because they are routinely fixed by people working on the affected tools. shouldn't ping the reviewer in general. If there are issues with a tool upgrade, then ping can happen on the tool upgrade attempt PR.
Change:
#![feature(alloc_layout_extra)] <ins> #![feature(array_chunks)] </ins> #![feature(bool_to_option)] #![feature(bound_cloned)] #![feature(box_syntax)]

Discussion:
In the stdlib I'd like an iterator like chunksexact that yields fixed-sized arrays, using a const usize argument (mostly useful for short arrays). .chunksexactct::<3() .map( a + b + c) Those arrays could allow better optimizations and also better pattern matching. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This also applies to the method on slices.
We should actually be able to implement this and test it out unstably now.
Im willing to give this a shot in the weekend and next week!
assign
So, a simple PoC fails to compile horribly <details<summary<strongBacktrace</strong</summary<p</p</details
Notice that a freestanding function does work:
The more I go into this, the more obstacles I stumble upon. Below a list of all ICE's I encountered:
Keep going on, those bugs/limitations are worth fixing anyway :)
to_array() could be a new function related to take(), it collects the first N items of an iterator into an array of length given as const generic argument (it panics if the iterator isn't long enough). Usable like this (using iterate() from itertools):
EDIT: This is already PR'd:
We need a good built-in static_assert that works with constant generics too :)
Change:
Options: <ins> cargo install </ins> --mode=[system,user,local]   change mode as (system/user/local) -g                           equivalent to --mode=user -G                           equivalent to --mode=system NOTE: <del> This command creates/uses local-level .cargo by default. To create/use user-level .cargo, use option -g/--mode=user. To create/use system-level .cargo, use option -G/--mode=system. </del> <ins> "cargo install" installs bin/libs to local-level .cargo by default. To install them into user-level .cargo,  use option -g/--mode=user. To install them into bin/lib on sysroot, use option -G/--mode=system. </ins> "); }

Discussion:
There's some code for this in cargo now, but it doesn't quite do the right thing. See .
Also worth considering the difference between sysroot and the install prefix - they are not the same. For instance, I never install cargo, always running it out of the build directory, in which case the build directory is sysroot.
I think this is resolved.
Change:
let def_id = body.source.def_id(); debug!(?def_id); <ins> // Optimizing coroutines creates query cycles. if tcx.is_coroutine(def_id) { trace!("Skipped for coroutine {:?}", def_id); return; } </ins> let param_env = tcx.param_env_reveal_all_normalized(def_id); let map = Map::new(tcx, body, Some(MAX_PLACES)); let loop_headers = loop_headers(body);

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. --This code compiles in debug mode, but fails in release mode (): On release mode, it errors with: I bisected it down to this patch causing the issue: cc <!-- 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<summaryBacktrace</summary<p</p</details
label +T-compiler +A-mir-opt +S-has-mcve -needs-triage
Shouldn't this be given a priority? label +P-critical cc cc
This fails to compile with either debug or release mode on stable. That means this isn't a regression, but rather an accidental stabilization. Probably still P-critical though
- good catch, I updated the example to use the dyn trait as suggested by the stable compiler, which passes both debug and release, but fails with nightly release.
This is not an accidental stabilization. This was stabilized in . This is a legitimate misoptimization.
Change:
LL | struct Cl<'a, 'b, 'c, T, U, V, M: ThreeWithLifetime<T, 'a, A=(), B=(), C=(), U, 'b, V, 'c>> { |                                                        ^^ | <del> = note: type arguments must be provided before lifetime arguments </del> <ins> = note: lifetime arguments must be provided before type arguments </ins> error[E0747]: lifetime provided when a type was expected --> $DIR/suggest-move-types.rs:82:56

Discussion:
suggests type parameters should come before lifetime parameters, which is incorrect. The message is emitted here: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I want to try working on this. claim
I've been trying to fix this, but even reversing the arguments to the format didn't seem to do anything. Am I missing something? I also to the error note for testing: And here's the error diff: EDIT: I modified the expected stderr for the test so that it matches how it should look after this is fixed by the way.
I've looked into it a bit more, and it looks like this isn't as simple as I thought at first. I thought it might work if I just reversed the arguments to , but that messes up other things. I think I'll need to rethink this.
Note that I cherry-picked the examples that were incorrect. The diagnostic is correct in other cases. You'll need to investigate a little to work out how best to fix this; one simple solution would be to sort the two with , though I'm not sure if that's the cleanest approach.
Okay, thanks for the info! I'll look into sorting and see if that works :)
I think I've figured out a basic solution. Let me know if there are things I can improve!
Change:
self.trait_def(trait_def_id).has_auto_impl } <del> pub fn generator_layout(self, def_id: DefId) -> &'tcx GeneratorLayout<'tcx> { self.optimized_mir(def_id).generator_layout.as_ref().unwrap() </del> <ins> /// Returns layout of a generator. Layout might be unavailable if the /// generator is tainted by errors. pub fn generator_layout(self, def_id: DefId) -> Option<&'tcx GeneratorLayout<'tcx>> { self.optimized_mir(def_id).generator_layout.as_ref() </ins> } /// Given the `DefId` of an impl, returns the `DefId` of the trait it implements.

Discussion:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:
Change:
#![feature(unboxed_closures)] #![allow(unknown_features)] #![feature(int_uint)] #![feature(on_unimplemented)] <ins> // FIXME(#21363) remove `old_impl_check` when bug is fixed #![feature(old_impl_check)] </ins> #![deny(missing_docs)] #[macro_use]

Discussion:
This code fails to compile: error message: A similar error occurs if is used instead of . However, if you comment out the for loop, the call to works just fine. I thought maybe it had something to do with auto-deref, so I tried dereferencing the iterator: but dumps core: I'm not sure, but this may be related to ? dumps core when I try too. version:
CC
I think the problem is worse than this; trait objects in general don’t seem to be being recognised as implementing their traits: All three fail:
I'm not sure this is a bug at all. You're pretty much asking for an automatic - I did come up with a & -based model that would kinda work for this and IIRC pointed out that object-safe traits would eventually qualify for this. We do have object safety now, so it might be doable, but I wouldn't bet on it making into 1.0. In the meanwhile, does work? If it doesn't, is it just the case of missing in a couple places?
This a particular case of . See comments over there. is leaning towards an opt-in syntax extension that handles the boiler plate code, instead of automatic s by the compiler.
ByRef for trait objects seems to hit the same llvm assertion: output:
Interesting. So if I have a value with type where is a trait, then we can't say that implements in the general case? (Assuming object safety.) So my guess is that can still call because of auto deref? Shouldn't that mean it can work with ? Maybe that is what is about... You have to explicitly deref a to use it in ? (Sorry for all the questions. I'm just confused!)
doing autoderef on the iterator in seems like something reasonable to have. looks like the compiler is mistakenly treating an unsized lvalue as an rvalue, in trans.
On Mon, Jan 12, 2015 at 01:33:08PM -0800, Andrew Gallant wrote: Actually, I believe it works with , but not with the other types.
Just thank you for this issue. It resolves all my problems perfectly!
Change:
match probe.kind { InherentImplCandidate(impl_def_id, ref substs) | ExtensionImplCandidate(impl_def_id, _, ref substs, _) => { <ins> let selcx = &mut traits::SelectionContext::new(self.infcx(), self.fcx); let cause = traits::ObligationCause::misc(self.span, self.fcx.body_id); </ins> // Check whether the impl imposes obligations we have to worry about. let impl_generics = ty::lookup_item_type(self.tcx(), impl_def_id).generics; let impl_bounds = impl_generics.to_bounds(self.tcx(), substs); <del> // FIXME(#20378) assoc type normalization here? // Erase any late-bound regions bound in the impl // which appear in the bounds. let impl_bounds = self.erase_late_bound_regions(&ty::Binder(impl_bounds)); </del> <ins> let traits::Normalized { value: impl_bounds, obligations: norm_obligations } = traits::normalize(selcx, cause.clone(), &impl_bounds); </ins> // Convert the bounds into obligations. let obligations = <del> traits::predicates_for_generics( self.tcx(), traits::ObligationCause::misc(self.span, self.fcx.body_id), &impl_bounds); </del> <ins> traits::predicates_for_generics(self.tcx(), cause.clone(), &impl_bounds); </ins> debug!("impl_obligations={}", obligations.repr(self.tcx())); // Evaluate those obligations to see if they might possibly hold. <del> let mut selcx = traits::SelectionContext::new(self.infcx(), self.fcx); obligations.all(|o| selcx.evaluate_obligation(o)) </del> <ins> obligations.all(|o| selcx.evaluate_obligation(o)) && norm_obligations.iter().all(|o| selcx.evaluate_obligation(o)) </ins> } ObjectCandidate(..) |

Discussion:
(or so niko told me) I believe this code should compile, but it does not compile. Trawling through some logs made Niko think that something wasn't normalized one way or the other, so opening an issue! cc cc

Right now we don't normalize impl bounds during method probing, which means that the winnow stage may not work great when those bounds involve associated types. I think with the new setup we should be able to do this but didn't have time to test. Search for the FIXME in
Change:
.map(|entry| { entry.split(' ').nth(1).expect("every git status entry should list a path") }); <ins> let mut untracked_count = 0; </ins> for untracked_path in untracked_paths { println!("skip untracked path {untracked_path} during rustfmt invocations"); // The leading `/` makes it an exact match against the

Discussion:
The skipped files are files in the repo that are not tracked by git. It looks like they might still get to the "formatted modified file" counter? I have no other changed files in the repo, so I wonder what rustfmt is saying to have formatted here :sweat_smile:
It detects X files modified, but the fact that they are not tracked means that their rustfmt invocation will be skipped.
It's better to give different counts for skipped and formatted files?
Maybe soemthing like "formatted x files, skipped y untracked files" would make more sense.
The number is actually right, but it's the number of the files that have been modified in the current branch compared to the master branch: you have 86 untracked path in this case. Anywa, we can make it more explicit here.
Change:
<ins> error[E0770]: the type of const parameters must not depend on other generic parameters --> $DIR/issue-88997.rs:8:40 | LL | struct Range<T: PartialOrd, const MIN: T, const MAX: T>(T) |                                        ^ the type must not depend on the parameter `T` error[E0770]: the type of const parameters must not depend on other generic parameters --> $DIR/issue-88997.rs:8:54 | LL | struct Range<T: PartialOrd, const MIN: T, const MAX: T>(T) |                                                      ^ the type must not depend on the parameter `T` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0770`. </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. --: 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> // compile-flags: -D warnings --cap-lints allow // check-pass // Regression test for issue #78660 // Tests that we don't ICE when a future-incompat-report lint has // has a command-line source, but is capped to allow fn main() { ["hi"].into_iter(); } </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. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
b = self.infcx.shallow_resolve(b); } <ins> if a == b { return Ok(a); } </ins> match (&a.kind, &b.kind) { (_, &ty::Infer(ty::TyVar(vid))) => { if D::forbid_inference_vars() {

Discussion:
The following takes approximately one year to compile: (This estimate was derived from observing that compile time scales seemingly exponentially in the depth of the instantiated closure. At level 23 it took about 25 seconds, and at 22 only 13. Extrapolating this doubling-per-depth leads us to about a year at level 43 which is depicted above).
Flamegraph:
Yields: cc
Change:
#![allow(rustc::untranslatable_diagnostic)] use either::Either; <ins> use hir::ClosureKind; </ins> use rustc_data_structures::captures::Captures; use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{codes::*, struct_span_code_err, Applicability, Diag, MultiSpan};

Discussion:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or
Change:
StorageLive(_7); _7 = (); _0 = CoroutineState::<(), ()>::Yielded(move _7); <ins> StorageDead(_4); StorageDead(_6); StorageDead(_7); </ins> discriminant((*(_1.0: &mut {coroutine@$DIR/coroutine_tiny.rs:20:16: 20:24}))) = 3; return; }

Discussion:
Reproduces with on commit Remove and add to get a lot of ICEs like this:
So, looks like we should either allow StorageLive on an already live local, or we need to ensure that all locals are explicitly marked StorageDead before returning. No idea how realistic it is to achieve the latter. Cc
Change:
use rustc_infer::infer::{InferCtxt, NllRegionVariableOrigin, RegionVariableOrigin}; use rustc_middle::mir::{ Body, ClosureOutlivesRequirement, ClosureOutlivesSubject, ClosureRegionRequirements, <del> ConstraintCategory, Local, Location, ReturnConstraint, </del> <ins> ConstraintCategory, Local, Location, ReturnConstraint, TerminatorKind, </ins> }; use rustc_middle::traits::ObligationCause; use rustc_middle::traits::ObligationCauseCode;

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: It looks like the error is pointing to the wrong spot in the code and is quite misleading. Ideally the output should mention that is still mutably borrowed because it holds a reference to between loops. Or something, im not actually sure :P I have confirmed that this occurs in both the latest stable (1.62.1) and nightly () <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
With the proposed the output will be like this:
Change:
return; } <ins> // as_slice() must only be called when iter.len() is > 0 because // vec::Splice modifies vec::Drain fields and may grow the vec which would invalidate // the iterator's internal pointers. Creating a reference to deallocated memory // is invalid even when it is zero-length let drop_ptr = iter.as_slice().as_ptr(); </ins> unsafe { // drop_ptr comes from a slice::Iter which only gives us a &[T] but for drop_in_place // a pointer with mutable provenance is necessary. Therefore we must reconstruct

Discussion:
MCVE (could be reduced further): Originally found by miri-test-libstd. See for more. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I suspect this is a regression from (, cc but I have not yet bisected.
claim
I have debug printing for the slice length to and the test prints that the iterator is zero-length, which means a zero-length slice is created. refers to regarding safety requirements, which in turn states Which I interpret as any aligned, non-null pointer is valid for zero-length slices, which includes recently freed allocations. So this seems to be a false positive caused by miri not taking the slice length into account.
That is not the case, unfortunately. Quoting from I am not happy with this rule, but currently, LLVM does not really let us a choice here ().
Added 1.59.0 milestone since that's my understanding of when the regression occurred.
Removing prioritization label as per label -I-prioritize
Change:
use rustc_infer::infer::{ InferCtxt, InferOk, LateBoundRegion, LateBoundRegionConversionTime, NllRegionVariableOrigin, }; <del> use rustc_infer::traits::ObligationCause; </del> use rustc_middle::mir::tcx::PlaceTy; use rustc_middle::mir::visit::{NonMutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::AssertKind;

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
build_base: opt_path(matches, "build-base"), stage_id: matches.opt_str("stage-id").unwrap(), mode: matches.opt_str("mode").unwrap().parse().expect("invalid mode"), <ins> suite: matches.opt_str("suite").unwrap(), </ins> debugger: None, run_ignored, filter: matches.free.first().cloned(),

Discussion:
When compiletest fails, it prints an error summary like this at the end: However, there is one very important bit of information that I cannot gleam from this information: what are the host and target architectures that were tested! Figuring this out requires scrolling up quite a bit to where this test beings (and carefully not scrolling up too far because then one might look at the wrong test). See for an example where this confused people. I have also been confused by this multiple times in the past, e.g. using the name of the CI runner to incorrectly deduce what the architecture(s) are (and not realizing that some of our runners run tests for quite a few different targets). So I think in case of a failure, that summary at the end should repeat the important information that is printed at the top of the test run:
Cc
And also it would be nice if when it ignored a test because it was the wrong platform, it showed some indication of that, because otherwise it looks like it ran the test and it passed. Perhaps show a question mark ()? (We already use for tests that were ignored because they were already run and passed.)
AFAIK should already be used for all kinds of "ignored", including directives.
Turns out these messages are printed by bootstrap, not compiletest: However, detecting failures and exiting is done a few layers deeper: In case of failure, never returns or unwinds (except if fail-fast is off). I am not sure how to best adjust this to print an error before exiting (or to always print an error after the process finished, whether it succeeded or failed). any advice? If we just want this to happen when fail-fast is off, that would be easy, but I am not sure if that ever applies.