jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0308]: mismatched types --> $DIR/loop-no-implicit-break.rs:3:9 | LL |         1 |         ^ expected `()`, found integer | help: you might have meant to break the loop with this value | LL |         break 1; |         ^^^^^  ^ error[E0308]: mismatched types --> $DIR/loop-no-implicit-break.rs:13:9 | LL |         1 |         ^ expected `()`, found integer | help: you might have meant to break the loop with this value | LL |         break 1; |         ^^^^^  ^ error[E0308]: mismatched types --> $DIR/loop-no-implicit-break.rs:21:9 | LL |         1 |         ^ expected `()`, found integer | help: you might have meant to return this value | LL |         return 1; |         ^^^^^^  ^ error[E0308]: mismatched types --> $DIR/loop-no-implicit-break.rs:29:9 | LL |         1 |         ^ expected `()`, found integer | help: you might have meant to return this value | LL |         return 1; |         ^^^^^^  ^ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --It may not be immediately clear to a user why implicit-return/break style works for expressions, but not for . Adding a hint to explicitly break with would be helpful. <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-suggestion-diagnostics
claim
Change:
<ins> warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/sized-late-bound-issue-114872.rs:3:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-02-18 commit[0] 2023-02-16: Auto merge of - matthiaskrgr:rollup-kpzfc6j, r=matthiaskrgr commit[1] 2023-02-16: Auto merge of - Zoxc:arena-query-clean, r=cjgillot commit[2] 2023-02-17: Auto merge of - matthiaskrgr:rollup-bgadak1, r=matthiaskrgr commit[3] 2023-02-17: Auto merge of - kylematsuda:type-of, r=BoxyUwU commit[4] 2023-02-17: Auto merge of - Zoxc:query-ctxtx-byval, r=cjgillot commit[5] 2023-02-17: Auto merge of - BoxyUwU:addconstarghastype_predicate, r=compiler-errors commit[6] 2023-02-17: Auto merge of - matthiaskrgr:rollup-5k2j7cx, r=matthiaskrgr commit[7] 2023-02-17: Auto merge of - WaffleLapkin:de-arena-allocates-you-OwO, r=Nilstrieb
It's just the non-lifetime binders pr:
Change:
fn point_at_returns_when_relevant( &self, <del> err: &mut Diagnostic, </del> <ins> err: &mut DiagnosticBuilder<'tcx, ErrorGuaranteed>, </ins> obligation: &PredicateObligation<'tcx>, ) { match obligation.cause.code().peel_derives() {

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: We shouldn't show here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
without
another one 
What ideal output would you suggest? Should we remove the suggestion line like:
Ideally we should be checking that the return type . If it's not suggestable, don't mention it.
claim
I actually believe that neither the E0029 nor the E0277 should have been emitted. I would check explicitly for and change the error to be (that way the error isn't printed out, but rustc will ICE if no other error is emitted, which should have happened).
The PR will prevent E0029 and E0277 from printing out after checking the type references.
Change:
<del> //@ known-bug: rust-lang/rust#126521 macro_rules! foo { ($val:ident) => { true; }; } fn main() { #[expect(semicolon_in_expressions_from_macros)] let _ = foo!(x); } </del>

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: matches!(, Error Allow)'' 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: [earlylintchecks] perform lints prior to macro expansion [hircrate] getting the crate HIR -- label +F-stmtexpr_attributes
bisects to :thinking: cc edit: ah the assertion was there...
Change:
os.unlink(temp_path) <del> def download(path, url, probably_big, verbose, help_on_error=None): </del> <ins> def download(path, url, probably_big, verbose): </ins> for _ in range(0, 4): try: <del> _download(path, url, probably_big, verbose, True, help_on_error=help_on_error) </del> <ins> _download(path, url, probably_big, verbose, True) </ins> return except RuntimeError: print("nspurious failure, trying again") <del> _download(path, url, probably_big, verbose, False, help_on_error=help_on_error) </del> <ins> _download(path, url, probably_big, verbose, False) </ins> <del> def _download(path, url, probably_big, verbose, exception, help_on_error=None): </del> <ins> def _download(path, url, probably_big, verbose, exception): </ins> # Try to use curl (potentially available on win32 #    https://devblogs.microsoft.com/commandline/tar-and-curl-come-to-windows/) # If an error occurs:

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
<ins> // edition:2018 // revisions: full min #![cfg_attr(full, feature(const_generics))] #![cfg_attr(full, allow(incomplete_features))] #![cfg_attr(min, feature(min_const_generics))] struct Foo; impl<const H: feature> Foo { //~^ ERROR: expected type, found built-in attribute `feature` //~^^ ERROR: the const parameter `H` is not constrained by the impl trait, self type, or predicates async fn biz() {} } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Related to .
My hunch is that this code: needs to be generalized to also accept a . The function could just return (or maybe ) in that case and I expect the ICE would go away.
I'm tagging this as E-mentor because of the above instructions (feel free to also ping me on Zulip)
claim
Change:
<ins> #![crate_type = "lib"] #![feature(transmutability)] trait A { type AssocA; } trait B { type AssocB: std::mem::TransmuteFrom<()>; } impl<T> B for (T, u8) where T: A, { type AssocB = T::AssocA; //~ERROR: the trait bound `<T as A>::AssocA: TransmuteFrom<(), Assume { alignment: false, lifetimes: false, safety: false, validity: false }>` is not satisfied [E0277] } impl<T> B for (T, u16) where for<'a> &'a i32: A, { type AssocB = <&'static i32 as A>::AssocA; //~ERROR: `()` cannot be safely transmuted into `<&i32 as A>::AssocA` } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' File: --auto-reduced (treereduce-rust): original: Version 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: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
--> $DIR/empty-struct-tuple-pat.rs:29:9 | LL |         E::Empty4 => () <del> |         ^^^^^^^^^ not a unit struct/variant or constant </del> <ins> |         ^^^^^^^^^ did you mean `E::Empty4 ( /* fields */ )`? </ins> error[E0532]: expected unit struct/variant or constant, found tuple variant `XE::XEmpty5` --> $DIR/empty-struct-tuple-pat.rs:33:9 | LL |         XE::XEmpty5 => (), |         ^^^^------- <del> |             | |             help: a unit variant with a similar name exists: `XEmpty4` </del> <ins> |         |   | |         |   help: a unit variant with a similar name exists: `XEmpty4` |         did you mean `XE::XEmpty5 ( /* fields */ )`? </ins> error: aborting due to 4 previous errors

Discussion:
Code Example (): <img width="805" alt="image" src="https://user-"Currently we provide a "do you mean..." for the but not for the . We probably should provide one for both.
Consider fixing Btw (which is a similar enhancement)
I'd like to work on this if it is still available.
go ahead! Ideally, you could turn the output into but just changing the tuple case would be enough.
I created a PR, could you please help review. I took a look at your suggestion of updating all the errors to , that seemed too many changes, not sure if it was necessary, so I just the tuple case.
Change:
<ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/region-error-ice-109072.rs:8:9 | LL | impl Lt<'missing> for () { |     -   ^^^^^^^^ undeclared lifetime |     | |     help: consider introducing lifetime `'missing` here: `<'missing>` error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/region-error-ice-109072.rs:9:15 | LL |     type T = &'missing (); |               ^^^^^^^^ undeclared lifetime | help: consider introducing lifetime `'missing` here | LL |     type T<'missing> = &'missing (); |           ++++++++++ help: consider introducing lifetime `'missing` here | LL | impl<'missing> Lt<'missing> for () { |     ++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0261`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 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: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.
Change:
[[package]] name = "thiserror" <del> version = "1.0.40" </del> <ins> version = "1.0.47" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "978c9a314bd8dc99be594bc3c175faaa9794be04a5a5e153caba6915336cebac" </del> <ins> checksum = "97a802ec30afc17eee47b2855fc72e0c4cd62be9b4efe6591edde0ec5bd68d8f" </ins> dependencies = [ "thiserror-impl", ]

Discussion:
Error message says it all: This is probably related to It goes away when I . Looks like the thiserror build script is caching its output too aggressively, so it doesn't notice that it needs to be rerun? Cc
As far as I understand, this is a bootstrap bug, not caching. See 1st paragraph of
Although, sounds like I'm wrong because I wouldn't have expected to help. ¯()/¯ I don't know of anything the thiserror build script is doing wrong with regard to caching.
I think you mean , which I'd say is a cargo limitation. But indeed then clearing my build cache wouldn't have helped... Here we don't have a proc macro dependency I think, so I don't think it is that problem.
I think what happens is that usually, when the rustc version changes, cargo will rerun build scripts automatically. But here the rustc version is always and so even though the output of running on a particular file can change, cargo keeps using the old cache. thiserror would have to say "rerun if the output of running might change", but it doesn't have a way to do that. (The rustc binary didn't even change, the sysroot did.) Maybe bootstrap should delete the cached build script output when the stage0 library artifacts change? Not sure if it even knows that this is the case though. Cc
Will check what we can do on the bootstrap side by the coming weekend. Thanks for the ping.
Hm, we usually rely on Cargo doing the rebuild as a result of depinfo containing references to the sysroot when it uses it (via -Zbinary-dep-depinfo), but in this case that doesn't get passed since we don't control the rustc invocation. I'm not sure we have a good way of recognizing when we need the rebuild and when we don't; we wouldn't want to always clear build scripts because that would cause many more spurious rebuilds...
Hm yeah, maybe the right solution is for cargo to provide a native way of doing "probe builds", that integrates with its caching...
Fixing this on bootstrap will most likely require implementing hacky tricks(like creating/moving some values as files between outputs and comparing them each time on the compilations) and that could make our complex flow even more confusing.

And there's a good chance these things could cause unexpected problems that are hard to detect. +1
FWIW for now thiserror is working around this via
Change:
)); // This is effectively `{ let _result = ...; _result }`. <del> // The construct was introduced in #21984. // FIXME(60253): Is this still necessary? </del> <ins> // The construct was introduced in #21984 and is necessary to make sure that // temporaries in the `head` expression are dropped and do not leak to the // surrounding scope of the `match` since the `match` is not a terminating scope. // </ins> // Also, add the attributes to the outer returned expr node. return self.expr_drop_temps(head_sp, match_expr, e.attrs.clone()) }

Discussion:
See:
for future reference: is referencing my PR which changed the r-value temporary rules with respect to the temporaries in the of
Even beside the part the loop desugaring is so complex. It would be nice to document what every employed trick changes compared to the naive desugaring.
PR itself was motivated (or at least spawned off of) PR . I'm actually trying to find out what the actual motivation for the described change was. The change, as described, was that the temporaries within would previously live until the end of the enclosing block. So if you consider the following code (): which, when it is accepted by the compiler (as written it requires NLL), it should print this: notably, we drop all of {, , } immediately after the for-statement, but before the at the end of the block. The breakage I would be concerned about, if we made for-loops no longer a terminating scope for their , is that all of the temps would live until the end of the block, and thus the drops of {, , } would happen after the "end of enclosing block", which would be an observable change. has relayed to me in private conversation that they tried examples like this under variants of their desugaring and did not witness any change in behavior. Our best guess as to why this is, is because the desugaring is, in the end, turning into a which is itself a terminating scope for the temporaries in the -input, and so you don't need to recreate such an effect by other means.
Note: it is nonetheless possible that the distinction here is more subtle and my above example isn't quite right. in particular, I'm a little worried that there may have been a reason that the example from PR puts the for-expression in the tail expression of a block, and that examples that don't take similar care might fail to pick up on a relevant distinction here...
Change:
<ins> fn take_str_maybe(x: Option<&str>) -> Option<&str> { None } fn main() { let string = String::from("Hello, world"); let option = Some(&string); take_str_maybe(option); //~^ ERROR: mismatched types [E0308] } </ins>

Discussion:
can easily be converted to , but we give a somewhat opaque E0308 when with the following situation: This results in: Which is not totally clear to people who do not understand the trait and/or do not know that it is implemented for these types. We should suggest that the user use to convert between these types. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
only works for and not for There are a couple of options I thought about, if there is a better one i'd be happy to use it: tell the user to pass a instead of a and use try to find where the parameter comes from and tell the user to remove the & sign and use if this is the last instance where the was used just handle the cases in which a is passed try to find a Copy or Clone impl on the struct and suggest to use it and use (this one seems like the most unsafe for arbitrary types, but in this particular case it would work) sorry for the inconvenience, I am new to rustc and I am currently trying to get started with this issue.
another option that would remain more local than finding where the was constructed is to try and suggest for that case in particular. Having said that, finding where the was constructed would be great because it's a type that is almost always wrong to use, unless it comes from a place where you end up with that because of type params (like a hashmap or another container), so it'd be good to lead people towards better code. What you can do is indeed split your work and focus on making the case work on its own PR, and then follow up with an attempt to handle .
Change:
tcx, root_span, param_env, <del> CompileTimeInterpreter::new(tcx.const_eval_limit(), can_access_statics), </del> <ins> CompileTimeInterpreter::new( tcx.const_eval_limit(), can_access_statics, /*check_alignment:*/ false, ), </ins> ) }

Discussion:
code from rustc this causes a new panic when executed via miri:
Ah, there was a reason why we disabled alignment checks in CTFE... This can probably be reproduced without Miri by passing -Zextra-const-ub-checks to rustc.
Yeah this just need "cargo miri run", no additional flags required. Edit: oops, misread :sweat_smile:
Right, this does also reproduce with . Do you want to move the issue?
Yeah let's move this to the rustc repo.
Change:
<ins> // check-pass const FOO: isize = 10; const ZST: &() = unsafe { std::mem::transmute(FOO) }; fn main() { match &() { ZST => 9, }; } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Assigning and removing as as part of the prioritization working group procedure.
searched nightlies: from nightly-2020-09-16 to nightly-2020-09-29 regressed nightly: nightly-2020-09-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Cc