jiebi/CodeConvo huggingface dataset:
Change:
working_dir: env::current_dir().unwrap(), lint_store: RefCell::new(lint::LintStore::new()), lints: RefCell::new(NodeMap()), <ins> one_time_diagnostics: RefCell::new(FnvHashSet()), </ins> plugin_llvm_passes: RefCell::new(Vec::new()), mir_passes: RefCell::new(mir_pass::Passes::new()), plugin_attributes: RefCell::new(Vec::new()),

Discussion:
Example: Adding to a crate will point out the location of this line for every time the lint fires (). This should be listed only once. It should be reasonably easy to deduplicate these based upon equal span and message.
I think this is a good "E-easy" candidate. Relevant code is in . Using a as a field on should work, so that we only emit a note the first time we encounter it.
Question -- in , we get only "lint level defined here" per , even if it applies to multiple lints (e.g., ). Do people think it'd be better to have it like this, or would you rather see different messages for (say) and , even if they both apply to the same ?
Can someone with perms close this? I forgot to use the in .
Great! Fixed in
Change:
<ins> // Copyright 2016 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. // rustc-env:RUST_NEW_ERROR_FORMAT trait Parser<T> { fn parse(text: &str) -> Option<T>; } impl<bool> Parser<bool> for bool { fn parse(text: &str) -> Option<bool> { Some(true) } } fn main() { println!("{}", bool::parse("ok").unwrap_or(false)); } </ins>

Discussion:
This code is wrong, but the error message is confusing: Because I used accidentally as a type name when not using the right syntax ... this is pretty confusing:
One solution would be to add detail after the expected/found lines if primitive shadowing has come into play. This would not change the language, but make the error look like:
Change:
println!("{:?}", nums); ``` <del> This gives us: </del> <ins> We get this error: </ins> ```text note: `nums` moved into closure environment here because it has type

Discussion:
Right before the "move closures" section, the book doesn't really make it clear that this code would not compile: It shows part of the compile error, but it just looks like a non-error message from the compiler. Consider appending "the error message" to "This gives us".
Change:
LL |             break; |             ~~~~~ <del> error: aborting due to 2 previous errors </del> <ins> error[E0571]: `break` with value from a `while` loop --> $DIR/issue-114529-illegal-break-with-value.rs:22:9 | LL |       while true { |       ---------- you can't `break` with a value in a `while` loop LL | /         break (|| { LL | |             let local = 9; LL | |         }); | |__________^ can only break with a value inside `loop` or breakable block | help: use `break` on its own without a value inside this `while` loop | LL |         break; |         ~~~~~ error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0571`.

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no type for local variable HirId(DefId(0:3 ~ E798F6428C27040F6BCB788CE3C70B28DC596BC8C3AD45A9CC67EC872D6B13EF[a927]::main).70) (local )', 'error: internal compiler error: no type for local variable HirId(DefId(0:3 ~ E798F6428C27040F6BCB788CE3C70B28DC596BC8C3AD45A9CC67EC872D6B13EF[a927]::main).70) (local )' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- TRIAGEBOTSTART --&lt;!-- TRIAGEBOTASSIGNSTART --&lt;!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --&lt;!-- TRIAGEBOTASSIGNEND --&lt;!-- TRIAGEBOTEND --
Regression in nightly-2023-10-31 Regression in = ping
reduced a bit further:
claim
Change:
<ins> // check-pass #[allow(unused)] fn test<T, F, U>(f: F) -> Box<dyn Fn(T) -> U + 'static> where F: 'static + Fn(T) -> U, for<'a> U: 'a, // < This is the problematic line, see #97607 { Box::new(move |t| f(t)) } fn main() {} </ins>

Discussion:
See https://crater- This is a 1.62 regression, it seems, based on Crater. At the very least, it's a diagnostics issue that we're suggesting adding an already existing lifetime bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-04-01 to nightly-2022-05-31 regressed nightly: nightly-2022-05-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details, cc
The issue is that bound is causing the new wf check introduced in to fail. Regarding the diagnostics being weird, the issue is probably because we don't handle the case where a higher-ranked lifetime doesn't outlive itself. We just see a borrowck error, see that it's due to the binder's lifetime, and suggest adding it. Not sure if that needs fixed, personally think it's not worth it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
This got fixed on nightly by enabling nll by default
claim For the test
Change:
fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { // This pass must run before inlining, since we insert callee bodies in RevealAll mode. // Do not apply this transformation to generators. <del> if (tcx.sess.mir_opt_level() >= 3 || !super::inline::is_enabled(tcx)) </del> <ins> if (tcx.sess.mir_opt_level() >= 3 || super::inline::is_enabled(tcx)) </ins> && body.generator.is_none() { let param_env = tcx.param_env_reveal_all_normalized(body.source.def_id());

Discussion:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc
Change:
margin: 0 0 10px; } <ins> footer { border-top: 1px solid #ddd; font-size: 12px; font-style: italic; padding-top: 4px; margin-top: 4em; margin-bottom: 1em; } </ins> /* Links layout ========================================================================== */ a {

Discussion:
Per we should have the docs licensed correctly. Nominating.
I can have a look at this.
Change:
<ins> // Copyright 2014 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. trait Tr { fn test<X>(u: X) -> Self { u   //~ ERROR mismatched types } } fn main() {} </ins>

Discussion:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:
Change:
fn parse_async_block(&mut self, mut attrs: AttrVec) -> PResult<'a, P<Expr>> { let lo = self.token.span; self.expect_keyword(kw::Async)?; <del> let capture_clause = self.parse_capture_clause(); </del> <ins> let capture_clause = self.parse_capture_clause()?; </ins> let (iattrs, body) = self.parse_inner_attrs_and_block()?; attrs.extend(iattrs); let kind = ExprKind::Async(capture_clause, DUMMY_NODE_ID, body);

Discussion:
I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim
Change:
} pub(crate) fn maybe_recover_unexpected_block_label(&mut self) -> bool { <del> let Some(label) = self.eat_label().filter(|_| { self.eat(&token::Colon) && self.token.kind == token::OpenDelim(Delimiter::Brace) }) else { </del> <ins> // Check for `'a : {` if !(self.check_lifetime() && self.look_ahead(1, |tok| tok.kind == token::Colon) && self.look_ahead(2, |tok| tok.kind == token::OpenDelim(Delimiter::Brace))) { </ins> return false; <del> }; </del> <ins> } let label = self.eat_label().expect("just checked if a label exists"); self.bump(); // eat `:` </ins> let span = label.ident.span.to(self.prev_token.span); let mut err = self.struct_span_err(span, "block label not supported here"); err.span_label(span, "not supported here");

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: The compiler rejects all these expressions as the lifetimes are in a nonsensical position. Instead, this happened: The compiler accepted the expressions without saying anything This behavior seems to occur since 1.61. 60 and below properly reject the code.
This very likely regressed in , I'll put up a fix in like 30 mins.
For the record -- Bisection points at: found 9 bors merge commits in the specified range commit[0] 2022-02-27UTC: Auto merge of - scottmcm:cfg-out-miri-from-swap, r=oli-obk commit[1] 2022-02-27UTC: Auto merge of - erikdesjardins:more-noundef, r=nikic commit[2] 2022-02-28UTC: Auto merge of - matthiaskrgr:rollup-1jsj0wu, r=matthiaskrgr commit[3] 2022-02-28UTC: Auto merge of - RalfJung:miri, r=RalfJung commit[4] 2022-02-28UTC: Auto merge of - erikdesjardins:more-more-noundef, r=nikic commit[5] 2022-02-28UTC: Auto merge of - cjgillot:inline-fresh-expn, r=oli-obk commit[6] 2022-02-28UTC: Auto merge of - psumbera:sparc64-abi-fix2, r=nagisa commit[7] 2022-02-28UTC: Auto merge of - matthiaskrgr:rollup-d8rj2xv, r=matthiaskrgr commit[8] 2022-02-28UTC: Auto merge of - matthiaskrgr:rollup-xv9y98j, r=matthiaskrgr
label +T-compiler +A-parser +A-lifetimes
Change:
dependencies = [ "fm", "getopts", <del> "libc 0.2.112", </del> <ins> "libc", </ins> "num_cpus", "termcolor", "threadpool",

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
<del> error: expected one of `.`, `;`, `?`, `}`, or an operator, found `assert_eq` --> $DIR/macros-no-semicolon.rs:3:5 </del> <ins> error: expected `;`, found `assert_eq` --> $DIR/macros-no-semicolon.rs:2:21 </ins> | LL |     assert_eq!(1, 2) <del> |                     - expected one of `.`, `;`, `?`, `}`, or an operator </del> <ins> |                     ^ help: add `;` here </ins> LL |     assert_eq!(3, 4) <del> |     ^^^^^^^^^ unexpected token </del> <ins> |     --------- unexpected token </ins> <del> error: aborting due to previous error </del> <ins> error: expected `;`, found `println` --> $DIR/macros-no-semicolon.rs:3:21 | LL |     assert_eq!(3, 4) |                     ^ help: add `;` here LL |     println!("hello"); |     ------- unexpected token error: aborting due to 2 previous errors </ins>

Discussion:
: The current output is: We should detect cases where a semicolon would be appropriate (probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own) and suggest a semicolon. . We might want to silence one or the other depending on whether the current token might be starting a statement or an item ( vs , etc.). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Sorry, I don't have much time these days. release-assignment
Just a guess: could this be addressed with another block, as in
I think we would need to answer this question: why is the logic here not handling the cases we want to handle?
This seems to be on track given the clue "probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own"...
claim
release-assignment
That is a great question: as the code is written it looks like it should work. I don't know why it isn't triggering :( It might be that isn't being called in these case. It might be a good idea to uplift most of this method into
I'd like to give this a try. claim
Change:
<ins> error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds --> $DIR/issue-87258_b.rs:21:21 | LL |     fn foo<'a>() -> Self::FooFuture<'a> { |                     ^^^^^^^^^^^^^^^^^^^ | = note: hidden type `Struct<'_>` captures lifetime '_#7r error: aborting due to previous error For more information about this error, try `rustc --explain E0700`. </ins>

Discussion:
: (Also ) <details<summary<strongBacktrace</strong</summary<p</p</details
Issue might be related (or this may be a duplicate of it).
This seems to be caused by Re-inserting gets rid of the ICE. What was the rationale for deleting that function?
It was replacing inference lifetimes with concrete ones (but wrong ones, as it was using lifetimes from a completely different item). This avoided certain ICEs and was even correct by accident for the example in the doc comment, but it was just papering over the ICEs causing other examples (where the impl trait is outside the current impl block) to fail. I am looking into this new ICE now
I am getting locally before the ICE, so likely the ICE just hides actual errors. Should still fix that of course, but needs more looking into it
I think you need to use 2018 or 2021 edition.
minimized and edition-free: The problem is that typeck runs some of old borrowck/regionck and that just can't handle GAT and associated TAIT being used together. While worked in this specific case, that function won't work if the TAIT were declared outside the impl block and only used, so the following would just hit a different ICE, even though it should be equivalent (except that the defining use scope is the surrounding module instead of just the impl block).
So... turns out this works just fine with nll... I'd say we just wait for that, nll is only blocked on diagnostics, and those are actively being worked on:
I've found this does work if adding a bound on the TAIT: . It seems to me that should be required, so accepting code without it was actually a bug? Also, how does this work with NLL? I add and it still ICEs. (see the playground). Is there anything else needed for enabling NLL?
It seems the linked example on the playground does not ICE on the 2021-08-03 nightly.
that's with the fixed . Without it it ICEs, both with and without NLL
Hum, indeed, the 2 minimized examples Oli mentioned in do ICE with or without .
oof, not sure what I tested here -.- I'll investigate again. But yea, we can just error out instead of ICEing.
This, and no longer ICE since
GATs issue triage: not blocking. Fixed; needs test.
Change:
<ins> error: `self` parameter is only allowed in associated functions --> $DIR/issue-102989.rs:7:15 | LL | fn ref_Struct(self: &Struct, f: &u32) -> &u32 { |               ^^^^ not semantically valid as function parameter | = note: associated functions are those in `impl` or `trait` definitions error[E0412]: cannot find type `Struct` in this scope --> $DIR/issue-102989.rs:7:22 | LL | fn ref_Struct(self: &Struct, f: &u32) -> &u32 { |                      ^^^^^^ not found in this scope error[E0425]: cannot find value `x` in this scope --> $DIR/issue-102989.rs:11:13 | LL |     let x = x << 1; |             ^ help: a local variable with a similar name exists: `f` error[E0152]: found duplicate lang item `sized` --> $DIR/issue-102989.rs:5:1 | LL | trait Sized { } | ^^^^^^^^^^^ | = note: the lang item is first defined in crate `core` (which `std` depends on) = note: first definition in `core` loaded from SYSROOT/libcore-*.rlib = note: second definition in the local crate (`issue_102989`) error[E0277]: the size for values of type `{integer}` cannot be known at compilation time --> $DIR/issue-102989.rs:11:15 | LL |     let x = x << 1; |               ^^ doesn't have a size known at compile-time | = help: the trait `std::marker::Sized` is not implemented for `{integer}` error[E0308]: mismatched types --> $DIR/issue-102989.rs:7:42 | LL | fn ref_Struct(self: &Struct, f: &u32) -> &u32 { |    ----------                            ^^^^ expected `&u32`, found `()` |    | |    implicitly returns `()` as its body has no tail or `return` expression | note: consider returning one of these bindings --> $DIR/issue-102989.rs:7:30 | LL | fn ref_Struct(self: &Struct, f: &u32) -> &u32 { |                              ^ ... LL |     let x = x << 1; |         ^ error: aborting due to 6 previous errors Some errors have detailed explanations: E0152, E0277, E0308, E0412, E0425. For more information about an error, try `rustc --explain E0152`. </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. --found via fuzzing <!-- 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
It seems that the ICE does not need and no_core feature. A little bit smaller example is:
Change:
<ins> // Copyright 2017 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. #![crate_name = "foo"] #[doc(hidden)] pub trait Foo {} trait Dark {} pub trait Bam {} pub struct Bar; struct Hidden; // @!has foo/struct.Bar.html '//*[@id="impl-Foo"]' 'impl Foo for Bar' impl Foo for Bar {} // @!has foo/struct.Bar.html '//*[@id="impl-Dark"]' 'impl Dark for Bar' impl Dark for Bar {} // @has foo/struct.Bar.html '//*[@id="impl-Bam"]' 'impl Bam for Bar' // @has foo/trait.Bam.html '//*[@id="implementors-list"]' 'impl Bam for Bar' impl Bam for Bar {} // @!has foo/trait.Bam.html '//*[@id="implementors-list"]' 'impl Bam for Hidden' impl Bam for Hidden {} </ins>

Discussion:
See as an example, goes nowhere
Another example: The type is public in this case, but it's explicitly hidden.
Yeah, there's a lot of these.
For , it could be related to re-exported signatures. The same method in doesn't have this issue: Also, is it a bug that you can have private items in a public signature's ? Or private items in an impl for a public type? cc
I wonder if rustdoc should be resolving qualified paths that it encounters.
Is there still some unresolved issue here?
Still a thing; for example, tries to link to types in rand, but the doc link is broken. (That link goes to 1.19.0, but it's still there in today's nightly docs.) If i were to guess, it probably has to do with rustdoc seeing types that are in dependencies of std, but aren't being documented alongside it.
Wrote a fix for it. Will make the PR tomorrow or after tomorrow.
This issue was actually fixed by The issue i actually referenced in that PR was apparently a duplicate of this one.
Change:
# Make sure they don't get set when installing from source. channel = "nightly" download-rustc = false <del> # Build the llvm-bitcode-linker as it is required for running nvptx tests </del> <ins> # Build the llvm-bitcode-linker </ins> llvm-bitcode-linker = true [dist]

Discussion:
With the latest , when I run a run-make test twice in a row, bootstrap rebuilds and : This has to be a recent regression, it didn't happen until ~yesterday. Confirmed with that it also happens for them.
Sounds suspiciously similar to
Yeah this is again caused by being enabled :laughing: Do you think that there's some more general solution to the rebuild problem?
Thanks for notifying me about this. I am travelling this weekend, meaning i might not have a chance to thoroughly investigate before Monday. (But I will at the latest be able to look on Monday). The last time it was due to dependency on the same crates with different rustflags. One from llbc-linker and one from some other tool (rustdoc?). The two different invocations maps to the same cache entry but is invalid between each other and thus triggers a rebuild. The solution last time was to mimic the rustflags being used other places in llbc-linker. That might be a good short term solution now as well. I don't know about the long term solution but it seems like either caching multiple versions of a crate or unifying the rustflag somewhere might be alternatives?
Of course, there's no rush, I just wanted to let you know, given that you already have some experience in debugging this :laughing: This seems rather brittle though, as you mention. I wonder what's so unique about this tool that it causes these rebuilds so often. You mentioned that we cannot share flags between all Step invocations. But maybe it would make sense to better share flags between at least this tool and other steps, rather than hardcoding selected flags? (as was done last time with the parallel compiler).
Actually, I wonder if we really need to enable this linker by default in all four bootstrap profiles.
Sure, seems fine to me. I didn't expect it to be a problem this frequently.
posted instead to disable this flag by default, I don't think it should be enabled for most contributors.