jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0308]: mismatched types --> $DIR/binary-op-suggest-deref.rs:6:12 | LL |     if i < 0 {} |            ^ expected `&i64`, found integer | help: consider dereferencing the borrow | LL |     if *i < 0 {} |        + error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up.

I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim
Change:
} ``` <del> The nightly feature [Arbintrary self types][AST] extends the accepted </del> <ins> The nightly feature [Arbitrary self types][AST] extends the accepted </ins> set of receiver types to also include any type that can dereference to `Self`:

Discussion:
, where it should be "Arbitrary self types". CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So what happened to them? I still consider them to be faulty code, but I assume there's a discussion that led to the removal of this error. There ought to be more information about that on the page.
I do not see that note for E0307 (but do see it for others, like E001). We do not remove documentation for error codes because people can use older compilers and might need help when googling for those errors they might see. As to what happened to them, they sometimes get superseded by other, more specific errors, and other times the compiler started accepting the code due to new features.
claim
Change:
pub mod pipe; pub mod process; pub mod rand; <ins> pub mod stdio; </ins> pub mod thread; pub mod thread_local_dtor; pub mod thread_local_key;

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Building std library (-Zbuild-std) with nightly for uwp-windows-msvc targets has been failing with compile errors since around after 17/10/22 I expected to see this happen: Last successeful build on 16/10: Instead, this happened: Lastest failed build: It most recently worked on: rustc 1.66.0-nightly ( 2022-10-14) : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Hey, is anyone looking into this because ALXR ci (uwp) builds are failing for over a week. Should this issue be posted in another repo?
This is the right repo, but it fell through the cracks for whatever reason. I can get to it this weekend.
Thank you :)
Oh, sorry I missed this! Since 10.0. console functions are available on UWP (see ). So I think the thing to do here is to simply stop making the function conditionally imported.
Change:
// We want to suggest the properly-balanced expression `1 / (2 + 3)`, not // the malformed `1 / (2 + 3` let _a = (1 / (2 + 3)); <ins> f(); } fn f() -> bool { loop { if (break { return true }) { } } false </ins> }

Discussion:
Rustc 1.30.0-nightly ( 2018-09-29) suggests turning into , which changes the meaning of the program. warning: unnecessary parentheses around condition -- | 5 | if (break { return true }) { | ^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses | = note: #[warn(unused_parens)] on by default
Change:
<ins> #![deny(unused_variables)] macro_rules! make_var { ($struct:ident, $var:ident) => { let $var = $struct.$var; }; } #[allow(unused)] struct MyStruct { var: i32, } fn main() { let s = MyStruct { var: 42 }; make_var!(s, var); //~ ERROR unused variable: `var` let a = 1; //~ ERROR unused variable: `a` } </ins>

Discussion:
Consider the following file in a cargo package: Cargo will warn that is not used. Upon running , cargo will change the second parameter from to , making the compilation fail. Even worse, if contained a field then would change the variable without producing any warning. a new cargo binary project with the above snippet in (presumably with ) No response No response
just applies any  suggestion produced by . In this case, the suggestion from is to replace with . I went ahead and ran to see if it could help me understand what is going on better: ` (I cleaned up the expanded code slightly, but it is the same) Looking at the expanded code, it makes me think that is seeing in as the source of the problem since it expands to and is unused in this case. The normal suggestion is to add an underscore to so it would not be "unused". So suggests to change the being passed to the macro call as it does not understand that the warning is really coming from within the macro, not the call itself. It also could be suggesting this as is not valid rust (macro?) syntax. If you change your example slightly, correctly suggests the problem comes from within the macro call. To me, this seems like a problem with , but I do not know enough about the compiler internals to be 100% certain.
Transferred to rust-lang/rust, since the suggestions are generated by the compiler.
Yes, this issue comes from rustc. The lint is emitted from here Maybe we only point out that there is an unused variable coming from , but without the suggestion? I'm not sure what is a proper lint for this test case. any thoughts on it?
The quick and straightforward way to fix this would be to only emit the suggestion in this lint if the span has the root context, but then a subset of valid suggestions wouldn't be emitted. I had an older PR that I'm having trouble finding that would automatically do that for every diagnostic, but IIRC it had some negative perf impact when not implementing it very simplistic. In this we can probably instead check that all of the spans involved have the same . If they don't, don't suggest changes.
Change:
<ins> // Checks that private macros aren't documented by default. They // should be still be documented in `--document-private-items` mode, // but that's tested in `macro-document-private.rs`. // // // This is a regression text for issue #88453. #![feature(decl_macro)] // @!has macro_private_not_documented/index.html 'a_macro' // @!has macro_private_not_documented/macro.a_macro.html macro_rules! a_macro { () => () } // @!has macro_private_not_documented/index.html 'another_macro' // @!has macro_private_not_documented/macro.another_macro.html macro another_macro { () => () } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: is hidden from the documentation. Instead, this happened: is shown in the documentation and has its own page. Private declarative macros are also shown. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: rustc 1.56.0-nightly ( 2021-08-14) <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-nightly-to-nightly -regression-untriaged +A-macros +A-visibility +T-rustdoc --
modify labels +requires-nightly
Thanks for filing this issue! This regression was almost certainly introduced in . I'm looking into it.
Assigning priority as in the prioritization working group. label: +P-high -I-prioritize
Thanks
Change:
<ins> // Visibilities on impl items expanded from macros are resolved (issue #64705). macro_rules! perftools_inline { ($($item:tt)*) => ( $($item)* ); } mod state { pub struct RawFloatState; impl RawFloatState { perftools_inline! { pub(super) fn new() {} // OK } } } pub struct RawFloatState; impl RawFloatState { perftools_inline! { pub(super) fn new() {} //~ ERROR failed to resolve: there are too many initial `super`s } } fn main() {} </ins>

Discussion:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in
Change:
<ins> error[E0392]: lifetime parameter `'a` is never used --> $DIR/dedup.rs:6:12 | LL | struct Foo<'a>; |            ^^ unused lifetime parameter | = help: consider removing `'a`, referring to it in a field, or using a marker such as `PhantomData` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0392`. </ins>

Discussion:
The following code: gives the following output: The "unused lifetimes" warning is redundant - not using a lifetime parameter is a hard error, so the warning gives no additional information.
Note that this lint still makes sense for functions: But then running clippy on the following looks dumb (the lints are redundant): I don't really know the compiler internals, but should this lint just skip structs ? (is that even possible ?)
label +E-needs-test This was fixed in but no test was for nonduplication.
Change:
SymbolExportLevel::C)); } <ins> if tcx.sess.allocator_kind.get().is_some() { for method in ALLOCATOR_METHODS { local_crate.push((format!("__rust_{}", method.name), INVALID_DEF_ID, SymbolExportLevel::Rust)); } } </ins> if let Some(id) = tcx.sess.derive_registrar_fn.get() { let def_id = tcx.hir.local_def_id(id); let idx = def_id.index;

Discussion:
Since bumped the bootstrap compiler, stage0 libstd fails to build when jemalloc is disabled: I believe it needs to restore the logic removed here: I tried to add this to : Then stage0 passed, but stage1 std failed like:
cc
We should probably add a builder for this...
or just get on with evicting jemalloc...
is not the right way to fix this - I that so I could build rust with a local rust that does not have jemalloc i.e. unless the following two conditions are true: you're using a local rust (as opposed to the automatic stage0 download) and your local rust does not have jemalloc (you compiled the whole thing yourself with ) it's irrelevant. Edit: to be clear, by "not the right way to fix this" I mean "it worked fine before I that flag, so its removal is probably not the root cause". That's doesn't exclude the possibility that we could perform some incantations with this flag and fix the issue. Edit2: sorry, I thought you were exclusively referring to rather than all the logic. I read and thought this issue was about the same thing.
Generally, the two conditions you list are actually true for me. I build Fedora's rustc without jemalloc, and I use that as the local stage0 to build the next release. And i think the force flag does come into play too, because if we need to rebuild the current release then the local rust gets treated as a stage1. But right now it's more direct. I am using the downloaded stage0, which wants to default to jemalloc. Since I'm disabling that for my build, stage0 can't find it.
Interesting, I kinda figured I was the only one! Rereading , I see I'm wrong about my two conditions above - it actually applies when trying to build something without jemalloc, from something that defaults to it. Anyway, it should all be fixed soonish...
Change:
match node { pprust::AnnNode::Ident(&ast::Ident { name, span }) => { s.s.space(); <del> // FIXME #16420: this doesn't display the connections // between syntax contexts </del> s.synth_comment(format!("{}{:?}", name.as_u32(), span.ctxt())) } pprust::AnnNode::Name(&name) => { s.s.space(); s.synth_comment(name.as_u32().to_string()) } <ins> pprust::AnnNode::Crate(_) => { s.s.hardbreak(); let verbose = self.sess.verbose(); s.synth_comment(syntax_pos::hygiene::debug_hygiene_data(verbose)); s.s.hardbreak_if_not_bol(); } </ins> _ => {} } }

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:
<ins> // Regression test for #75889. const FOO: dyn Fn() -> _ = ""; //~ ERROR E0121 static BOO: dyn Fn() -> _ = ""; //~ ERROR E0121 fn main() {} </ins>

Discussion:
I'll jump straight into the minimum verifiable example: Try it out . Here is the standard error output: Being a complete beginner I don't really know what I can add to this report, and I have a workaround which I can use to avoid this problem. (I know what I can put in the place of ) Edit: () gives which seems not ideal.
Assigning as and removing .
There is a partial fix in , though it regresses diagnostics. I think it ought not to be too much work to address this, but I do not have time at the moment.
This ICEs since . modify labels: +regression-from-stable-to-stable
Change:
<ins> running 1 test test $DIR/doctest-output-include-fail.md - (line 3) ... FAILED failures: ---- $DIR/doctest-output-include-fail.md - (line 3) stdout ---- error: expected `;`, found `}` --> $DIR/doctest-output-include-fail.md:5:16 | LL |     let x = 234 // no semicolon here! oh no! |                ^ help: add `;` here LL | } | - unexpected token error: aborting due to 1 previous error Couldn't compile the test. failures: $DIR/doctest-output-include-fail.md - (line 3) test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME </ins>

Discussion:
The repro repository has everything: Expected behavior is that the diagnostics have: , but they currently have .
cc (as per )
Thanks for opening the issue! I'm surprised since it's an issue that was supposed to be fixed in Just to confirm: which rustc version do you use? Also cc since you're the one who fixed this bug.
This happened with 1.81 most likely — I would take the few secs to check but I’m on a phone right now.
The doctest system needs to use the same infrastructure as the rest of rustdoc.
I can confirm this does fix my repro: ! Would you like a separate issue for the part where it says when really it could normalize the path and just say ?
Yes please!
filed as
Thanks! Gonna take a look in the next days if someone else didn't do it before then.
Change:
baz(|_| ()); //~^ ERROR implementation of `FnOnce` is not general enough //~| ERROR mismatched types <ins> baz(|x| ()); //~^ ERROR implementation of `FnOnce` is not general enough //~| ERROR mismatched types </ins> }

Discussion:
a new project with (in my case, it used pathfinding version 4.0.0 or 4.0.1) with: produces the following output: For the two closures ( and ), if I add a type for the parameter by changing to , it builds without any errors. If it had told me that it needed type annotations, I would have understood the problem and been able to fix it right away. (I assumed that there was enough type information for it to infer the correct types.) The first confusing bit is that both errors highlight the entire call to , including all parameters. This makes it harder to figure out which one it is complaining about (though the second note contains the line number). Does the first argument have something to do with the lifetimes it is complaining about? I found this part of the message hard to understand: The type parameters look almost identical, and the didn't make sense to me. Could it somehow indicate the bounds of that lifetime (2), or better explain why that lifetime doesn't last long enough? FYI: found as part of solving Advent of Code 2022, Day 12. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A smaller MCVE:
I'm thinking whether we should fix this as a compiler bug (i.e., make it compile) or suggesting people write explicit type here
maybe related:
Also if we move the closure to the parameter: This will also compile. Combined with , I guess something is wrong with propagating lifetime of closures when we store it in a variable...
claim
Change:
<ins> fn r#fn() {} fn main() { let r#final = 1; // Should correctly suggest variable defined using raw identifier. fina; //~ ERROR cannot find value // Should correctly suggest function defined using raw identifier. f(); //~ ERROR cannot find function } </ins>

Discussion:
Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.
Change:
} #[stable(feature = "collection_debug", since = "1.17.0")] <del> impl<'a, K: 'a + fmt::Debug, V: 'a + fmt::Debug> fmt::Debug for Keys<'a, K, V> { </del> <ins> impl<'a, K: 'a + fmt::Debug, V: 'a> fmt::Debug for Keys<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> f.debug_list().entries(self.inner.clone()).finish() </del> <ins> f.debug_list().entries(self.clone()).finish() </ins> } }

Discussion:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.