jiebi/CodeConvo huggingface dataset:
Change:
} fn main() { <del> let ex = |x| { //~ ERROR type annotations needed let_(add(x,x), |y| { </del> <ins> let ex = |x| { let_(add(x,x), |y| { //~ ERROR type annotations needed </ins> let_(add(x, x), |x|x)})}; }

Discussion:
This compiles just fine: But this gives a compiler error: It seems really weird that the second statement is affected like this? Empty project (created with ), unmodified (so no extra dependencies): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is actually that the first statement has type error, but somehow the error is reported to the second statement. The first statement alone reports the error correctly and by fixing the error, the following compiles fine
This happens on Nightly and on Stable.
Labeling as this was a regression introduced by 1.41.0.
Assigning .
Problem seems to be that we always assume the last closure was the source of the inference failure
Just sticking a return after is enough to get the correct diagnostic in this specific instance. However, we clearly need to be smarter than that, as in a sequence of closures, any of them could be the source of an inference error (current implementation always assumes last, just adding a return always assumes first).
Definitely not the case - looking into some alternative fixes. claim
Ok this is even more subtle than I first thought. There's just far too much ambiguity here for this diagnostic code to produce a sensible suggestion. Any time a sub-expression/local pattern/argument pattern/closure's type contains the inference target it immediately becomes a candidate for suggesting on. In this case though, the inference target is , so any code that has anything to do with strings will trip the diagnostic...
Compiling the above results in this - clearly the has nothing to do with the error...
I have a similar message to: But what I don't understand is: why does it complain it can't infer the type if it clearly knows the type?
Change:
/// with `0` executions. /// /// If there are no live `Counter` `Coverage` statements remaining, we remove <del> /// dead `Coverage` statements along with the dead blocks. Since at least one </del> <ins> /// `Coverage` statements along with the dead blocks. Since at least one </ins> /// counter per function is required by LLVM (and necessary, to add the /// `function_hash` to the counter's call to the LLVM intrinsic /// `instrprof.increment()`).

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
<ins> // Check that `*y` isn't borrowed after `y = y`. // check-pass fn main() { let mut x = 1; { let mut y = &mut x; y = y; y; } x; { let mut y = &mut x; y = y; y = y; y; } x; } </ins>

Discussion:
Hey Folks, So, I've been fuzz testing nightly using a range of generated programs and am digesting the findings. This one stood out to me: This currently reports an E0505 on the playground and Rust nightly. However, removing the nop and its fine. This feels like a bug to me ... thoughts?
I think this is technically a reborrow () rather than a no-op, because the lhs and rhs are both known to be . Though this might be the first time I've ever seen a reborrow cause fewer programs to compile versus a move! (amusingly, though, the MIR is simply ) Edit: nope, there's more to it than that. If you explicitly write , it compiles!
Ok, have found some more related cases: Above gives and . Above gives and .
Discussed in lang team pre-triage meeting. Maybe you'd be game to investigate and take a look at what's happening here?
Change:
} } <del> fn find_field(tcx: TyCtxt<'_>, (def_id, ident): (DefId, Ident)) -> Option<FieldIdx> { let adt = tcx.adt_def(def_id); if adt.is_enum() { return None; } adt.non_enum_variant().fields.iter_enumerated().find_map(|(idx, field)| { if field.is_unnamed() { let field_ty = tcx.type_of(field.did).instantiate_identity(); let adt_def = field_ty.ty_adt_def().expect("expect Adt for unnamed field"); tcx.find_field((adt_def.did(), ident)).map(|_| idx) } else { (field.ident(tcx).normalize_to_macros_2_0() == ident).then_some(idx) } }) } </del> #[derive(Clone, Copy)] struct NestedSpan { span: Span,

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'forcing query with already existing '', 'thread 'rustc' panicked at 'forcing query with already existing '' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [findfield] find the index of maybe nested field in [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to :thinking:
WG-prioritization assigning priority (). cc: + for label -I-prioritize +P-medium
I'm going to fix it in (still WIP), where the query will be removed.
Testing out on this issue:
I seems like does not have proper or impls, possibly due to the differing . Are you familiar with that part of spans?
Change:
for (var crate in rawSearchIndex) { if (!rawSearchIndex.hasOwnProperty(crate)) { continue; } <ins> searchWords.push(crate); searchIndex.push({ crate: crate, ty: 1, // == ExternCrate name: crate, path: "", desc: rawSearchIndex[crate].doc, type: null, }); </ins> // an array of [(Number) item type, //              (String) name, //              (String) full path or empty string for previous path,

Discussion:
E.g. doesn't show the crate.
ccing myself, will have a look at this in the next week or so.
cc me
Triage: searching for libc doesn't show libc.
Hmm, I deliberately removed the search-index entry in because it was .
Change:
#traits-as-parameters", ); } <ins> (ty::Param(p), ty::Closure(..) | ty::Generator(..)) => { let generics = self.generics_of(body_owner_def_id); let p_span = self.def_span(generics.type_param(p, self).def_id); if !sp.contains(p_span) { db.span_label(p_span, "this type parameter"); } db.help(&format!( "every closure has a distinct type and so could not always match the  caller-chosen type of parameter `{}`", p )); } </ins> (ty::Param(p), _) | (_, ty::Param(p)) => { let generics = self.generics_of(body_owner_def_id); let p_span = self.def_span(generics.type_param(p, self).def_id);

Discussion:
Minimal example: The error is technically correct. I specified, that I want a box of F, but I create a closure. Because F is generic, it is caller-chosen and I create a new closure, which has a different type. Still, it took me quite some time to find out what was going on in the more complicated real code. I think that it would help to add a note here explaining, that each closure has a different type, and that the inner closure does not match the type F exactly. Maybe additionally a hint could be , stating to use instead (i.e. the traits F is bound to).
Current output: It doesn't handle the closure case in any special way, and it should.
I’m experiencing the same problem
Change:
let image_src = src.join("save-analysis"); let dst = image.join("lib/rustlib").join(target).join("analysis"); t!(fs::create_dir_all(&dst)); <ins> println!("image_src: {:?}, dst: {:?}", image_src, dst); </ins> cp_r(&image_src, &dst); <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")

Discussion:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .
Change:
"hermit-abi", "libc", "miniz_oxide", <del> "object 0.32.2", </del> <ins> "object 0.36.0", </ins> "panic_abort", "panic_unwind", "profiler_builtins",

Discussion:
The relevant commit seem to be located at <details<summaryError</summary<p</p</details
Ah. cc
Ah, this was fixed in
Okay, it seems like this is just a misunderstanding. keywords cannot be searched ...
This won't be actually fixed in std until lands.
Change:
let size = size.try_eval_target_usize(self.tcx(), self.elaborator.param_env()); self.open_drop_for_array(*ety, size) } <del> ty::Slice(ety) => self.open_drop_for_array(*ety, None), </del> <ins> ty::Slice(ety) => self.drop_loop_pair(*ety), </ins> _ => span_bug!(self.source_info.span, "open drop from non-ADT `{:?}`", ty), }

Discussion:
Attempting to compile this code causes extremely large memory usage by rustc. By experimentation, the important features of the code are: large , the element type needs to have drop glue, and the drop can't be skipped with or some other mechanism. It also must be a program, not a library function. The problematic compiler invocation: . I expected to see this happen: The compiler memory usage shouldn't run away due to large ; in fact the compiler memory usage should be almost entirely independent of for this program. Instead, this happened: When is large, uses a lot of memory and takes a long time. I have not successfully compiled the above program with the given of 64M. I repro'd this on , , and finally: (I did not capture a compiler backtrace.) I surmise that there's a correlation between and compiler behavior but I haven't explored it beyond verifying a small doesn't repro the bad behavior. I thought perhaps this program tries to use the stack for the slice-array cast, and somehow the compiler is getting stuck on such a large stack frame. Thankfully, this is ruled out by checking that does indeed do the slice-array cast entirely using pointers. So the compiler shouldn't "see" how big the array is; it's behind a pointer. Appending to bypasses the issue, so it appears to be drop glue for the box which causes the problem. I don't see a particular reason why the drop glue for this type should be problematic; it should be no different than dropping the initialized part of a large . </p</details
is what shows up in logging right before hanging + memory explodes seems to be the culprit. ...
Change:
# If this file is modified, then llvm will be forcibly cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2013-12-18 </del> <ins> 2013-12-29 </ins>

Discussion:
Introduced by . This is because we now use to build but it defaults to soft float for all arm which is wrong for gnueabihf/eabihf. This is fixed in upstream llvm to choose the right float abi based on the target. This will no longer be an issue once we update llvm.
Change:
<ins> error[E0282]: type annotations needed --> $DIR/issue-105608.rs:13:22 | LL |     Combination::<0>.and::<_>().and::<_>(); |                      ^^^ cannot infer type of the type parameter `M` declared on the associated function `and` | help: consider specifying the generic argument | LL |     Combination::<0>.and::<_>().and::<_>(); |                         ~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>

Discussion:
Continuation of . I minimized this together with thank you for your help and originally finding the issue! <!-- 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. --: The first and most relevant delayed bug: All the delayed bugs and the usual backtrace: <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed the the PR: searched nightlies: from nightly-2021-01-01 to nightly-2022-12-12 regressed nightly: nightly-2022-11-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
self.try_fold(init, ok(fold)).unwrap() } <del> unsafe fn __iterator_get_unchecked(&mut self, idx: usize) -> <I as Iterator>::Item where Self: TrustedRandomAccess, { // SAFETY: the caller must uphold the contract for // `Iterator::__iterator_get_unchecked`. unsafe { try_get_unchecked(&mut self.iter, idx) } } </del> } #[unstable(issue = "none", feature = "inplace_iteration")]

Discussion:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.
Change:
p!(print(data)) } } <del> ty::Placeholder(placeholder) => p!(write("Placeholder({:?})", placeholder)), </del> <ins> ty::Placeholder(placeholder) => match placeholder.name { ty::BoundTyKind::Anon(_) => p!(write("Placeholder({:?})", placeholder)), ty::BoundTyKind::Param(_, name) => p!(write("{}", name)), }, </ins> ty::Alias(ty::Opaque, ty::AliasTy { def_id, substs, .. }) => { // We use verbose printing in 'NO_QUERIES' mode, to // avoid needing to call `predicates_of`. This should

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 can't reproduce this? On master, that is.
Ah oops, looks like I minimized wrongly, give me a sec...
This should do: `
Minimized -- PR coming up.
Change:
use rustc_middle::ty::{self, Ty}; use rustc_span::source_map::Span; use rustc_target::spec::abi::Abi; <ins> use rustc_trait_selection::traits; </ins> use rustc_trait_selection::traits::error_reporting::ArgKind; use rustc_trait_selection::traits::error_reporting::InferCtxtExt as _; use std::cmp;

Discussion:
Repro: Output:
cc
What's causing this is that we currently inspect the obligations in scope for obligations, but in this case the obligation is (which implies a obligation as a supertrait). This is expected but unfortunate, yes. We could probably fix this particular case in a relatively straightforward way by trying to upcast each pending obligation to a obligation.
I imagine that atm this could be worked around by changing: to
Today, this gives a completely different error about not implementing ...
Updated code to not give the unrelated error (by removing bounds everywhere), still gives the type must be known error.
This comes up for me fairly regularly. It would be really nice to fix it. (e.g., it came up recently in )
We discussed this in the types team 'backlog bonanza' meeting today. Our conclusion was that this is a "nice to have" and that directly fixing this issue felt like a types team FCP, because it's a tweak to the inference rules. TL;DR right now we say If there is some trait obligation , then we take the args from it seems reasonable to say If there is some trait obligation that implies (through the "invariants", in terms) , then we take the args from that would fix this example (types team FCP would be required). However, I believe that beyond this specific example, most people who wind up here are trying to do something a bit more sophisticated, such as having an argument that might be a closure but might not, or have extended varieties of closures (). It is possible that just making the above change would fix those problems, but it's likely that further changes would be required. Those scope feels like a lang-team initiative. Still may be worth making this change just to screen out the easy cases, mind you!
Change:
<ins> // run-rustfix trait O { type M; } trait U<A: O> { const N: A::M; } impl<D> O for D { type M = u8; } impl<C: O<M = u8>> U<C> for u16 { const N: C::M = 4u8; //~ ERROR mismatched types } fn main() {} </ins>

Discussion:
Repro: This caused E0277 "the trait bound is not satisfied" error: The error doesn't make sense because is obviously . It seems the associated const type is evaluated before the generic bounds are , causing this error. Changing both and to makes the error go away. Reproducible on all 3 versions on playground (1.23.0, 1.24.0-beta, 1.25.0-nightly).
This exact issue just occured to and me when trying to use associated constants to create a constant struct in a library with user-provided data (without const fns) (actual use case: ). A minimized examples is this (): Error: The interesting thing is that even though both bounds are specified, the compiler doesn't seem to take them into account. Edit: The issue is not using a trait with an associated type and const as generic bound. Instead the problem is implementing a trait with an associated type and const in general:
I ran into the same problem. It's also in 1.26 stable. Here's a further minimized example (): We can also use the type parameter in the trait rather than the type (): Both code fragments give an error saying that in the blanket impl, Rust cannot figure out that implements and : Note that in both cases, if you remove the constraint on the quantified type , the error about goes away! This is very strange. However, like in , the error message stays. The problem goes away if you declare the type of in to be , rather than some type that is computed potentially based on parameters. I'm not familiar with the compiler internals, but my hypothesis is that associated types and constants depending on a type parameter are not evaluated properly in the constant expression evaluator. In this case, it's associated types that do not reduce well: forces Rust to do some fancy type of computation at compile time in order to type check, but there's a bug in the code for such computations. I feel there are a couple of different issues in the same spirit: In , Rust is trying to check two types against each other, which forces it to simplify the type . This fails. The error message shows that Rust cannot decide that , even though was in the where clause. Same in , where they get a warning (!) about a "constant evaluation error".

In , the same happens but with a consteval that uses a different trait fn.
Copying over my minimal example from as another data point (): Here I've a supertrait to my trait to get rid of the issue but it still can't determine the required trait implementation (of my trait in this case) to make this work.
All of these cases now compile, except for , which has a type error: Current output: The correct code would be The outstanding work would be providing a suggestion explaining what "consider constraining the associated type to " means. This will be hard to do given the different cases that need to be accounted for, for the case above you need to move the constraint to , for example (although that's not needed, just nicer stylistically).