jiebi/CodeConvo huggingface dataset:
Change:
<ins> trait Output<'a> { type Type; } struct Wrapper; impl Wrapper { fn do_something_wrapper<O, F>(self, _: F) //~^ ERROR the trait bound `for<'a> F: Output<'a>` is not satisfied //~| ERROR the trait bound `for<'a> F: Output<'a>` is not satisfied where F: for<'a> FnOnce(<F as Output<'a>>::Type), //~^ ERROR the trait bound `F: Output<'_>` is not satisfied //~| ERROR the trait bound `F: Output<'_>` is not satisfied { } } fn main() { let mut wrapper = Wrapper; wrapper.do_something_wrapper(|value| ()); //~^ ERROR expected a `FnOnce } </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<strongICE location label +F-unboxedclosures
Regression in nightly-2024-03-22
Minimized: <details<summaryError output</summary</details labels -F-unboxed_closures
duplicate of ?
it would be nice if you could check the bugtracker before posting something, as right now about 30-50% of your bugreports are just re-reports of ices we already know about it seems :upsidedownface:

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: relating different kinds: (Alias(Projection, AliasTy { args: [?3t, !101.Named(DefId(0:16 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::{impl}::dosomethingwrapper::'), "'"), i32], defid: DefId(0:6 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::Output::Type), usealiastynewinstead: () }),) !71.Named(DefId(0:16 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::{impl}::dosomethingwrapper::'), "'")', 'error: internal compiler error: relating different kinds: (Alias(Projection, AliasTy { args: [?3t, !101.Named(DefId(0:16 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::{impl}::dosomethingwrapper::'), "'"), i32], defid: DefId(0:6 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::Output::Type), usealiastynewinstead: () }),) !71.Named(DefId(0:16 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::{impl}::dosomethingwrapper::'), "'")' File: --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<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate -- label +F-unboxedclosures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Regression in nightly-2024-02-15 cc :sweat_smile:
an ICE in the middle of constructing an error, these can usually be solved with some tainting, I'll investigate
I can take a look at this since it's been a month hehe claim
Change:
<del> //! Note: most of the tests relevant to this file can be found (at the time of writing) in //! src/tests/ui/pattern/usefulness. </del> <ins> //! Note: tests specific to this file can be found in: //!     - ui/pattern/usefulness //!     - ui/or-patterns //!     - ui/consts/const_in_pattern //!     - ui/rfc-2008-non-exhaustive //!     - probably many others //! I (Nadrieril) prefer to put new tests in `ui/pattern/usefulness` unless there's a specific //! reason not to, for example if they depend on a particular feature like or_patterns. </ins> //! //! This file includes the logic for exhaustiveness and usefulness checking for //! pattern-matching. Specifically, given a list of patterns for a type, we can

Discussion:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim
Change:
fn parse_initializer(&mut self, eq_optional: bool) -> PResult<'a, Option<P<Expr>>> { let eq_consumed = match self.token.kind { token::BinOpEq(..) => { <del> // Recover `let x <op>= 1` as `let x = 1` </del> <ins> // Recover `let x <op>= 1` as `let x = 1` We must not use `+ BytePos(1)` here // because `<op>` can be a multi-byte lookalike that was recovered, e.g. `➖=` (the // `➖` is a U+2796 Heavy Minus Sign Unicode Character) that was recovered as a // `-=`. let extra_op_span = self.psess.source_map().start_point(self.token.span); </ins> self.dcx().emit_err(errors::CompoundAssignmentExpressionInLet { span: self.token.span, <del> suggestion: self.token.span.with_hi(self.token.span.lo() + BytePos(1)), </del> <ins> suggestion: extra_op_span, </ins> }); self.bump(); true

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --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<!-- query stack: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.
Change:
age: u32, } fn main() { let d = Dog { name: "Rusty".to_string(), age: 8 };

Discussion:
I tried this code: I expected to see this happen: A suggestion to change to Instead, this happened: A suggestion to change to (note the extra comma!) With the comma at the end, I get a parser error and a suggestion to remove the comma. Nightly on playground: 1.49.0-nightly (2020-10-27 )
modify labels: +A-diagnostics
Change:
<ins> // check-pass // incremental #![feature(lint_reasons)] #![warn(unused)] struct OneUnused; struct TwoUnused; impl OneUnused { #[expect(unused)] fn unused() {} } impl TwoUnused { #[expect(unused)] fn unused1(){} // This unused method has `#[expect(unused)]`, so the compiler should not emit a warning. // This ui test was added after a regression in the compiler where it did not recognize multiple // `#[expect(unused)]` annotations inside of impl blocks. // issue 114416 #[expect(unused)] fn unused2(){} } fn main() { let _ = OneUnused; let _ = TwoUnused; } </ins>

Discussion:
At some point between (works) and (does not work) the following stopped compiling: I have not bisected for the exact commit that broke this. I have only tried to reproduce this error using . It's possible that this is also broken for other lints. PR:
Without properly double-checking this, I'm certain that this regressed in (merged April 14) which condensed multiple diagnostics triggered by methods into a single one for readability meddling with the affairs of . I don't know how is implemented but if it only considers the first primary span of a (buffered) lint diagnostic, then one fix will be changing the relevant part of the code to consider all primary spans. label T-compiler A-lint F-lintreasons
Change:
Some(rustfmt_path) } <ins> pub(crate) fn rustc_dev_contents(&self) -> Vec<String> { assert!(self.download_rustc()); let ci_rustc_dir = self.out.join(&*self.build.triple).join("ci-rustc"); let rustc_dev_contents_file = t!(File::open(ci_rustc_dir.join(".rustc-dev-contents"))); t!(BufReader::new(rustc_dev_contents_file).lines().collect()) } </ins> pub(crate) fn download_ci_rustc(&self, commit: &str) { self.verbose(&format!("using downloaded stage2 artifacts from CI (commit {commit})"));

Discussion:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.
Change:
} } <del> return Some(self.graph.node_data(idx)); </del> <ins> return Some(idx); </ins> } return None;

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn foo<T>() where for<'a> T: 'a {} fn main<'a>() { foo::<&'a i32>(); //~^ ERROR the type `&'a i32` does not fulfill the required lifetime } </ins>

Discussion:
The following code fails to compile despite : The exact error is: Per comment , it seems that could imply .
contains the following comment:
I'd be interested in digging into this if you can give me some advice on how to get started.
hmm, probably best would be to privmsg me on IRC, if that's possible (). It should be fairly easy to write a targeted patch covering cases like , where the bound region only appears on the RHS; doing a more general fix (e.g., one that handles ) would be somewhat harder, though some of the recent refactoring I've been doing would help there.
Change:
pub fn into_inner(slot: ManuallyDrop<T>) -> T { slot.value } <ins> } impl<T: ?Sized> ManuallyDrop<T> { </ins> /// Manually drops the contained value. /// /// # Safety

Discussion:
currently requires . It would be nice if we could remove this restriction. I'm not sure how to do it with the current implementation using though.
Doesn't seem possible until we get by-value DSTs
care to explain why?
Ah, nevermind. It would just need to make unsized, too.
The and methods can keep could keep their bounds, we just need to relax the bound on the struct itself, and make sure . Then the following code would be possible:
I guess this would be possible by allowing types to be when there is only one variant. I was worried that would be unsound, but then I realized, the only way to create a DST type would be from an unsize coercion, and then way you know what the erased type is and can get the vtable/slice length then, just like any other unsize coercion.
See
Change:
_ => span_bug!( ident.span, "unexpected resolution for an identifier in pattern: {:?}", <del> res </del> <ins> res, </ins> ), } }

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on nightly but not on beta or stable.
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
looks like the probable culprit. cc
Will fix.
Was already looking at this hehe, I have a fix for you in
Change:
help: the bound will not be checked when the type alias is used, and should be removed | LL | type VVec<'b, 'a> = (&'b u32, Vec<&'a i32>); <del> |            --  -- </del> <ins> |                -- </ins> warning: bounds on generic parameters are not enforced in type aliases --> $DIR/type-alias-bounds.rs:14:18

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
<ins> error[E0627]: yield expression outside of generator literal --> $DIR/yield-outside-generator-issue-78653.rs:4:5 | LL |     yield || for i in 0 { } |     ^^^^^^^^^^^^^^^^^^^^^^^ error[E0277]: `{integer}` is not an iterator --> $DIR/yield-outside-generator-issue-78653.rs:4:23 | LL |     yield || for i in 0 { } |                       ^ `{integer}` is not an iterator | = help: the trait `Iterator` is not implemented for `{integer}` = note: if you want to iterate between `start` until a value `end`, use the exclusive range syntax `start..end` or the inclusive range syntax `start..=end` = note: required because of the requirements on the impl of `IntoIterator` for `{integer}` = note: required by `into_iter` error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0627. For more information about an error, try `rustc --explain E0277`. </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Assigning and removing .
This ICEs since modify labels: +regression-from-stable-to-stable
Change:
use syntax::ast; use syntax_pos::{self, Span}; use rustc::hir; <ins> use rustc::hir::print; </ins> use rustc::hir::def::Def; use rustc::ty::{self, Ty, AssociatedItem}; use errors::{DiagnosticBuilder, CodeMapper};

Discussion:
produces I think the first item in this list should be
More generally, if the expected type is an enum, and the found type is T, then you should search the enum's variants and check them whether is the sole argument of one of them. If yes, suggest the variant constructor.
I agree we should list variants like that, but I also think the functions suggestions are sort of silly; see
Change:
click: ".srclink" wait-for: "#sidebar-toggle" click: "#sidebar-toggle" <del> wait-for: 500 </del> fail: true assert-css: ("#source-sidebar", { "left": "-300px" })

Discussion:
Load Open files panel on the left. Refresh page. You'll notice everytime you load the page, the file list slides again. So we now have to wait 1s for it to stop sliding before starting to read the file we clicked on. Btw, I'd rather this never slides at all. This is time loss anyway. Could there be an option to disable this?
So there are two different things here apparently: removing the animation Don't remember the file sidebar state Did I get it right?
Yes absolutely A single simple solution to both "things" could be to completely remove the animation. I don't know of any IDE that does this - probably because it isn't optimal with regards to ergonomics. The fact the new panel now slides the code so we can read the code and have the panel open at the same time is still an improvement over the previous panel, even if we revert the animation part.
I think the idea behind the animation is to allow the reader to see that it's not hovering the code. As for the setting, not sure. What do you think
I agree with we should remove the animation. It bothers me as well, I just haven't found the time to file an issue / PR about it. :-) I don't think we should add a setting.
Ok, I'll remove the animation then. Will send a PR tomorrow. For the setting, it's that we keep the current save the state of the sidebar. Should I remove it as well?
My idea of new setting was rather "should there be an animation or should it be static", if we didn't want to remove the animation completely, for those of us that don't think the animation is worth the wait (so no need for a such new setting if we just remove the animation completely :) ) With regards to the other setting idea you seem to be talking about, it seems reasonable to me to always keep the current state of the sidebar, as we currently do, and not add an extra setting for that either :)
Oh ok. Well, that cleared things up. I'll just remove the animation then.
Change:
) -> Result<&'a NameBinding<'a>, Determinacy> { bitflags::bitflags! { struct Flags: u8 { <del> const MACRO_RULES        = 1 << 0; const MODULE             = 1 << 1; const MISC_SUGGEST_CRATE = 1 << 2; const MISC_SUGGEST_SELF  = 1 << 3; const MISC_FROM_PRELUDE  = 1 << 4; </del> <ins> const MACRO_RULES          = 1 << 0; const MODULE               = 1 << 1; const DERIVE_HELPER_COMPAT = 1 << 2; const MISC_SUGGEST_CRATE   = 1 << 3; const MISC_SUGGEST_SELF    = 1 << 4; const MISC_FROM_PRELUDE    = 1 << 5; </ins> } }

Discussion:
So pointed out to me that some recent changes in name resolution seem to have broken . They pointed me at dealing with the fallout -- maybe you can leave a few notes as to what errors you were seeing before this commit? cc -- could this be the recent changes around name resolution of helper attributes in macros? It seems the relevant code is stuff like:
(Nominated for discussion around the breakage policy/implications here.)
Duplicate of , I'll prepare a fix.
fix Or rather a "tiebreaker" for the ambiguity, since both names are indeed in scope and create ambiguity, which is correctly detected after .
Fixed in

This is a dependency of . I was trying to compile ; it failed on both the master branch and the current published version. is ambiguous (derive helper attribute vs any other name) Indeed, the code does seem to treat as simultaneously a derive macro and an attribute macro. It works fine on stable.
Example of failing builds:
modify labels: +E-needs-bisection It'd be nice if somebody pinpointed specific PR (or nightly at least). Maybe has a clue what could have caused it.
Seems to be introduced at nightly-2019-11-17. Unfortunately I'm not able to bisect that further because cargo-bisect-rustc is telling me:
Likely
This is a consequence of , I'll provide a ASAP.
Fixed in