jiebi/CodeConvo huggingface dataset:
Change:
closure_def_id: DefId, closure_span: Span, closure_clause: hir::CaptureBy, <del> body: &'tcx hir::Body<'tcx>, </del> min_captures: Option<&ty::RootVariableMinCaptureList<'tcx>>, ) -> Vec<hir::HirId> { <del> fn resolve_ty<T: TypeFoldable<'tcx>>( fcx: &FnCtxt<'_, 'tcx>, span: Span, body: &'tcx hir::Body<'tcx>, ty: T, ) -> T { let mut resolver = Resolver::new(fcx, &span, body); ty.fold_with(&mut resolver) } </del> let upvars = if let Some(upvars) = self.tcx.upvars_mentioned(closure_def_id) { upvars } else {

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. --Removing allows the code to compile successfully. <!-- 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 --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
} } <del> #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Copy)] </del> <ins> // Clippy uses Hash and PartialEq #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Copy, Hash, PartialEq)] </ins> pub enum StrStyle { /// A regular string, like `"foo"`. Cooked,

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.
Change:
| help: include the missing field in the pattern | <del> LL |     Struct { a, b, _ } = Struct { a: 1, b: 2 }; </del> <ins> LL |     Struct { a, b _ } = Struct { a: 1, b: 2 }; </ins> |               ^^^ help: if you don't care about this missing field, you can explicitly ignore it | <del> LL |     Struct { a, .., _ } = Struct { a: 1, b: 2 }; </del> <ins> LL |     Struct { a, .. _ } = Struct { a: 1, b: 2 }; </ins> |               ^^^^ error: aborting due to 5 previous errors

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:
self.register_unsize_obligations(span, &**u) } ty::UnsizeVtable(ref ty_trait, self_ty) => { <del> vtable::check_object_safety(self.tcx(), ty_trait, span); </del> <ins> vtable::check_object_safety(self.tcx(), &ty_trait.principal, span); </ins> // If the type is `Foo+'a`, ensures that the type // being cast to `Foo+'a` implements `Foo`: vtable::register_object_cast_obligations(self,

Discussion:
The following code either aborts or segfaults for me, depending on if I'm in gdb or not, on Linux: With optimizations, becomes Which means we're doing something very bad when translating this code.
Still reducing...
FWIW, I can confirm that behaviour on Windows.
cc me
Reduced: And that makes it clear the issue is not broken codegen, but rather that is mistakenly treated as object-safe (while it inherits from the non-object-safe ).
nice. cc
P-backcompat-lang, 1.0.
Hint: iterate with
takes/creates s but needs a . I'm not sure how to make these agree.
checkobjectsafety should use to enumerate the trait_ref, I think. Annoyingly this does require a right now (harder to fix than you might think).
On I get , which is an unwrap in in the supertraits iterator.
Change:
please only update it with command `x test tidy --bless`" ); } <del> let allowed_issue_names = BTreeSet::from(issues_list); let mut remaining_issue_names: BTreeSet<String> = allowed_issue_names.clone(); </del> <ins> let mut remaining_issue_names: BTreeSet<&str> = allowed_issue_names.clone(); </ins> let (ui, ui_fulldeps) = (path.join("ui"), path.join("ui-fulldeps")); let paths = [ui.as_path(), ui_fulldeps.as_path()];

Discussion:
1) modify some code of 2) run =for the first ~6 seconds, tidy is being built in parallel, but for the remaining ~1 minute and 9 seconds llvm is doing some sequential work. I'm not sure what takes so long, there must be one epic cgu that it is processing or something?
I wanted to check the problem but couldn't reproduce it locally.
! :thinking:
aha lol! it boils down to , an array of ~4K static &strs which is being inlined into the code it seems. When I cut the file down to just a handful of items, compilation time reduces to 7 seconds :upsidedownface: cc I guess?
Can you check if reduces this slowness?
It does indeed.
Ah, but if people give the tests meaningful names, it will reduce the build time. :relieved:
Change:
n.to_string()); err.emit(); } <del> let id = respan(dot_span.to(hi), n); let field = self.mk_tup_field(e, id); e = self.mk_expr(lo.to(hi), field, ThinVec::new()); </del> <ins> let field = self.mk_tup_field(e, respan(idx_span, n)); e = self.mk_expr(lo.to(idx_span), field, ThinVec::new()); </ins> } None => { let prev_span = self.prev_span;

Discussion:
If a procedural macro generates an access to a named struct field like then the may be either defsite or callsite and it works either way. But if accessing an unnamed tuple struct field like then it only works if is call_site. I believe it should work either way in either case.
Sorry for the delay! Fixed in .
Change:
} } } <del> _ if sp == expr.span && !is_macro => { </del> <ins> _ if sp == expr.span => { </ins> if let Some(steps) = self.deref_steps(checked_ty, expected) { let expr = expr.peel_blocks();

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
<ins> //@ check-pass // https://github.com/rust-lang/rust/issues/119792 struct Wrapper<T>(T); trait Div<Rhs> {} trait Mul<Rhs> { type Output; } impl<T> Mul<T> for Wrapper<T> { type Output = (); } impl<T> Div<Self> for Wrapper<T> {} pub trait NumOps<Rhs> {} impl<T, Rhs> NumOps<Rhs> for T where T: Mul<Rhs, Output = ()> + Div<Rhs> {} </ins>

Discussion:
This only happens with rust doc. Crate builds and runs tests successfully on current master: ICE occurs with The backtrace doesn't seem to point to any specific code in the crate. : <details<summary<strongBacktrace</strong</summary<p</p</details
I've been poking at this for a bit, and haven't really gotten a full MCVE (it still depends on (version 0.2.17) being in the dependency tree), but it's definitely much simpler.
Also, bisected this and got searched nightlies: from nightly-2023-12-14 to nightly-2023-12-15 regressed nightly: nightly-2023-12-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like ?
Minimized to:
Triage: I can no longer reproduce this. Can be closed once a regression test has been .
Change:
return; }; let tcx = self.tcx; <ins> let first_hir_id = tcx.hir().local_def_id_to_hir_id(first_id); let first_lint_level = tcx.lint_level_at_node(lint::builtin::DEAD_CODE, first_hir_id).0; assert!(dead_codes.iter().skip(1).all(|id| { let hir_id = tcx.hir().local_def_id_to_hir_id(*id); let level = tcx.lint_level_at_node(lint::builtin::DEAD_CODE, hir_id).0; level == first_lint_level })); </ins> let names: Vec<_> = dead_codes.iter().map(|&def_id| tcx.item_name(def_id.to_def_id())).collect(); let spans: Vec<_> = dead_codes

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:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-windows everything is the system allocator on windows // ignore-musl no dylibs on musl yet // ignore-bitrig no jemalloc on bitrig // ignore-openbsd no jemalloc on openbsd </del> <ins> // ignore-musl no dylibs </ins> // aux-build:allocator-dylib.rs <ins> // aux-build:allocator1.rs </ins> // no-prefer-dynamic // error-pattern: cannot link together two allocators

Discussion:
As of the time of this writing, we are running jemalloc at the revision which I believe is the 4.0.4 release of jemalloc. Previously we were running which I believe is somewhere in the 3.6 series. We attempted to upgrade jemalloc many times between these two commits eventually that the previous behavior of on Windows is fundamentally racy in jemalloc right now unfortunately. This led to a to where we are today. Unfortunately, however, there is a so we are attempting to downgrade back to 3.6. There were no known problems other than some Windows issues with jemalloc 3.6, so we believe it'll be fine for awhile. In this downgrade, however, it appears that the implementation of is somewhat broken as well, causing the to fail to land. As a result, the downgrade attempt will disable jemalloc on Windows entirely. This issue will track re-enabling it on Windows as well as re-upgrading once the deadlock bug is fixed. As far as I know the only reason to not enable Windows is that lots of locking support was improved in 4.0.*, and the only reason to not upgrade immediately is the deadlock bugs we've encountered.
FWIW one of my Rust projects with CI-every-night has started deadlocking recently, and after some investigation it turned up the exact same stack trace as rustdoc itself, so that's at least another data point for the deadlock in jemalloc.
Change:
} fn handle_explain(registry: Registry, code: &str, output: ErrorOutputType) { <del> let normalised = if code.starts_with('E') { code.to_string() } else { format!("E{0:0>4}", code) }; </del> <ins> let upper_cased_code = code.to_ascii_uppercase(); let normalised = if upper_cased_code.starts_with('E') { upper_cased_code } else { format!("E{0:0>4}", code) }; </ins> match registry.try_find_description(&normalised) { Ok(Some(description)) => { let mut is_in_code_block = false;

Discussion:
It would be nice if supported lowercase error codes: The current output is: Ideally, the command would work regardless of whether you enter or : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-driver +A-error-codes +C-enhancement +T-compiler claim
I'm just about to open a pull request for this. Thank you for bringing it up!
Change:
profiler_runtime: None, is_no_builtins: Default::default(), native_libraries: Default::default(), <del> used_libraries: tcx.native_libraries(LOCAL_CRATE), </del> <ins> used_libraries: tcx.native_libraries(LOCAL_CRATE).iter().map(Into::into).collect(), </ins> link_args: tcx.link_args(LOCAL_CRATE), crate_name: Default::default(), used_crates_dynamic: cstore::used_crates(tcx, LinkagePreference::RequireDynamic),

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. --I tried this command: I expected to see this happen: An file is generated. Instead, this happened: <!-- 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. --: Originally posted by in cc (original implementer of
PR changed the encode/decode method of . When was implemented, the encode/decode of was purposely crafted to avoid calling the encode/decode method of . The most straightforward fix is to implement / for to allow it be serialized outside of metadata. After that, may be now it is the time to re-think the way we store data in the file. What do you think ?
I think should completely be avoided in the input of the linker function. One of the uses if in it's field. This field doesn't seem to be used by the linking code.
Good suggestion, let me look into it.
are you still working on this?
Thank you for reminding and apologize for the delay. I did create a prototype but haven't got a chance polish it yet. I'll create the PR this week.
Sorry again about the delay. I've created PR , which fixes this issue.
Change:
<ins> // check-pass use std::fmt::Debug; use std::marker::PhantomData; trait Foo { type Gat<'a>: ?Sized where Self: 'a; } struct Bar<'a, T: Foo + 'a>(T::Gat<'a>); struct Baz<T: ?Sized>(PhantomData<T>); impl<T: ?Sized> Foo for Baz<T> { type Gat<'a> = T where Self: 'a; } fn main() { let x = Bar::<'_, Baz<()>>(()); let y: &Bar<'_, Baz<dyn Debug>> = &x; } </ins>

Discussion:
Example code I'd expect to work (): (in case the example above seems artificial, the I've reduced this from involves using an associated trait to add around sized types, but not , since wouldn't itself work) <hr/I'd expect to work because should hold, after normalization to (which holds here because ), but nothing performs that normalization before coercion gives up entirely. Unlike (where I've been wary of associated types in the past), there should be no weird interactions here, we should be able to largely treat the as a tuple (and we already ensure the type parameter being changed doesn't show up anywhere else in the , anyway). <hr/The and examples get to normalize before asking the trait system about any or obligations - I wonder if we could just normalize here? But we would have to be careful, because we are in a speculative operation, so we would have to use , like this other piece of coercion logic: cc (author of the crate where this could be useful) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
FWIW, this can be worked around but they're nightly-only and entirely unnecessary if we fix this issue.
Not sure if I should nominate this for compiler team or lang team, but let's try compiler team first.
This removing nomination. please feel free to keep the discussion going on Zulip or even re-nominating it if you consider a re-discussion important.
I'd like to work on this. I haven't worked on the compiler yet, so not sure I'll be able to fix this in a reasonable time. But since it's labelled it's worth giving a try, right? Any advice is appreciated :) claim
I'm not sure if that E-easy label is really accurate! That said, you could try to drop by in #wg-traits on Zulip at some point during one of my morning office hours times, if that works for you (9am-10 US Eastern Time, every day but Tuesday), and we could talk it over.
is this the same as ?
yes, that's the same thing, unsize coercion doesn't properly consider associated types.

(maybe it's time for me to return to this )
if there's anything we can do to help, feel free to poke us; we want this for uazu/qcell. =^-^=
It's been some time this issue was touched, so let me take a look at it.
Change:
<ins> error: captured variable cannot escape `FnMut` closure body --> $DIR/issue-95079-missing-move-in-nested-closure.rs:3:29 | LL | fn foo1(s: &str) -> impl Iterator<Item = String> + '_ { |         - variable defined here LL |     None.into_iter() LL |         .flat_map(move |()| s.chars().map(|c| format!("{}{}", c, s))) |                           - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |                           | | |                           | returns a reference to a captured variable which escapes the closure body |                           | variable captured here |                           inferred to be a `FnMut` closure | = note: `FnMut` closures only have access to their captured variables while they are executing... = note: ...therefore, they cannot allow references to captured variables to escape help: consider adding 'move' keyword before the nested closure | LL |         .flat_map(move |()| s.chars().map(move |c| format!("{}{}", c, s))) |                                           ++++ error: lifetime may not live long enough --> $DIR/issue-95079-missing-move-in-nested-closure.rs:9:15 | LL |     move |()| s.chars().map(|c| format!("{}{}", c, s)) |     --------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ returning this value requires that `'1` must outlive `'2` |     |       | |     |       return type of closure `Map<Chars<'_>, [closure@$DIR/issue-95079-missing-move-in-nested-closure.rs:9:29: 9:32]>` contains a lifetime `'2` |     lifetime `'1` represents this closure's body | = note: closure implements `Fn`, so references to captured variables can't escape the closure help: consider adding 'move' keyword before the nested closure | LL |     move |()| s.chars().map(move |c| format!("{}{}", c, s)) |                             ++++ error: aborting due to 2 previous errors </ins>

Discussion:
Given the following code: The current output is: The actually needed fix here is the following, which should ideally be recommended <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly more minimal:
claim
I came up with a solution of printing an extra line of to give user a recommendation of fixing the error by adding 'move' keyword before the closure parameter of map(). The following is the output for the first testing code. Is this good enough? This is the output from the second testing code ():
Refined the fix with a verbose suggestion of where to add keyword. The output of the first test case is: The output of the second test case is: In addition, the fix will also add the suggestion for nested closure block like this test case: The output of the above test case is:
Change:
}; let index_expr_ty = self.node_ty(index_expr.id); <ins> let adjusted_base_ty = self.resolve_type_vars_if_possible(&adjusted_base_ty); let index_expr_ty = self.resolve_type_vars_if_possible(&index_expr_ty); </ins> let result = self.try_index_step(ty::MethodCall::expr(expr.id), expr,

Discussion:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high
Change:
LL |     format!("" 1); |                ^ expected `,` <del> error: expected token: `,` </del> <ins> error: expected one of `,`, `.`, `?`, or an operator, found `1` </ins> --> $DIR/bad-format-args.rs:4:19 | LL |     format!("", 1 1); <del> |                   ^ expected `,` </del> <ins> |                   ^ expected one of `,`, `.`, `?`, or an operator here </ins> error: aborting due to 3 previous errors

Discussion:
See The macro claims that it expects when failing to parse a format string argument, but it actually accepts all tokens that make up expressions in that position. The simplest fix would be to use , but that causes parsing errors directly after the format string to claim that expression tokens are expected in that position are accepted, when they are not. In other words, it would be nice to get diagnostics like this: while avoiding getting diagnostics like this:
Change:
); } } <ins> if let ty::RawPtr(_) = &actual.sty { err.note("try using `<*const T>::as_ref()` to get a reference to the  type behind the pointer: https://doc.rust-lang.org/std/ primitive.pointer.html#method.as_ref"); } </ins> err } } else {

Discussion:
When trying to call a method on a raw pointer Rust compiler says there's no such method. It would be better to say that there is such method, but the pointer has to be explicitly dereferenced first. This is technically correct, but unexpected and help hint for this error suggests wrong solution. I've read this message as "yada yada no such method", so I went to check whether I've spelled the method correctly, whether I've put the method in the appropriate block, etc. — all completely irrelevant to this error. I'd find something like that more helpful:
, though. The best we could do here is to add some logic in trait suggestion mechanism to check whether traits for dereferenced values exist. Something along the lines of Too many help messages will overwhelm messages that actually matter, though.
Triage: no change
Triage: the error message has improved /
To suggest it would have to suggest , which is taking the suggestions a bit far. We could add a note though.
Change:
LL | fn bar(_: fn(Foo<for<'b> fn(Foo<fn(&'b ())>::Assoc)>::Assoc)) {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 1 previous error </del> <ins> error: higher-ranked subtype error --> $DIR/issue-111404-1.rs:10:1 | LL | fn bar(_: fn(Foo<for<'b> fn(Foo<fn(&'b ())>::Assoc)>::Assoc)) {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error: aborting due to 2 previous errors </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 --
Ow, my bad! claim
Change:
<ins> // check-pass // Regression test of #77475, this used to be ICE. #![feature(decl_macro)] use crate as _; pub macro ice(){} 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. --This does not happen if the macro is private or . <!-- 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
The ice also occurs with .
This is now compiled fine with the latest nightly, I think fixed it. Marking as .
Still ICEs for me on playground
Note that its nightly isn't the latest (see for example).
Latest nightly compiles it fine
This should be open until the test is .