jiebi/CodeConvo huggingface dataset:
Code change:
Const generic defaults are being stabilized, <!-- 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 --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ? Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta

Related discussion:
text: <ins> error[E0771]: use of non-static lifetime `'a` in const generic --> $DIR/outer-lifetime-in-const-generic-default.rs:4:17 | LL |         let x: &'a (); |                 ^^ | = note: for more information, see issue #74052 <https://github.com/rust-lang/rust/issues/74052> error: aborting due to previous error For more information about this error, try `rustc --explain E0771`. </ins>
Code change:
Context: - the test had to be disabled there to get a fix in With running the UI tests targeting wasm32 causes this failure with LLVM asserts enabled: With LLVM asserts disabled it produces invalid wasm bytecode: Manually executing the rustc command printed by the UI test and adding generates the following IR . Running that through (built by bootstrap) also produces invalid bytecode (checked with ). Tested on base commit + PR (currently ) ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Quick observations: The failing assert: Looking at the , it seems like the only way this assert could fail is if the value is too large to fit in the specified number of bytes. There are two calls to , and one of them has a check for out-of-range values already, so it's probably in .
No longer blocks the PR, it now disables the test on wasm32 instead.
Upstream issue:

Related discussion:
text: // The new pass manager is enabled by default for LLVM >= 13. // This matches Clang, which also enables it since Clang 13. <del> // FIXME: There are some perf issues with the new pass manager // when targeting s390x, so it is temporarily disabled for that // arch, see https://github.com/rust-lang/rust/issues/89609 user_opt.unwrap_or_else(|| target_arch != "s390x" && llvm_util::get_version() >= (13, 0, 0)) </del> <ins> // There are some perf issues with the new pass manager when targeting // s390x with LLVM 13, so enable the new pass manager only with LLVM 14. // See https://github.com/rust-lang/rust/issues/89609. let min_version = if target_arch == "s390x" { 14 } else { 13 }; user_opt.unwrap_or_else(|| llvm_util::get_version() >= (min_version, 0, 0)) </ins> }
Code change:
Context: - the test had to be disabled there to get a fix in With running the UI tests targeting wasm32 causes this failure with LLVM asserts enabled: With LLVM asserts disabled it produces invalid wasm bytecode: Manually executing the rustc command printed by the UI test and adding generates the following IR . Running that through (built by bootstrap) also produces invalid bytecode (checked with ). Tested on base commit + PR (currently ) ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Quick observations: The failing assert: Looking at the , it seems like the only way this assert could fail is if the value is too large to fit in the specified number of bytes. There are two calls to , and one of them has a check for out-of-range values already, so it's probably in .
No longer blocks the PR, it now disables the test on wasm32 instead.
Upstream issue:

Related discussion:
text: <del> Subproject commit e29ac13bc97e26f886c3bfe72f9135e994c3cd0a </del> <ins> Subproject commit c8eccf626fb5bb851b2ade93af8851ca1523807f </ins>
Code change:
Context: - the test had to be disabled there to get a fix in With running the UI tests targeting wasm32 causes this failure with LLVM asserts enabled: With LLVM asserts disabled it produces invalid wasm bytecode: Manually executing the rustc command printed by the UI test and adding generates the following IR . Running that through (built by bootstrap) also produces invalid bytecode (checked with ). Tested on base commit + PR (currently ) ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Quick observations: The failing assert: Looking at the , it seems like the only way this assert could fail is if the value is too large to fit in the specified number of bytes. There are two calls to , and one of them has a check for out-of-range values already, so it's probably in .
No longer blocks the PR, it now disables the test on wasm32 instead.
Upstream issue:

Related discussion:
text: // run-pass <del> // ignore-wasm32-bare FIXME(#93923) llvm miscompilation </del> use std::collections::HashMap; use std::path::Path;
Code change:
<!-- 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: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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. --: cc labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.

Related discussion:
text: <ins> // Issue #94176: wrong span for the error message of a mismatched type error, // if the function uses a `let else` construct. #![feature(let_else)] pub fn test(a: Option<u32>) -> Option<u32> { //~ ERROR mismatched types let Some(_) = a else { return None; }; println!("Foo"); } fn main() {} </ins>
Code change:
<!-- 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: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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. --: cc labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/issue-94176.rs:5:32 | LL | pub fn test(a: Option<u32>) -> Option<u32> { |        ----                    ^^^^^^^^^^^ expected enum `Option`, found `()` |        | |        implicitly returns `()` as its body has no tail or `return` expression | = note:   expected enum `Option<u32>` found unit type `()` help: consider returning the local binding `a` | LL ~     println!("Foo"); LL +     a | error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
<!-- 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: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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. --: cc labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.

Related discussion:
text: <ins> // // popped up in in #94012, where an alternative desugaring was // causing unreachable code errors #![feature(let_else)] #![deny(unused_variables)] #![deny(unreachable_code)] fn let_else_diverge() -> bool { let Some(_) = Some("test") else { let x = 5; //~ ERROR unused variable: `x` return false; }; return true; } fn main() { let_else_diverge(); } </ins>
Code change:
<!-- 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: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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. --: cc labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.

Related discussion:
text: <ins> error: unused variable: `x` --> $DIR/let-else-then-diverge.rs:11:13 | LL |         let x = 5; |             ^ help: if this is intentional, prefix it with an underscore: `_x` | note: the lint level is defined here --> $DIR/let-else-then-diverge.rs:6:9 | LL | #![deny(unused_variables)] |         ^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
While checking whether the can be ported from typenum to nightly with , I hit this warning. I am not sure whether it's a false positive or whether the behavior I want is meant to be disallowed, but I think it should be allowed when enabling . I've reduced the code though I left some stuff to show why it would be useful. Originally posted by in
is emitted if we successfully evaluate an anonymous constant with generic const arguments. Anonymous constants currently inherit all of their parents generics, so for the constant has both and in scope, even though it only uses . This would mean that pretty much all anonymous constants would cause that lint, so we add a flag to their MIR to detect whether they actually use any generic parameter: uses so that flag is true. The problem is now that is concrete, so evaluating the constant is successful, but the constant refers to which is still generic. We should just disable the lint if is enabled :shrug: cc
Another similar. Short example failing on Nightly (thanks to ilyvion for narrowing it down): My use case: I know it's a semantic/voluntary constraint only, and it's quite recursive, but I believe it deserves its place. (Alternatives I tried are at )
this has been fixed, needs test to close

Related discussion:
text: <ins> // check-pass #![feature(generic_const_exprs)] #![allow(incomplete_features)] #![deny(const_evaluatable_unchecked)] pub struct If<const CONDITION: bool>; pub trait True {} impl True for If<true> {} pub struct FixedI8<const FRAC: u32> { pub bits: i8, } impl<const FRAC_LHS: u32, const FRAC_RHS: u32> PartialEq<FixedI8<FRAC_RHS>> for FixedI8<FRAC_LHS> where If<{ FRAC_RHS <= 8 }>: True, { fn eq(&self, _rhs: &FixedI8<FRAC_RHS>) -> bool { unimplemented!() } } impl<const FRAC: u32> PartialEq<i8> for FixedI8<FRAC> { fn eq(&self, rhs: &i8) -> bool { let rhs_as_fixed = FixedI8::<0> { bits: *rhs }; PartialEq::eq(self, &rhs_as_fixed) } } fn main() {} </ins>
Code change:
<!-- 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 --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim

Related discussion:
text: target: Target, item: Option<ItemLike<'_>>, ) -> bool { <del> let is_function = matches!(target, Target::Fn | Target::Method(..)); </del> <ins> let is_function = matches!(target, Target::Fn); </ins> if !is_function { self.tcx .sess
Code change:
<!-- 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 --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim

Related discussion:
text: #[rustc_legacy_const_generics(0)] //~ ERROR #[rustc_legacy_const_generics] functions must only have fn foo8<X>() {} <ins> impl S { #[rustc_legacy_const_generics(0)] //~ ERROR attribute should be applied to a function fn foo9<const X: usize>() {} } </ins> #[rustc_legacy_const_generics] //~ ERROR malformed `rustc_legacy_const_generics` attribute fn bar1() {}
Code change:
<!-- 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 --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim

Related discussion:
text: = help: instead of using a suffixed literal (`1u8`, `1.0f32`, etc.), use an unsuffixed version (`1`, `1.0`, etc.) error: malformed `rustc_legacy_const_generics` attribute input <del> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:32:1 </del> <ins> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:37:1 </ins> | LL | #[rustc_legacy_const_generics] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: must be of the form: `#[rustc_legacy_const_generics(N)]` error: malformed `rustc_legacy_const_generics` attribute input <del> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:35:1 </del> <ins> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:40:1 </ins> | LL | #[rustc_legacy_const_generics = 1] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: must be of the form: `#[rustc_legacy_const_generics(N)]`
Code change:
<!-- 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 --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim

Related discussion:
text: |         - non-const generic parameter error: attribute should be applied to a function <ins> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:33:5 | LL |     #[rustc_legacy_const_generics(0)] |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     fn foo9<const X: usize>() {} |     ---------------------------- not a function error: attribute should be applied to a function </ins> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:25:5 | LL |     #[rustc_legacy_const_generics(1)]
Code change:
<!-- 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 --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim

Related discussion:
text: | = help: replace the const parameters with concrete consts <del> error: aborting due to 12 previous errors </del> <ins> error: aborting due to 13 previous errors </ins> For more information about this error, try `rustc --explain E0044`.
Code change:
iterates over (which point to a slice of bytes in memory). When the code points expire (no more bytes available in the slice), there is no chance of the iterator ever returning more values. Therefore, should implement . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is currently fused in practice and I don't think there's a good reason to change that in the future. This would technically be an API change but one that should have no negative impact to existing code. Which is the long winded way of saying I agree.
Thanks for the quick response! I realize that this is an API change but didn't feel it'd warrant a "feature suggestion". I guess for now I'm just throwing the idea out there.
This is a great idea and I'd be happy to see a PR that implements it. I was just ticking off a checklist. It's not a breaking change and it is useful, so implementing it should not be at all controversial.
Sounds good, I'll get to it tomorrow! claim
Note that, procedurally, a new trait impl is insta-stable so will need a FCP. (That's totally ok, just wanted to note it. You can and should send a PR for it.)

Related discussion:
text: use crate::collections::TryReserveError; use crate::fmt; use crate::hash::{Hash, Hasher}; <del> use crate::iter::FromIterator; </del> <ins> use crate::iter::{FromIterator, FusedIterator}; </ins> use crate::mem; use crate::ops; use crate::rc::Rc;