jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Checks what happens when `public` is used instead of the correct, `pub` // run-rustfix pub enum Test { //~^ ERROR expected one of `!` or `::`, found keyword `enum` //~^^ HELP write `pub` instead of `public` to make the item public A, B, } fn main() { } </ins>

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
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. // aux-build:issue-29181.rs extern crate issue_29181 as foo; fn main() { 0.homura(); //~ ERROR no method named `homura` found } </ins>

Discussion:
Updated 10/21: is currently valid Rust. I don't know if it should be, but it causes the compiler to blow its stack when recursively traversing a crate which contains it. To reproduce: Create a lib crate with this body: (compiles fine)Link to this crate, then include code that results in a method missing error, such as: This will cause the stack to overflow in while it looks up traits in linked crates that define a method . There are probably other functions which overflow like this in the case of this text. I would think either should be smart enough to not recursively include the self module or should be an error.
It would be easier to debug this problem if we would have source code that causes it (e.g. for ).
I did some debugging, found the issue, and have updated the title and top comment to explain it clearly, including steps to reproduce. Fortunately, the practical fix is easy (don't use ).
Change:
Greater | // `{ 42 } > 3` GreaterEqual | // `{ 42 } >= 3` AssignOp(_) | // `{ 42 } +=` <del> LAnd | // `{ 42 } &&foo` </del> As | // `{ 42 } as usize` // Equal | // `{ 42 } == { 42 }`    Accepting these here would regress incorrect // NotEqual | // `{ 42 } != { 42 }  struct literals parser recovery.

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
<ins> #![feature(marker_trait_attr)] #[marker] trait A {} trait B {} impl<T: A> B for T {} impl<T: B> A for T {} impl A for &str {} impl<T: A + B> A for (T,) {} trait TraitWithAssoc { type Assoc; } impl<T: A> TraitWithAssoc for T { type Assoc = T; } impl TraitWithAssoc for ((&str,),) { //~^ ERROR conflicting implementations type Assoc = ((&'static str,),); } fn main() {} </ins>

Discussion:
() same code with an additional line of whitespace/comments where indicated: however, the playground seems to behave different from my local nightly here Tested on label T-compiler requires-nightly F-markertraitattr A-traits A-typesystem and someone please add “I-unsound ”
ACTUALLY… the error after adding the whitespace disappears again with . Which would explain why it isn’t reproducable in the playground. Might be related to label A-incr-comp.
This test doesn't seem to compile with the most recent nightly but I don't think the underlying issue has been fixed. Not sure how to retrigger this issue
Change:
} #[stable(feature = "rust1", since = "1.0.0")] <ins> impl<T:Copy> Clone for [T; $N] { fn clone(&self) -> [T; $N] { *self } } #[stable(feature = "rust1", since = "1.0.0")] </ins> impl<T: Hash> Hash for [T; $N] { fn hash<H: hash::Hasher>(&self, state: &mut H) { Hash::hash(&self[..], state)

Discussion:
broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.
Change:
<ins> trait Marker {} impl Marker for u32 {} trait MyTrait { fn foo(&self) -> impl Marker; } struct Outer; impl MyTrait for Outer { fn foo(&self) -> impl Marker { 42 } } impl dyn MyTrait { //~^ ERROR the trait `MyTrait` cannot be made into an object fn other(&self) -> impl Marker { //~^ ERROR the trait `MyTrait` cannot be made into an object MyTrait::foo(&self) //~^ ERROR the trait bound `&dyn MyTrait: MyTrait` is not satisfied //~| ERROR the trait bound `&dyn MyTrait: MyTrait` is not satisfied //~| ERROR the trait bound `&dyn MyTrait: MyTrait` is not satisfied //~| ERROR the trait `MyTrait` cannot be made into an object } } fn main() {} </ins>

Discussion:
No response No response This code is originally extracted from a reduction of a problem found hit on a . I reduced the code down to something that, confusingly, provides an incorrect diagnostics message. Originally, the dynamic dispatch were , I just substituted them. The nightly toolchain as of today behaves the same. As a note, the correct output is provided if the statement is commented out, which is why I think this is related to , but maybe not the same.
This is a duplicate of , so I'll close this in favor of that. I do agree that it's a diagnostic issue, so I will fix it.

No response cc No response No response
Is there any workaround for this issue before a patch lands?
Change:
if self.check_keyword(kw::Pub) { let sp = sp_start.to(self.prev_token.span); if let Ok(snippet) = self.span_to_snippet(sp) { <del> let vis = self.parse_visibility(FollowedByType::No)?; </del> <ins> let vis = match self.parse_visibility(FollowedByType::No) { Ok(v) => v, Err(mut d) => { d.cancel(); return Err(err); } }; </ins> let vs = pprust::vis_to_string(&vis); let vs = vs.trim_end(); err.span_suggestion(

Discussion:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2021-02-10 to nightly-2021-05-01 regressed nightly: nightly-2021-03-19 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsIt looks like is when this error started happening. cc
I'm going to take a look at this. claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
"src/libterm", "src/jemalloc", "src/libprofiler_builtins", <ins> "src/stdsimd", </ins> ]; let std_src_dirs_exclude = [ "src/libcompiler_builtins/compiler-rt/test",

Discussion:
cc possibly caused by ; it seems that stdsimd will have to be included in rust-src
Also, this broke Xargo and the development workflow of all the no_std / embedded users who use it. cc
Change:
ns, impl_, ) <del> .map(|item| match item.kind { ty::AssocKind::Fn => "method", ty::AssocKind::Const => "associatedconstant", ty::AssocKind::Type => "associatedtype", </del> <ins> .map(|item| { let kind = item.kind; self.kind_side_channel.set(Some((kind.as_def_kind(), item.def_id))); match kind { ty::AssocKind::Fn => "method", ty::AssocKind::Const => "associatedconstant", ty::AssocKind::Type => "associatedtype", } </ins> }) .map(|out| { (

Discussion:
I tried this code: I expected to see this happen: Rustdoc links to Instead, this happened: Rustdoc gets confused that means a function and thinks that the link is a primitive. <!-- 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. --: Relevant code: I think the fix is just to add as a match guard. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is blocking and made unnecessarily difficult.
claim
which arm do you mean to add the match guard to?
the one for telling if the resolved item is a primitive:
It looks like is in fact for
Oh hmm - the issue is that for primitives, rustdoc generates the anchor manually: I would try storing the of the associated item in instead, so you know later whether the anchor is a manual link () or whether it was generated by rustdoc.
Adding in here and adding the match guard seems to fix things, but also feels like a hack.
I mean, all of is a hack because other parts of rustdoc break when you store the associated item instead: If you can figure out a way to get rid of it, I'd love to do that, but it will require some pretty major refactors I think.
Change:
= note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0080]: evaluation of constant value failed <del> --> $DIR/uninhabited.rs:65:9 </del> <ins> --> $DIR/uninhabited.rs:63:9 </ins> | LL |         assert!(false); <del> |         ^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: false', $DIR/uninhabited.rs:65:9 </del> <ins> |         ^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: false', $DIR/uninhabited.rs:63:9 | = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0080]: evaluation of constant value failed --> $DIR/uninhabited.rs:87:9 | LL |         assert!(false); |         ^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: false', $DIR/uninhabited.rs:87:9 </ins> | = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
self.suggest_accessing_field_where_appropriate(cause, &exp_found, diag); self.suggest_await_on_expect_found(cause, span, &exp_found, diag); self.suggest_function_pointers(cause, span, &exp_found, diag); <ins> self.suggest_turning_stmt_into_expr(cause, &exp_found, diag); </ins> } }

Discussion:
The code below has superfluous semicolons in the branches of the if expression: The error message that results is: This can be confusing to beginners, who may not understand unit type. However, since the expressions and can be shown to have no side effects, the code (as is) can't be what the user intended. Could the compiler produce a more targeted error message that mentions the superfluous semicolon? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label T-compiler A-diagnostics D-newcomer-roadblock D-terse
claim
Thinking more about this, I don't think we should extend the "remove semicolon to make tail expression" suggestion to cover this case, since we don't know the expected type of at the point at which the suggestion would be made. For example, we don't make the suggestion to change to here: But that's just a guess based on my limited knowledge of type mismatch suggestions. Maybe someone else could weigh in?
Change:
LL | fn k<'a, T: WithLifetime<'a>>(_x: T::Output) -> &'a isize { |                                                  ++ <del> error: aborting due to 6 previous errors </del> <ins> error[E0106]: missing lifetime specifier --> $DIR/lifetime-elision-return-type-requires-explicit-lifetime.rs:45:37 | LL | fn l<'a>(_: &'a str, _: &'a str) -> &str { "" } |             -------     -------     ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value with an elided lifetime, but the lifetime cannot be derived from the arguments help: consider using the `'a` lifetime | LL | fn l<'a>(_: &'a str, _: &'a str) -> &'a str { "" } |                                      ++ error: aborting due to 7 previous errors </ins> For more information about this error, try `rustc --explain E0106`.

Discussion:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 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
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.
Change:
path, opt_ns, record_used, path_span, crate_lint, ); <del> for (i, &Segment { ident, id }) in path.iter().enumerate() { </del> <ins> for (i, &Segment { ident, id, has_generic_args: _ }) in path.iter().enumerate() { </ins> debug!("resolve_path ident {} {:?} {:?}", i, ident, id); let record_segment_res = |this: &mut Self, res| { if record_used {

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
Change:
cargo.env("RUSTC_VERBOSE", self.verbosity.to_string()); <del> // in std, we want to avoid denying warnings for stage 0 as that makes cfg's painful. if self.config.deny_warnings && !(mode == Mode::Std && stage == 0) { </del> <ins> if self.config.deny_warnings { </ins> cargo.env("RUSTC_DENY_WARNINGS", "1"); }

Discussion:
rustc should not compile with any warnings. Some warnings are currently denied, but not all: see , for instance, where a warning got through.
stage 0 libcore/std never denied warnings as far as I know
Change:
<ins> pub static FOO: &str = "foo"; pub fn foo() { println!("foo"); } </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 this happen: generate 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
This is strange, Miri uses but statics seem to work fine for us?
Does the test case I gave work for Miri? I notice that produces much larger rmeta files than would, which are in turn larger than 's rmetas (as expected). It would be nice to have an option to make lone produce the same output as , and I was hoping that it would just be a matter of stabilizing , but they don't seem to be equivalent. Ideally they'd produce the same output, but I'd be happy with functionally interchangable - which is what this issue is about. Overall, I'm finding it hard to work out what controls what goes into a file. I audited all the places where either or both of and/or are checked, and unifying them does not produce an output where and together produce the same as . I guess I haven't confirmed that MIR is the only difference between the two cases.
Yes: when I set up a 2-crate workspace matching your 2 files and then do , it works as expected.
PR adds so that generates equivalent rmetas to .
Change:
<ins> error[E0106]: missing lifetime specifier --> $DIR/missing-lifetime-in-alias.rs:23:24 | LL | type B<'a> = <A<'a> as Trait>::Foo; |                        ^^^^^ expected named lifetime parameter | help: consider using the `'a` lifetime | LL | type B<'a> = <A<'a> as Trait<'a>>::Foo; |                        ~~~~~~~~~ error[E0106]: missing lifetime specifier --> $DIR/missing-lifetime-in-alias.rs:27:28 | LL | type C<'a, 'b> = <A<'a> as Trait>::Bar; |                            ^^^^^ expected named lifetime parameter | note: these named lifetimes are available to use --> $DIR/missing-lifetime-in-alias.rs:27:8 | LL | type C<'a, 'b> = <A<'a> as Trait>::Bar; |        ^^  ^^ error[E0107]: missing generics for associated type `Trait::Bar` --> $DIR/missing-lifetime-in-alias.rs:27:36 | LL | type C<'a, 'b> = <A<'a> as Trait>::Bar; |                                    ^^^ expected 1 lifetime argument | note: associated type defined here, with 1 lifetime parameter: `'b` --> $DIR/missing-lifetime-in-alias.rs:7:10 | LL |     type Bar<'b> |          ^^^ -- help: add missing lifetime argument | LL | type C<'a, 'b> = <A<'a> as Trait>::Bar<'a>; |                                    ~~~~~~~ error: aborting due to 3 previous errors Some errors have detailed explanations: E0106, E0107. For more information about an error, try `rustc --explain E0106`. </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 this happen (which works correctly with rustc 1.57.0 stable): But with , I get: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also consider the following code, which creates an error message that could be more precise. I wouldn't call the following example a bug, but maybe these two issues are related: () Error output:
I think this is due to cc: let me see if I can fix this real quick.
claim
label +regression-from-stable-to-nightly +A-diagnostics
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
self.fcx.require_type_is_sized( var_ty, p.span, <del> traits::SizedArgumentType(Some(ty_span)), </del> <ins> // ty_span == ident.span iff this is a closure parameter with no type // ascription, or if it's an implicit `self` parameter traits::SizedArgumentType( if ty_span == ident.span && self.fcx.tcx.is_closure(self.fcx.body_id.into()) { None } else { Some(ty_span) }, ), </ins> ); } } else {

Discussion:
Notice how the last 2 suggestions aren't valid in such a closure: The suggestions given in should help me get closer to fixing the error, or at least not have invalid syntax. No response No response Output of :
(if is used in the snippet, comes up again with leaking implementation details)