jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(rustc_attrs)] #![rustc_dummy=5z] //~ ERROR unexpected expression: `5z` fn main() {} </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</detailsRegression in nightly-2022-11-18 from ()
This makes me wonder if we could just create a superset of a set of chars and feed these into rustc, hmm.
Can we just here?
cc
I'll take a look, thanks for the heads up.
I changed the test input to the following, to avoid an "expected item after attributes" error: With rust 1.64.0 I get these errors: If I change to return if fails, then I get these errors: Do you think that is reasonable behaviour?
Both seem fine, I'd do whatever is simpler to implement.
Change:
errors = vec![]; } if seen_spans.insert(err.span) { <del> errors.push((import, err)); </del> <ins> errors.push((*import, err)); </ins> prev_root_id = import.root_id; } <del> } else if is_indeterminate { let path = import_path_to_string( &import.module_path.iter().map(|seg| seg.ident).collect::<Vec<_>>(), &import.kind, import.span, ); let err = UnresolvedImportError { span: import.span, label: None, note: None, suggestion: None, candidates: None, }; // FIXME: there should be a better way of doing this than // formatting this as a string then checking for `::` if path.contains("::") { errors.push((import, err)) } </del> <ins> } } if !errors.is_empty() { self.throw_unresolved_import_error(errors); return; } for import in &indeterminate_imports { let path = import_path_to_string( &import.module_path.iter().map(|seg| seg.ident).collect::<Vec<_>>(), &import.kind, import.span, ); let err = UnresolvedImportError { span: import.span, label: None, note: None, suggestion: None, candidates: None, }; // FIXME: there should be a better way of doing this than // formatting this as a string then checking for `::` if path.contains("::") { errors.push((*import, err)) </ins> } }

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 code: () I expected to see an error that only says that " is unresolved". But the error says that all uses of items from the module with glob import ( in this case) are unresolved too: This may lead to extremely long and unreadable errors. The issue was originally found while developing where it caused . <!-- 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. --:
<details<summaryOutput on 1.38:</summary</details label A-diagnostics A-resolve regression-from-stable-to-stable
why do you think it's a "regression-from-stable-to-stable"? IMO the output from is even worse
The error is much shorter, and only points at the actual problem. The unused import warnings, of course, wouldn't be there if those imports were actually used.
From those rollups, looks relevant.
ah, you are right, I've misread the output thinking that the warnings were errors too.
I spent some time trying to debug this last week and I'm fairly sure is the PR that introduced this. I wasn't aware of that PR at the time but I spent a lot of time trying to understand what is "determinate" vs. "indeterminate" (which is unfortunately not documented) and I remember finding out that with glob import the import is becoming "indeterminate" while it's normally (without the glob import) it is "determinate", which is one of the things we check elsewhere when generating these warnings.
Assigning as and removing .
Change:
/// Parse `box expr` - this syntax has been removed, but we still parse this /// for now to provide a more useful error fn parse_expr_box(&mut self, box_kw: Span) -> PResult<'a, (Span, ExprKind)> { <del> let (span, _) = self.parse_expr_prefix_common(box_kw)?; let inner_span = span.with_lo(box_kw.hi()); let code = self.psess.source_map().span_to_snippet(inner_span).unwrap(); let guar = self.dcx().emit_err(errors::BoxSyntaxRemoved { span: span, code: code.trim() }); </del> <ins> let (span, expr) = self.parse_expr_prefix_common(box_kw)?; // Make a multipart suggestion instead of `span_to_snippet` in case source isn't available let box_kw_and_lo = box_kw.until(self.interpolated_or_expr_span(&expr)); let hi = span.shrink_to_hi(); let sugg = errors::AddBoxNew { box_kw_and_lo, hi }; let guar = self.dcx().emit_err(errors::BoxSyntaxRemoved { span, sugg }); </ins> Ok((span, ExprKind::Err(guar))) }

Discussion:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).
Change:
} <ins> #[stable(feature = "from_nonzero", since = "1.31.0")] impl From<$Ty> for $Int { fn from(nonzero: $Ty) -> Self { nonzero.0 .0 } } </ins> impl_nonzero_fmt! { (Debug, Display, Binary, Octal, LowerHex, UpperHex) for $Ty }

Discussion:
I'd really expect this to just work: All types should implement , as this conversion is always possible and free.
Change:
<ins> fn no_err() { |x: String| x; let _ = String::from("x"); } fn err() { String::from("x".as_ref()); //~ ERROR type annotations needed } fn arg_pat_closure_err() { |x| String::from("x".as_ref()); //~ ERROR type annotations needed } fn local_pat_closure_err() { let _ = "x".as_ref(); //~ ERROR type annotations needed } fn err_first_arg_pat() { String::from("x".as_ref()); //~ ERROR type annotations needed |x: String| x; } fn err_second_arg_pat() { |x: String| x; String::from("x".as_ref()); //~ ERROR type annotations needed } fn err_mid_arg_pat() { |x: String| x; |x: String| x; |x: String| x; |x: String| x; String::from("x".as_ref()); //~ ERROR type annotations needed |x: String| x; |x: String| x; |x: String| x; |x: String| x; } fn err_first_local_pat() { String::from("x".as_ref()); //~ ERROR type annotations needed let _ = String::from("x"); } fn err_second_local_pat() { let _ = String::from("x"); String::from("x".as_ref()); //~ ERROR type annotations needed } fn err_mid_local_pat() { let _ = String::from("x"); let _ = String::from("x"); let _ = String::from("x"); let _ = String::from("x"); String::from("x".as_ref()); //~ ERROR type annotations needed let _ = String::from("x"); let _ = String::from("x"); let _ = String::from("x"); let _ = String::from("x"); } fn main() {} </ins>

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:
<ins> error: this file contains an unclosed delimiter --> $DIR/brace-in-let-chain.rs:58:54 | LL | fn main() { |           - unclosed delimiter ... LL | fn quux() { |           - unclosed delimiter ... LL | fn foobar() { |             - unclosed delimiter ... LL | fn fubar() { |            - unclosed delimiter ... LL | fn qux() { |          - unclosed delimiter ... LL | fn foo() { |          - unclosed delimiter ... LL | fn bar() { |          - unclosed delimiter ... LL | fn baz() { |          - unclosed delimiter LL |     if false { LL |         { |         - this delimiter might not be properly closed... LL |             && let () = () LL |     } |     - ...as it matches this but it has different indentation LL | } |                                                      ^ error: found a `{` in the middle of a let-chain --> $DIR/brace-in-let-chain.rs:14:24 | LL |         && let () = () { |                        ^ LL |         && let () = () |         ------ you might have meant to continue the let-chain here | help: consider removing this brace to parse the `let` as part of the same chain | LL -         && let () = () { LL +         && let () = () | error: found a `{` in the middle of a let-chain --> $DIR/brace-in-let-chain.rs:6:24 | LL |         && let () = () { |                        ^ LL |         && let () = () |         ------ you might have meant to continue the let-chain here | help: consider removing this brace to parse the `let` as part of the same chain | LL -         && let () = () { LL +         && let () = () | error: aborting due to 3 previous errors </ins>

Discussion:
Unmatched delimiters are hard to deal with by taking consideration of surrounding code because they actually occur during lexing. Still, it'd be nice if we detected some common sources of issues like this one. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
fn flat_map_item(&mut self, item: P<ast::Item>) -> SmallVec<[P<ast::Item>; 1]> { match item.kind { <del> ast::ItemKind::MacCall(_) => return self.remove(item.id).make_items(), ast::ItemKind::MacroDef(_) => return smallvec![item], _ => {} </del> <ins> ast::ItemKind::MacCall(_) => self.remove(item.id).make_items(), _ => noop_flat_map_item(item, self), </ins> } <del> noop_flat_map_item(item, self) </del> } fn flat_map_trait_item(&mut self, item: P<ast::AssocItem>) -> SmallVec<[P<ast::AssocItem>; 1]> {

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. --Found an ICE with when trying to use it in the standard library (). 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<summary<strongBacktrace</strong</summary<p</p</details
I can hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
/// Splits the list into two at the given index. Returns everything after the given index, /// including the index. /// <ins> /// # Panics /// /// Panics if `at > len`. /// </ins> /// This operation should compute in O(n) time. <ins> /// </ins> /// # Examples /// /// ```

Discussion:
Currently, requires its argument to be strictly less than the length of the list, which means the following function panics when passed a one-element list. Instead, it should leave the original list unmodified and return an empty list: In contrast, does allow as a valid argument, so the above code works as desired if you replace DList with Vec.
Vec was actually like this until a few days ago when I happened to notice it and change the check. I must've mis-specified it in the RFC, or this went viral from the first mis-write.
Change:
); } <ins> if self.suggest_add_clone_to_arg(&obligation, &mut err, trait_predicate) { err.emit(); return; } </ins> if self.suggest_impl_trait(&mut err, span, &obligation, trait_predicate) { err.emit(); return;

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; <del> run.path($path).default_condition(builder.config.extended) </del> <ins> run.path($path).default_condition( builder.config.extended && builder.config.tools.as_ref().map_or(true, |tools| { tools.iter().any(|tool| match tool.as_ref() { "clippy" => $tool_name == "clippy-driver", x => $tool_name == x, }) }), ) </ins> } fn make_run(run: RunConfig<'_>) {

Discussion:
Running results in all tools built, even though I asked for one, using the following : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hm, so this was originally only for the use case (it's even somewhat explicitly specified as such in the docs above in ). If chosen tool failed to build the installation fails. If , this option is ignored. Did you actually want this to work? (Or just pointing out an inconsistency?) Generally speaking x.py build without arguments is essentially never what you really want IMO, it's too broad -- I would recommend always passing a specific thing to build, in this case it looks like you want src/tools/rustfmt as the flag.
I expected only the specified to get built, but I guess I also glossed over the word. Needs an update perhaps... it's not so clear. Maybe following would be better: Replacing
My confusion could also be coming from this snippet, which talks about building
claim
Change:
//~| WARN const_err println!("{}", 1/(false as u32)); //~^ WARN const_err <ins> //~| WARN const_err </ins> let _x = 1/(false as u32); <ins> //~^ WARN const_err //~| WARN const_err </ins> }

Discussion:
inlined inside a , I get a warning: however, when I involve a variable there is no warning at all but looking at the generated code it is quite clear that this panics:
It warns on current stable, but not on beta and nightly. Might be miri fallout? cc Curiously, when you take a reference (to trigger promotion to static) you get a hard error on beta and nightly (stable is still a warning). Isn't that a regression?
triage: P-medium Still want to get those warnings, but no longer P-high
Hm, what is the status of this? The PR was merged, but with , I don't get a compiler warning for the first example. For the second one I get two though? :confused:
The PR was just for the compilation error. The missing warnings just need an impl for this branch: The warning duplication is unfortunate, but if we deduplicate it, we loose warnings in other edge cases. We could deduplicate it similar to the way the notes about where the lint level was set are deduplicated (note how the second warning has no message). That would probably be the cleanest solution.
Change:
<ins> //@ run-rustfix #[allow(dead_code)] fn main() { struct S<'a>(&'a ()); fn f1(s: S<'_>) -> _ { //~^ ERROR the placeholder `_` is not allowed s } fn f2(s: S<'_>) -> _ { //~^ ERROR the placeholder `_` is not allowed let x = true; if x { s } else { s } } fn f3(s: S<'_>) -> _ { //~^ ERROR the placeholder `_` is not allowed return s; } fn f4(s: S<'_>) -> _ { //~^ ERROR the placeholder `_` is not allowed let _x = 1; return s; } } </ins>

Discussion:
The code Emits this diagnostic, which is wrong in this case. It should say cc: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Cannot reproduce: the code snippet as given produces on stable 1.78.0
Did you mean to write this code snippet instead?
Ooops yes :sweat_smile:, edited
claim
Change:
<ins> // run-rustfix fn main() { let _ = vec![vec![0, 1], vec![2]] .into_iter() .map(|y| y.iter().map(|x| x + 1).collect::<Vec<_>>()) //~^ ERROR cannot return value referencing function parameter `y` .collect::<Vec<_>>(); } </ins>

Discussion:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.
Change:
<ins> error[E0423]: expected function, found trait `Foo` --> $DIR/issue-58022.rs:14:9 | LL |         Foo(Box::new(*slice)) |         ^^^ not a function error[E0283]: type annotations needed: cannot resolve `_: Foo` --> $DIR/issue-58022.rs:4:25 | LL |     const SIZE: usize; |     ------------------ required by `Foo::SIZE` LL | LL |     fn new(slice: &[u8; Foo::SIZE]) -> Self; |                         ^^^^^^^^^ error: aborting due to 2 previous errors Some errors have detailed explanations: E0283, E0423. For more information about an error, try `rustc --explain E0283`. </ins>

Discussion:
Using a generic function to "converge" two into when T is an associated type for another trait causes the following error: Example code (): This may or may not be related to the compiler seemingly failing to assert that , an error that can be triggered by using the alternate signature for at line 40 of the example. I tested this with the linked playground on the latest stable (1.32.0), as well as a recent nightly: Compiling with doesn't seem to yield a very useful stack but here it is:
Another example by that causes only the second "call dest mismatch" ICE:
P-medium. Removing nomination label. (But maybe we should have a WG-impl-trait to provide a structured effort for working through the bugs with impl trait?)
This has been fixed in 1.38.0 as, while I can reproduce the ICE in 1.37.0, I am not observing it in neither of: stable (1.38.0), beta nor nightly. modify labels: E-needstest

The following code works on beta: But when used in a trait like so: rustc reports the following error:
Possibly related to rustc expecting possibly a type in this scenario? As you can declare trait methods with no parameter name
Possibly related to rustc expecting possibly a type in this scenario? Exactly. When becomes an error, we'll be able to accept arbitrary patterns in parameters of trait methods, but for now only very limited subset is allowed.
The example in the issue now compiles. If we don't have existing tests for this, we ought to add one.
Change:
#![feature(decl_macro)] <del> macro mac { ($ arg : expr) => { $ arg + $ arg } } </del> <ins> pub(crate) macro mac { ($ arg : expr) => { $ arg + $ arg } } </ins> fn main() { }

Discussion:
E.g. becomes Specifically, the syntax contexts of and are linked (the s refer to the same identifier, even with hygiene) but this is not represented in the output at all, so one might interpret them as being distinct identifiers.
There is no more pretty=hygene, was it replaced with something?
Closing. is apparently no longer a thing, and the output looks sufficiently different with that I don't think it's the same.
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Looks like is a thing though so reopening... output today is below. I'm not completely sure whether this is fixed or not --- the output looks the same for the two s, I guess? Not sure which are being referred to either...
Change:
severity: ChangeSeverity::Info, summary: "Removed android-ndk r25b support in favor of android-ndk r26d.", }, <ins> ChangeInfo { change_id: 125181, severity: ChangeSeverity::Warning, summary: "For tarball sources, default value for `rust.channel` will be taken from `src/ci/channel` file.", }, </ins> ];

Discussion:
On current master: Same thing on the 1.80.0 release tag: This default value of "dev" used to be accurate prior to , i.e. with Rust 1.79 and older. The default value comes from this hardcoded value: But post-, the default value varies by how you got your source tarball, or what git branch you are on. It is not accurate for the Rust 1.80.0 release sources to say the default value for is "dev", as it's actually "stable" now. Mentioning since you worked on the PR (which I am otherwise happy with). The change in default also needs to be called out in
Change:
<del> // This implements the dead-code warning pass. It follows middle::reachable // closely. The idea is that all reachable symbols are live, codes called // from live codes are live, and everything else is dead. </del> <ins> // This implements the dead-code warning pass. // All reachable symbols are live, code called from live code is live, code with certain lint // expectations such as `#[expect(unused)]` and `#[expect(dead_code)]` is live, and everything else // is dead. </ins> use hir::def_id::{LocalDefIdMap, LocalDefIdSet}; use itertools::Itertools;

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:
//~^ ERROR mismatched types foo::<isize>(x_u16.try_into().unwrap()); //~^ ERROR mismatched types <del> foo::<isize>(x_u8.try_into().unwrap()); </del> <ins> foo::<isize>(x_u8.into()); </ins> //~^ ERROR mismatched types foo::<isize>(x_isize); foo::<isize>(x_i64.try_into().unwrap());

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.