Question:
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

<ins> struct X<const N: usize = { (||1usize)() //~^ ERROR calls in constants are limited to }>; fn main() {} </ins>


Question:
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

<ins> error[E0015]: calls in constants are limited to constant functions, tuple structs and tuple variants --> $DIR/issue-93647.rs:2:5 | LL |     (||1usize)() |     ^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0015`. </ins>


Question:
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

<ins> struct Foo< 'a, const N: usize = { let x: &'a (); //~^ ERROR use of non-static lifetime `'a` in const generic 3 }, >(&'a ()); fn main() {} </ins>


Question:
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

<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>


Question:
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:

// 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> }


Question:
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:

<del> Subproject commit e29ac13bc97e26f886c3bfe72f9135e994c3cd0a </del> <ins> Subproject commit c8eccf626fb5bb851b2ade93af8851ca1523807f </ins>


Question:
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:

// run-pass <del> // ignore-wasm32-bare FIXME(#93923) llvm miscompilation </del> use std::collections::HashMap; use std::path::Path;


Question:
<!-- 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.

<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>


Question:
<!-- 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.

<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>


Question:
<!-- 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.

<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>


Question:
<!-- 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.

<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>


Question:
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

<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>


Question:
<!-- 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

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


Question:
<!-- 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

#[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() {}


Question:
<!-- 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

= 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)]`


Question:
<!-- 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

|         - 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)]


Question:
<!-- 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

| = 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`.


Question:
Our snapshot builder is running CentOS 6.
I think we would have to build on CentOS5 to reliably support RHEL5. Perhaps we should just call it unsupported as we do for old OS X versions? The only alternative I can think of is actually getting a C library like working for Rust and statically linking it in the snapshot builds. Sadly, itself doesn't really support static linking (and is huge).
I agree with I think we could move forward to just supporting RHEL=6.4 Do you agree? Can this bug be closed?
By the way, my earlier mention of musl isn't actually relevant. It only runs on kernels newer than the one offered by RHEL5 anyway.
The thing is that RHEL systems that many people use at work are upgraded rarely because stability is important in complex-shared setups and utmost in production. If I can't get Rust for RHEL5 then it will literally be 5 years before I can use Rust at work. It's not like your macbook where you might as well take the latest OSX after a month or two. We're currently still moving systems to RHEL5 and shutting down HPUX11 and RHEL3 sometime next year. RHEL6 is for new projects only and not used for anything in operations. The thing is that it's kind of a nightmare imagining how you could even get Rust going again on RHEL5 since you need an already-working Rust to bootstrap compiling. You'd have to go back to the last snapshot that worked and start trying to build incrementally-newer versions until you got up-to-date. Maybe you could start with a chroot configured like RHEL6 and somehow work backwards.
This per precisely the problem for me as well. I would love to be able to write a few tools in rust, and introduce some coworkers to the language.
I think your idea of using musl is a good one. I haven't used it before but the FAQ says it works on 2.6 kernels and RHEL5 is 2.6.18. I will see if I can build it. The other thing, though is that it's not just glibc but every one of the dependencies which depend on glibc -- which is likely all of them -- will have to be built with musl. How big that job is depends on how many dependencies Rust has. I haven't had the pleasure of building from source yet but I imagine it's quite a few. Still, some effort is warranted to avoid freezing out a large fraction of professional programmers. Update: musl builds with no problems in RHEL5. Too bad it doesn't seem to come with a test suite. Now to imagine how to build all those dependencies. The big problem still is that Rust can't bootstrap in RHEL5 environment so I'll still have to make in RHEL6.
This is worse than I thought Rust snapshot doesn't work on CentOS 6.5 which is equivalent to the final release of RHEL6. How am I the first one to notice? The only newer platform is RHEL7 which was released in June of this year. This platform requirement makes no sense. LLVM works fine on Redhat 5. Julia -- also based on LLVM -- compiles on RHEL5 without a hitch. Why does LLVM want GLIBCXX bla bla anyway? Doesn't clang++ ship it's own stdc++ library? Update: I went through the build process. Tried a few times with different Linuxs (Linuxi?) and was only successful using an up-to-date Arch. I think it may never be practical to reduce the build requirements to enable building on less bleeding-edge distros. What can and should be done is to cross-compile targeting older or alternative libc and ship binaries with own libstdc++ or libc++. The build process makes LLVM but not clang or clang++. I think the way forward would be to build clang (or just use Arch's if it doesn't need patching) and then use it's cross compiling capabilities along with the kernel sources, binutils and glibc from Centos5 srpms (or uclibc or musl might be good alternatives to old glibc; maybe even glibc can be configured to not use interfaces past 2.12; I'm not an expert). Anyway, it's an all-day project and I'll have to see if I'm still interested this weekend. Question: If the build-system requirements are bleeding-edge, is there any particular reason to build LLVM from scratch rather than using the very up-to-date one that always exists on Arch? Answer: Yes, duh. You have to cross-compile LLVM and all of it's dependencies too in order to ship a glibc-free This may also be a good time to integrate some patchelf technology. If most linux installations will be binary-only then it's good to let the user select where to install it. Some non-root users will want to try it in their home directory and some sysadmins would prefer to install to /opt/rust rather than piling everything up in /usr/local.
Just came across the same issue. I'm very surprised to find that rust aparently doesn't even run on RHEL6. Is there a way to compile a rust program for RHEL6 or 5?
Are you sure that snapshots don't work on RHEL 6.5? Nightlies I understand since they link libstdc++ dynamically, but snapshots link it statically. If snapshots work you should be able to build from source.
We use to use Rust in production, however we have a non trivial number of customers on RHEL 5 (and CentOS). The fact is that 5.10 came out less than a year ago and is not scheduled for EOL until sometime in 2017. If Rust decides to not support such platforms, it will mean that we will not be able to use it and I suspect that a large number of potential users will be in the same boat. I would like to add that we have figured out work arounds to run builds on CentOS 5.10 for now, but we really need rustc to properly support the platform.
Maybe musl is going to be the way forward…
So, I'm a bit confused about why musl is needed. When I looked, in the rust nightly there was only 1 symbol that depended on glibc 2.6, and that was conditionally detected when llvm when compiled on a box that had glibc 2.6. If rust was compiled on CentOS 5.10, it should "just work". I actually got it working (using really bad hacks), so it should be doable without embedding libc.
libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5)
honestly, I'm pretty sure that getting musl working properly will be a win, regardless of whether it is possible to build rustc on old boxes. The ability to (optionally) build a totally self-contained native binary from Rust, especially if the total file size remains plausible, would be very nice.
cc re musl.
The latest snapshot (being in ) should fix this issue.
I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much!

// FIXME: #13996: mark the `allocate` and `reallocate` return value as `noalias` <del> #[cfg(stage0, not(test))] use core::raw; #[cfg(stage0, not(test))] use util; </del> /// Returns a pointer to `size` bytes of memory. /// /// Behavior is undefined if the requested size is 0 or the alignment is not a


Question:
Our snapshot builder is running CentOS 6.
I think we would have to build on CentOS5 to reliably support RHEL5. Perhaps we should just call it unsupported as we do for old OS X versions? The only alternative I can think of is actually getting a C library like working for Rust and statically linking it in the snapshot builds. Sadly, itself doesn't really support static linking (and is huge).
I agree with I think we could move forward to just supporting RHEL=6.4 Do you agree? Can this bug be closed?
By the way, my earlier mention of musl isn't actually relevant. It only runs on kernels newer than the one offered by RHEL5 anyway.
The thing is that RHEL systems that many people use at work are upgraded rarely because stability is important in complex-shared setups and utmost in production. If I can't get Rust for RHEL5 then it will literally be 5 years before I can use Rust at work. It's not like your macbook where you might as well take the latest OSX after a month or two. We're currently still moving systems to RHEL5 and shutting down HPUX11 and RHEL3 sometime next year. RHEL6 is for new projects only and not used for anything in operations. The thing is that it's kind of a nightmare imagining how you could even get Rust going again on RHEL5 since you need an already-working Rust to bootstrap compiling. You'd have to go back to the last snapshot that worked and start trying to build incrementally-newer versions until you got up-to-date. Maybe you could start with a chroot configured like RHEL6 and somehow work backwards.
This per precisely the problem for me as well. I would love to be able to write a few tools in rust, and introduce some coworkers to the language.
I think your idea of using musl is a good one. I haven't used it before but the FAQ says it works on 2.6 kernels and RHEL5 is 2.6.18. I will see if I can build it. The other thing, though is that it's not just glibc but every one of the dependencies which depend on glibc -- which is likely all of them -- will have to be built with musl. How big that job is depends on how many dependencies Rust has. I haven't had the pleasure of building from source yet but I imagine it's quite a few. Still, some effort is warranted to avoid freezing out a large fraction of professional programmers. Update: musl builds with no problems in RHEL5. Too bad it doesn't seem to come with a test suite. Now to imagine how to build all those dependencies. The big problem still is that Rust can't bootstrap in RHEL5 environment so I'll still have to make in RHEL6.
This is worse than I thought Rust snapshot doesn't work on CentOS 6.5 which is equivalent to the final release of RHEL6. How am I the first one to notice? The only newer platform is RHEL7 which was released in June of this year. This platform requirement makes no sense. LLVM works fine on Redhat 5. Julia -- also based on LLVM -- compiles on RHEL5 without a hitch. Why does LLVM want GLIBCXX bla bla anyway? Doesn't clang++ ship it's own stdc++ library? Update: I went through the build process. Tried a few times with different Linuxs (Linuxi?) and was only successful using an up-to-date Arch. I think it may never be practical to reduce the build requirements to enable building on less bleeding-edge distros. What can and should be done is to cross-compile targeting older or alternative libc and ship binaries with own libstdc++ or libc++. The build process makes LLVM but not clang or clang++. I think the way forward would be to build clang (or just use Arch's if it doesn't need patching) and then use it's cross compiling capabilities along with the kernel sources, binutils and glibc from Centos5 srpms (or uclibc or musl might be good alternatives to old glibc; maybe even glibc can be configured to not use interfaces past 2.12; I'm not an expert). Anyway, it's an all-day project and I'll have to see if I'm still interested this weekend. Question: If the build-system requirements are bleeding-edge, is there any particular reason to build LLVM from scratch rather than using the very up-to-date one that always exists on Arch? Answer: Yes, duh. You have to cross-compile LLVM and all of it's dependencies too in order to ship a glibc-free This may also be a good time to integrate some patchelf technology. If most linux installations will be binary-only then it's good to let the user select where to install it. Some non-root users will want to try it in their home directory and some sysadmins would prefer to install to /opt/rust rather than piling everything up in /usr/local.
Just came across the same issue. I'm very surprised to find that rust aparently doesn't even run on RHEL6. Is there a way to compile a rust program for RHEL6 or 5?
Are you sure that snapshots don't work on RHEL 6.5? Nightlies I understand since they link libstdc++ dynamically, but snapshots link it statically. If snapshots work you should be able to build from source.
We use to use Rust in production, however we have a non trivial number of customers on RHEL 5 (and CentOS). The fact is that 5.10 came out less than a year ago and is not scheduled for EOL until sometime in 2017. If Rust decides to not support such platforms, it will mean that we will not be able to use it and I suspect that a large number of potential users will be in the same boat. I would like to add that we have figured out work arounds to run builds on CentOS 5.10 for now, but we really need rustc to properly support the platform.
Maybe musl is going to be the way forward…
So, I'm a bit confused about why musl is needed. When I looked, in the rust nightly there was only 1 symbol that depended on glibc 2.6, and that was conditionally detected when llvm when compiled on a box that had glibc 2.6. If rust was compiled on CentOS 5.10, it should "just work". I actually got it working (using really bad hacks), so it should be doable without embedding libc.
libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5)
honestly, I'm pretty sure that getting musl working properly will be a win, regardless of whether it is possible to build rustc on old boxes. The ability to (optionally) build a totally self-contained native binary from Rust, especially if the total file size remains plausible, would be very nice.
cc re musl.
The latest snapshot (being in ) should fix this issue.
I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much!

deallocate(ptr, size, align); } <del> #[cfg(stage0, not(test))] #[lang="closure_exchange_malloc"] #[inline] #[allow(deprecated)] unsafe fn closure_exchange_malloc(drop_glue: fn(*mut u8), size: uint, align: uint) -> *mut u8 { let total_size = util::get_box_size(size, align); let p = allocate(total_size, 8); let alloc = p as *mut raw::Box<()>; (*alloc).drop_glue = drop_glue; alloc as *mut u8 } </del> // The minimum alignment guaranteed by the architecture. This value is used to // add fast paths for low alignment values. In practice, the alignment is a // constant at the call site and the branch will be optimized out.


Question:
Our snapshot builder is running CentOS 6.
I think we would have to build on CentOS5 to reliably support RHEL5. Perhaps we should just call it unsupported as we do for old OS X versions? The only alternative I can think of is actually getting a C library like working for Rust and statically linking it in the snapshot builds. Sadly, itself doesn't really support static linking (and is huge).
I agree with I think we could move forward to just supporting RHEL=6.4 Do you agree? Can this bug be closed?
By the way, my earlier mention of musl isn't actually relevant. It only runs on kernels newer than the one offered by RHEL5 anyway.
The thing is that RHEL systems that many people use at work are upgraded rarely because stability is important in complex-shared setups and utmost in production. If I can't get Rust for RHEL5 then it will literally be 5 years before I can use Rust at work. It's not like your macbook where you might as well take the latest OSX after a month or two. We're currently still moving systems to RHEL5 and shutting down HPUX11 and RHEL3 sometime next year. RHEL6 is for new projects only and not used for anything in operations. The thing is that it's kind of a nightmare imagining how you could even get Rust going again on RHEL5 since you need an already-working Rust to bootstrap compiling. You'd have to go back to the last snapshot that worked and start trying to build incrementally-newer versions until you got up-to-date. Maybe you could start with a chroot configured like RHEL6 and somehow work backwards.
This per precisely the problem for me as well. I would love to be able to write a few tools in rust, and introduce some coworkers to the language.
I think your idea of using musl is a good one. I haven't used it before but the FAQ says it works on 2.6 kernels and RHEL5 is 2.6.18. I will see if I can build it. The other thing, though is that it's not just glibc but every one of the dependencies which depend on glibc -- which is likely all of them -- will have to be built with musl. How big that job is depends on how many dependencies Rust has. I haven't had the pleasure of building from source yet but I imagine it's quite a few. Still, some effort is warranted to avoid freezing out a large fraction of professional programmers. Update: musl builds with no problems in RHEL5. Too bad it doesn't seem to come with a test suite. Now to imagine how to build all those dependencies. The big problem still is that Rust can't bootstrap in RHEL5 environment so I'll still have to make in RHEL6.
This is worse than I thought Rust snapshot doesn't work on CentOS 6.5 which is equivalent to the final release of RHEL6. How am I the first one to notice? The only newer platform is RHEL7 which was released in June of this year. This platform requirement makes no sense. LLVM works fine on Redhat 5. Julia -- also based on LLVM -- compiles on RHEL5 without a hitch. Why does LLVM want GLIBCXX bla bla anyway? Doesn't clang++ ship it's own stdc++ library? Update: I went through the build process. Tried a few times with different Linuxs (Linuxi?) and was only successful using an up-to-date Arch. I think it may never be practical to reduce the build requirements to enable building on less bleeding-edge distros. What can and should be done is to cross-compile targeting older or alternative libc and ship binaries with own libstdc++ or libc++. The build process makes LLVM but not clang or clang++. I think the way forward would be to build clang (or just use Arch's if it doesn't need patching) and then use it's cross compiling capabilities along with the kernel sources, binutils and glibc from Centos5 srpms (or uclibc or musl might be good alternatives to old glibc; maybe even glibc can be configured to not use interfaces past 2.12; I'm not an expert). Anyway, it's an all-day project and I'll have to see if I'm still interested this weekend. Question: If the build-system requirements are bleeding-edge, is there any particular reason to build LLVM from scratch rather than using the very up-to-date one that always exists on Arch? Answer: Yes, duh. You have to cross-compile LLVM and all of it's dependencies too in order to ship a glibc-free This may also be a good time to integrate some patchelf technology. If most linux installations will be binary-only then it's good to let the user select where to install it. Some non-root users will want to try it in their home directory and some sysadmins would prefer to install to /opt/rust rather than piling everything up in /usr/local.
Just came across the same issue. I'm very surprised to find that rust aparently doesn't even run on RHEL6. Is there a way to compile a rust program for RHEL6 or 5?
Are you sure that snapshots don't work on RHEL 6.5? Nightlies I understand since they link libstdc++ dynamically, but snapshots link it statically. If snapshots work you should be able to build from source.
We use to use Rust in production, however we have a non trivial number of customers on RHEL 5 (and CentOS). The fact is that 5.10 came out less than a year ago and is not scheduled for EOL until sometime in 2017. If Rust decides to not support such platforms, it will mean that we will not be able to use it and I suspect that a large number of potential users will be in the same boat. I would like to add that we have figured out work arounds to run builds on CentOS 5.10 for now, but we really need rustc to properly support the platform.
Maybe musl is going to be the way forward…
So, I'm a bit confused about why musl is needed. When I looked, in the rust nightly there was only 1 symbol that depended on glibc 2.6, and that was conditionally detected when llvm when compiled on a box that had glibc 2.6. If rust was compiled on CentOS 5.10, it should "just work". I actually got it working (using really bad hacks), so it should be doable without embedding libc.
libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5)
honestly, I'm pretty sure that getting musl working properly will be a win, regardless of whether it is possible to build rustc on old boxes. The ability to (optionally) build a totally self-contained native binary from Rust, especially if the total file size remains plausible, would be very nice.
cc re musl.
The latest snapshot (being in ) should fix this issue.
I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much!

flags: c_int) -> *mut c_void; fn je_xallocx(ptr: *mut c_void, size: size_t, extra: size_t, flags: c_int) -> size_t; <del> #[cfg(stage0)] fn je_dallocx(ptr: *mut c_void, flags: c_int); #[cfg(not(stage0))] </del> fn je_sdallocx(ptr: *mut c_void, size: size_t, flags: c_int); fn je_nallocx(size: size_t, flags: c_int) -> size_t; fn je_malloc_stats_print(write_cb: Option<extern "C" fn(cbopaque: *mut c_void,


Question:
Our snapshot builder is running CentOS 6.
I think we would have to build on CentOS5 to reliably support RHEL5. Perhaps we should just call it unsupported as we do for old OS X versions? The only alternative I can think of is actually getting a C library like working for Rust and statically linking it in the snapshot builds. Sadly, itself doesn't really support static linking (and is huge).
I agree with I think we could move forward to just supporting RHEL=6.4 Do you agree? Can this bug be closed?
By the way, my earlier mention of musl isn't actually relevant. It only runs on kernels newer than the one offered by RHEL5 anyway.
The thing is that RHEL systems that many people use at work are upgraded rarely because stability is important in complex-shared setups and utmost in production. If I can't get Rust for RHEL5 then it will literally be 5 years before I can use Rust at work. It's not like your macbook where you might as well take the latest OSX after a month or two. We're currently still moving systems to RHEL5 and shutting down HPUX11 and RHEL3 sometime next year. RHEL6 is for new projects only and not used for anything in operations. The thing is that it's kind of a nightmare imagining how you could even get Rust going again on RHEL5 since you need an already-working Rust to bootstrap compiling. You'd have to go back to the last snapshot that worked and start trying to build incrementally-newer versions until you got up-to-date. Maybe you could start with a chroot configured like RHEL6 and somehow work backwards.
This per precisely the problem for me as well. I would love to be able to write a few tools in rust, and introduce some coworkers to the language.
I think your idea of using musl is a good one. I haven't used it before but the FAQ says it works on 2.6 kernels and RHEL5 is 2.6.18. I will see if I can build it. The other thing, though is that it's not just glibc but every one of the dependencies which depend on glibc -- which is likely all of them -- will have to be built with musl. How big that job is depends on how many dependencies Rust has. I haven't had the pleasure of building from source yet but I imagine it's quite a few. Still, some effort is warranted to avoid freezing out a large fraction of professional programmers. Update: musl builds with no problems in RHEL5. Too bad it doesn't seem to come with a test suite. Now to imagine how to build all those dependencies. The big problem still is that Rust can't bootstrap in RHEL5 environment so I'll still have to make in RHEL6.
This is worse than I thought Rust snapshot doesn't work on CentOS 6.5 which is equivalent to the final release of RHEL6. How am I the first one to notice? The only newer platform is RHEL7 which was released in June of this year. This platform requirement makes no sense. LLVM works fine on Redhat 5. Julia -- also based on LLVM -- compiles on RHEL5 without a hitch. Why does LLVM want GLIBCXX bla bla anyway? Doesn't clang++ ship it's own stdc++ library? Update: I went through the build process. Tried a few times with different Linuxs (Linuxi?) and was only successful using an up-to-date Arch. I think it may never be practical to reduce the build requirements to enable building on less bleeding-edge distros. What can and should be done is to cross-compile targeting older or alternative libc and ship binaries with own libstdc++ or libc++. The build process makes LLVM but not clang or clang++. I think the way forward would be to build clang (or just use Arch's if it doesn't need patching) and then use it's cross compiling capabilities along with the kernel sources, binutils and glibc from Centos5 srpms (or uclibc or musl might be good alternatives to old glibc; maybe even glibc can be configured to not use interfaces past 2.12; I'm not an expert). Anyway, it's an all-day project and I'll have to see if I'm still interested this weekend. Question: If the build-system requirements are bleeding-edge, is there any particular reason to build LLVM from scratch rather than using the very up-to-date one that always exists on Arch? Answer: Yes, duh. You have to cross-compile LLVM and all of it's dependencies too in order to ship a glibc-free This may also be a good time to integrate some patchelf technology. If most linux installations will be binary-only then it's good to let the user select where to install it. Some non-root users will want to try it in their home directory and some sysadmins would prefer to install to /opt/rust rather than piling everything up in /usr/local.
Just came across the same issue. I'm very surprised to find that rust aparently doesn't even run on RHEL6. Is there a way to compile a rust program for RHEL6 or 5?
Are you sure that snapshots don't work on RHEL 6.5? Nightlies I understand since they link libstdc++ dynamically, but snapshots link it statically. If snapshots work you should be able to build from source.
We use to use Rust in production, however we have a non trivial number of customers on RHEL 5 (and CentOS). The fact is that 5.10 came out less than a year ago and is not scheduled for EOL until sometime in 2017. If Rust decides to not support such platforms, it will mean that we will not be able to use it and I suspect that a large number of potential users will be in the same boat. I would like to add that we have figured out work arounds to run builds on CentOS 5.10 for now, but we really need rustc to properly support the platform.
Maybe musl is going to be the way forward…
So, I'm a bit confused about why musl is needed. When I looked, in the rust nightly there was only 1 symbol that depended on glibc 2.6, and that was conditionally detected when llvm when compiled on a box that had glibc 2.6. If rust was compiled on CentOS 5.10, it should "just work". I actually got it working (using really bad hacks), so it should be doable without embedding libc.
libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5)
honestly, I'm pretty sure that getting musl working properly will be a win, regardless of whether it is possible to build rustc on old boxes. The ability to (optionally) build a totally self-contained native binary from Rust, especially if the total file size remains plausible, would be very nice.
cc re musl.
The latest snapshot (being in ) should fix this issue.
I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much!

} #[inline] <del> #[cfg(stage0)] pub unsafe fn deallocate(ptr: *mut u8, _size: uint, align: uint) { let flags = align_to_flags(align); je_dallocx(ptr as *mut c_void, flags) } #[inline] #[cfg(not(stage0))] </del> pub unsafe fn deallocate(ptr: *mut u8, size: uint, align: uint) { let flags = align_to_flags(align); je_sdallocx(ptr as *mut c_void, size as size_t, flags)


Question:
Our snapshot builder is running CentOS 6.
I think we would have to build on CentOS5 to reliably support RHEL5. Perhaps we should just call it unsupported as we do for old OS X versions? The only alternative I can think of is actually getting a C library like working for Rust and statically linking it in the snapshot builds. Sadly, itself doesn't really support static linking (and is huge).
I agree with I think we could move forward to just supporting RHEL=6.4 Do you agree? Can this bug be closed?
By the way, my earlier mention of musl isn't actually relevant. It only runs on kernels newer than the one offered by RHEL5 anyway.
The thing is that RHEL systems that many people use at work are upgraded rarely because stability is important in complex-shared setups and utmost in production. If I can't get Rust for RHEL5 then it will literally be 5 years before I can use Rust at work. It's not like your macbook where you might as well take the latest OSX after a month or two. We're currently still moving systems to RHEL5 and shutting down HPUX11 and RHEL3 sometime next year. RHEL6 is for new projects only and not used for anything in operations. The thing is that it's kind of a nightmare imagining how you could even get Rust going again on RHEL5 since you need an already-working Rust to bootstrap compiling. You'd have to go back to the last snapshot that worked and start trying to build incrementally-newer versions until you got up-to-date. Maybe you could start with a chroot configured like RHEL6 and somehow work backwards.
This per precisely the problem for me as well. I would love to be able to write a few tools in rust, and introduce some coworkers to the language.
I think your idea of using musl is a good one. I haven't used it before but the FAQ says it works on 2.6 kernels and RHEL5 is 2.6.18. I will see if I can build it. The other thing, though is that it's not just glibc but every one of the dependencies which depend on glibc -- which is likely all of them -- will have to be built with musl. How big that job is depends on how many dependencies Rust has. I haven't had the pleasure of building from source yet but I imagine it's quite a few. Still, some effort is warranted to avoid freezing out a large fraction of professional programmers. Update: musl builds with no problems in RHEL5. Too bad it doesn't seem to come with a test suite. Now to imagine how to build all those dependencies. The big problem still is that Rust can't bootstrap in RHEL5 environment so I'll still have to make in RHEL6.
This is worse than I thought Rust snapshot doesn't work on CentOS 6.5 which is equivalent to the final release of RHEL6. How am I the first one to notice? The only newer platform is RHEL7 which was released in June of this year. This platform requirement makes no sense. LLVM works fine on Redhat 5. Julia -- also based on LLVM -- compiles on RHEL5 without a hitch. Why does LLVM want GLIBCXX bla bla anyway? Doesn't clang++ ship it's own stdc++ library? Update: I went through the build process. Tried a few times with different Linuxs (Linuxi?) and was only successful using an up-to-date Arch. I think it may never be practical to reduce the build requirements to enable building on less bleeding-edge distros. What can and should be done is to cross-compile targeting older or alternative libc and ship binaries with own libstdc++ or libc++. The build process makes LLVM but not clang or clang++. I think the way forward would be to build clang (or just use Arch's if it doesn't need patching) and then use it's cross compiling capabilities along with the kernel sources, binutils and glibc from Centos5 srpms (or uclibc or musl might be good alternatives to old glibc; maybe even glibc can be configured to not use interfaces past 2.12; I'm not an expert). Anyway, it's an all-day project and I'll have to see if I'm still interested this weekend. Question: If the build-system requirements are bleeding-edge, is there any particular reason to build LLVM from scratch rather than using the very up-to-date one that always exists on Arch? Answer: Yes, duh. You have to cross-compile LLVM and all of it's dependencies too in order to ship a glibc-free This may also be a good time to integrate some patchelf technology. If most linux installations will be binary-only then it's good to let the user select where to install it. Some non-root users will want to try it in their home directory and some sysadmins would prefer to install to /opt/rust rather than piling everything up in /usr/local.
Just came across the same issue. I'm very surprised to find that rust aparently doesn't even run on RHEL6. Is there a way to compile a rust program for RHEL6 or 5?
Are you sure that snapshots don't work on RHEL 6.5? Nightlies I understand since they link libstdc++ dynamically, but snapshots link it statically. If snapshots work you should be able to build from source.
We use to use Rust in production, however we have a non trivial number of customers on RHEL 5 (and CentOS). The fact is that 5.10 came out less than a year ago and is not scheduled for EOL until sometime in 2017. If Rust decides to not support such platforms, it will mean that we will not be able to use it and I suspect that a large number of potential users will be in the same boat. I would like to add that we have figured out work arounds to run builds on CentOS 5.10 for now, but we really need rustc to properly support the platform.
Maybe musl is going to be the way forward…
So, I'm a bit confused about why musl is needed. When I looked, in the rust nightly there was only 1 symbol that depended on glibc 2.6, and that was conditionally detected when llvm when compiled on a box that had glibc 2.6. If rust was compiled on CentOS 5.10, it should "just work". I actually got it working (using really bad hacks), so it should be doable without embedding libc.
libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5)
honestly, I'm pretty sure that getting musl working properly will be a win, regardless of whether it is possible to build rustc on old boxes. The ability to (optionally) build a totally self-contained native binary from Rust, especially if the total file size remains plausible, would be very nice.
cc re musl.
The latest snapshot (being in ) should fix this issue.
I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much!

//! These definitions are similar to their `ct` equivalents, but differ in that //! these can be statically allocated and are slightly optimized for the runtime <del> #[cfg(stage0)] #[doc(hidden)] pub enum Piece<'a> { String(&'a str), Argument(Argument<'a>), } </del> #[doc(hidden)] pub struct Argument<'a> { pub position: Position,


Question:
Our snapshot builder is running CentOS 6.
I think we would have to build on CentOS5 to reliably support RHEL5. Perhaps we should just call it unsupported as we do for old OS X versions? The only alternative I can think of is actually getting a C library like working for Rust and statically linking it in the snapshot builds. Sadly, itself doesn't really support static linking (and is huge).
I agree with I think we could move forward to just supporting RHEL=6.4 Do you agree? Can this bug be closed?
By the way, my earlier mention of musl isn't actually relevant. It only runs on kernels newer than the one offered by RHEL5 anyway.
The thing is that RHEL systems that many people use at work are upgraded rarely because stability is important in complex-shared setups and utmost in production. If I can't get Rust for RHEL5 then it will literally be 5 years before I can use Rust at work. It's not like your macbook where you might as well take the latest OSX after a month or two. We're currently still moving systems to RHEL5 and shutting down HPUX11 and RHEL3 sometime next year. RHEL6 is for new projects only and not used for anything in operations. The thing is that it's kind of a nightmare imagining how you could even get Rust going again on RHEL5 since you need an already-working Rust to bootstrap compiling. You'd have to go back to the last snapshot that worked and start trying to build incrementally-newer versions until you got up-to-date. Maybe you could start with a chroot configured like RHEL6 and somehow work backwards.
This per precisely the problem for me as well. I would love to be able to write a few tools in rust, and introduce some coworkers to the language.
I think your idea of using musl is a good one. I haven't used it before but the FAQ says it works on 2.6 kernels and RHEL5 is 2.6.18. I will see if I can build it. The other thing, though is that it's not just glibc but every one of the dependencies which depend on glibc -- which is likely all of them -- will have to be built with musl. How big that job is depends on how many dependencies Rust has. I haven't had the pleasure of building from source yet but I imagine it's quite a few. Still, some effort is warranted to avoid freezing out a large fraction of professional programmers. Update: musl builds with no problems in RHEL5. Too bad it doesn't seem to come with a test suite. Now to imagine how to build all those dependencies. The big problem still is that Rust can't bootstrap in RHEL5 environment so I'll still have to make in RHEL6.
This is worse than I thought Rust snapshot doesn't work on CentOS 6.5 which is equivalent to the final release of RHEL6. How am I the first one to notice? The only newer platform is RHEL7 which was released in June of this year. This platform requirement makes no sense. LLVM works fine on Redhat 5. Julia -- also based on LLVM -- compiles on RHEL5 without a hitch. Why does LLVM want GLIBCXX bla bla anyway? Doesn't clang++ ship it's own stdc++ library? Update: I went through the build process. Tried a few times with different Linuxs (Linuxi?) and was only successful using an up-to-date Arch. I think it may never be practical to reduce the build requirements to enable building on less bleeding-edge distros. What can and should be done is to cross-compile targeting older or alternative libc and ship binaries with own libstdc++ or libc++. The build process makes LLVM but not clang or clang++. I think the way forward would be to build clang (or just use Arch's if it doesn't need patching) and then use it's cross compiling capabilities along with the kernel sources, binutils and glibc from Centos5 srpms (or uclibc or musl might be good alternatives to old glibc; maybe even glibc can be configured to not use interfaces past 2.12; I'm not an expert). Anyway, it's an all-day project and I'll have to see if I'm still interested this weekend. Question: If the build-system requirements are bleeding-edge, is there any particular reason to build LLVM from scratch rather than using the very up-to-date one that always exists on Arch? Answer: Yes, duh. You have to cross-compile LLVM and all of it's dependencies too in order to ship a glibc-free This may also be a good time to integrate some patchelf technology. If most linux installations will be binary-only then it's good to let the user select where to install it. Some non-root users will want to try it in their home directory and some sysadmins would prefer to install to /opt/rust rather than piling everything up in /usr/local.
Just came across the same issue. I'm very surprised to find that rust aparently doesn't even run on RHEL6. Is there a way to compile a rust program for RHEL6 or 5?
Are you sure that snapshots don't work on RHEL 6.5? Nightlies I understand since they link libstdc++ dynamically, but snapshots link it statically. If snapshots work you should be able to build from source.
We use to use Rust in production, however we have a non trivial number of customers on RHEL 5 (and CentOS). The fact is that 5.10 came out less than a year ago and is not scheduled for EOL until sometime in 2017. If Rust decides to not support such platforms, it will mean that we will not be able to use it and I suspect that a large number of potential users will be in the same boat. I would like to add that we have figured out work arounds to run builds on CentOS 5.10 for now, but we really need rustc to properly support the platform.
Maybe musl is going to be the way forward…
So, I'm a bit confused about why musl is needed. When I looked, in the rust nightly there was only 1 symbol that depended on glibc 2.6, and that was conditionally detected when llvm when compiled on a box that had glibc 2.6. If rust was compiled on CentOS 5.10, it should "just work". I actually got it working (using really bad hacks), so it should be doable without embedding libc.
libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5)
honestly, I'm pretty sure that getting musl working properly will be a win, regardless of whether it is possible to build rustc on old boxes. The ability to (optionally) build a totally self-contained native binary from Rust, especially if the total file size remains plausible, would be very nice.
cc re musl.
The latest snapshot (being in ) should fix this issue.
I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much!

<ins> S 2014-09-16 828e075 winnt-x86_64 ce1e9d7f6967bfa368853e7c968e1626cc319951 winnt-i386 a8bd994666dfe683a5d7922c7998500255780724 linux-x86_64 88ff474db96c6ffc5c1dc7a43442cbe1cd88c8a2 linux-i386 7a731891f726c8a0590b142a4e8924c5e8b22e8d freebsd-x86_64 e67a56f76484f775cd4836dedb2d1069ab5d7921 macos-i386 f48023648a77e89086f4a2b39d76b09e4fff032d macos-x86_64 2ad6457b2b3036f87eae7581d64ee5341a07fb06 </ins> S 2014-09-10 6faa4f3 winnt-x86_64 939eb546469cb936441cff3b6f2478f562f77c46 winnt-i386 cfe4f8b519bb9d62588f9310a8f94bc919d5423b


Question:
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.)

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;


Question:
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.)

} } <ins> #[stable(feature = "encode_wide_fused_iterator", since = "1.62.0")] impl FusedIterator for EncodeWide<'_> {} </ins> impl Hash for CodePoint { #[inline] fn hash<H: Hasher>(&self, state: &mut H) {


Question:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 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
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

| PathSource::Struct | PathSource::TupleStruct(..) => false, }; <del> let mut error = false; </del> <ins> let mut res = LifetimeRes::Error; </ins> for rib in self.lifetime_ribs.iter().rev() { match rib.kind { // In create-parameter mode we error here because we don't want to support


Question:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 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
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

//     impl Foo for std::cell::Ref<u32> // note lack of '_ //     async fn foo(_: std::cell::Ref<u32>) { ... } LifetimeRibKind::AnonymousCreateParameter(_) => { <del> error = true; </del> break; } // `PassThrough` is the normal case.


Question:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 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
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

// `PathSegment`, for which there is no associated `'_` or `&T` with no explicit // lifetime. Instead, we simply create an implicit lifetime, which will be checked // later, at which point a suitable error will be emitted. <del> LifetimeRibKind::AnonymousPassThrough(..) | LifetimeRibKind::AnonymousReportError | LifetimeRibKind::Item => break, </del> <ins> LifetimeRibKind::AnonymousPassThrough(binder) => { res = LifetimeRes::Anonymous { binder, elided: true }; break; } LifetimeRibKind::AnonymousReportError | LifetimeRibKind::Item => { // FIXME(cjgillot) This resolution is wrong, but this does not matter // since these cases are erroneous anyway.  Lifetime resolution should // emit a "missing lifetime specifier" diagnostic. res = LifetimeRes::Anonymous { binder: DUMMY_NODE_ID, elided: true }; break; } </ins> _ => {} } } <del> let res = if error { LifetimeRes::Error } else { LifetimeRes::Anonymous { binder: segment_id, elided: true } }; </del> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id,


Question:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 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
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

// originating from macros, since the segment's span might be from a macro arg. segment.ident.span.find_ancestor_inside(path_span).unwrap_or(path_span) }; <del> if error { </del> <ins> if let LifetimeRes::Error = res { </ins> let sess = self.r.session; let mut err = rustc_errors::struct_span_err!( sess,


Question:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 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
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

<ins> // check-pass struct Foo<'a>(&'a ()); fn with_fn() -> fn(Foo) { |_| () } fn with_impl_fn() -> impl Fn(Foo) { |_| () } fn with_where_fn<T>() where T: Fn(Foo), { } fn main() {} </ins>


Question:
<!-- 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: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by

); err.span_label(self.span, "invalid cast"); if self.expr_ty.is_numeric() { <del> err.span_help( self.span, if self.expr_ty == fcx.tcx.types.i8 { "try casting from `u8` instead" } else if self.expr_ty == fcx.tcx.types.u32 { "try `char::from_u32` instead" } else { "try `char::from_u32` instead (via a `u32`)" }, ); </del> <ins> if self.expr_ty == fcx.tcx.types.u32 { match fcx.tcx.sess.source_map().span_to_snippet(self.expr.span) { Ok(snippet) => err.span_suggestion( self.span, "try `char::from_u32` instead", format!("char::from_u32({snippet})"), Applicability::MachineApplicable, ), Err(_) => err.span_help(self.span, "try `char::from_u32` instead"), }; } else if self.expr_ty == fcx.tcx.types.i8 { err.span_help(self.span, "try casting from `u8` instead"); } else { err.span_help(self.span, "try `char::from_u32` instead (via a `u32`)"); }; </ins> } err.emit(); }


Question:
<!-- 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: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by

--> $DIR/E0604.rs:2:5 | LL |     1u32 as char; <del> |     ^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/E0604.rs:2:5 | LL |     1u32 as char; </del> |     ^^^^^^^^^^^^ <ins> |     | |     invalid cast |     help: try `char::from_u32` instead: `char::from_u32(1u32)` </ins> error: aborting due to previous error


Question:
<!-- 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: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by

--> $DIR/error-festival.rs:25:5 | LL |     0u32 as char; <del> |     ^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/error-festival.rs:25:5 | LL |     0u32 as char; </del> |     ^^^^^^^^^^^^ <ins> |     | |     invalid cast |     help: try `char::from_u32` instead: `char::from_u32(0u32)` </ins> error[E0605]: non-primitive cast: `u8` as `Vec<u8>` --> $DIR/error-festival.rs:29:5


Question:
<!-- 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: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by

--> $DIR/cast-rfc0401.rs:41:13 | LL |     let _ = 0x61u32 as char; <del> |             ^^^^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/cast-rfc0401.rs:41:13 | LL |     let _ = 0x61u32 as char; </del> |             ^^^^^^^^^^^^^^^ <ins> |             | |             invalid cast |             help: try `char::from_u32` instead: `char::from_u32(0x61u32)` </ins> error[E0606]: casting `bool` as `f32` is invalid --> $DIR/cast-rfc0401.rs:43:13


Question:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 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: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

let second_input_ty = self.resolve_vars_if_possible(expected_input_tys[second_idx]); let third_input_ty = <del> self.resolve_vars_if_possible(expected_input_tys[second_idx]); </del> <ins> self.resolve_vars_if_possible(expected_input_tys[third_idx]); </ins> let span = if third_idx < provided_arg_count { let first_arg_span = provided_args[first_idx].span; let third_arg_span = provided_args[third_idx].span;


Question:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 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: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

} missing_idxs => { let first_idx = *missing_idxs.first().unwrap(); <del> let second_idx = *missing_idxs.last().unwrap(); </del> <ins> let last_idx = *missing_idxs.last().unwrap(); </ins> // NOTE: Because we might be re-arranging arguments, might have extra arguments, etc. // It's hard to *really* know where we should provide this error label, so this is a // decent heuristic <del> let span = if first_idx < provided_arg_count { </del> <ins> let span = if last_idx < provided_arg_count { </ins> let first_arg_span = provided_args[first_idx].span; <del> let second_arg_span = provided_args[second_idx].span; </del> <ins> let last_arg_span = provided_args[last_idx].span; </ins> Span::new( first_arg_span.lo(), <del> second_arg_span.hi(), </del> <ins> last_arg_span.hi(), </ins> first_arg_span.ctxt(), None, )


Question:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 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: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

<ins> fn main() { g((), ()); //~^ ERROR this function takes 6 arguments but 2 arguments were supplied } pub fn g(a1: (), a2: bool, a3: bool, a4: bool, a5: bool, a6: ()) -> () {} </ins>


Question:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 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: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

<ins> error[E0061]: this function takes 6 arguments but 2 arguments were supplied --> $DIR/issue-97197.rs:2:5 | LL |     g((), ()); |     ^-------- multiple arguments are missing | note: function defined here --> $DIR/issue-97197.rs:6:8 | LL | pub fn g(a1: (), a2: bool, a3: bool, a4: bool, a5: bool, a6: ()) -> () {} |        ^ ------  --------  --------  --------  --------  ------ help: provide the arguments | LL |     g((), {bool}, {bool}, {bool}, {bool}, ()); |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0061`. </ins>


Question:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 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: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

--> $DIR/missing_arguments.rs:39:3 | LL |   complex(   1,                     ""   ); <del> |   ^^^^^^^--------------------------------- three arguments of type `f32`, `i32`, and `i32` are missing </del> <ins> |   ^^^^^^^--------------------------------- three arguments of type `f32`, `i32`, and `f32` are missing </ins> | note: function defined here --> $DIR/missing_arguments.rs:7:4


Question:
<!-- 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: runs infinitely Instead, this happened: return directly The is set to :
According to and , rustc doesn't emit , which means the loop generated by the tail call shouldn't be removed(I guess).
This was apparently working in 1.58 and regressed in 1.59. label regression-from-stable-to-stable
Small reproducer:
From a cursory look, probably due to:
From cargo bisect: Probably related to
I'm tagging this as , as discussed in the . The following reproduction is concerning: This exits with an , which is not good. Presumably, is returning even though it returns . One of many ways in which this can likely be unsound.
Upstream fix: Upstream backport issue:
Reopening to beta-nominate. This regression is a nasty miscompilation that can silently induce unsoundness in valid code, given a certain opt-level setting, and is not platform-specific. The patch to LLVM to fix this is quite small:
As per T-compiler meeting (), lowering priority of this issue since has been there for a long time and the "illegal hardware instruction" mentioned is the we generate intentionally here. label +P-high -P-critical
Closing this as the beta backport has happened.

<del> Subproject commit 47848665966fc7393cb6f898077994f6dec2b591 </del> <ins> Subproject commit c9e2e89ed3aa5a3be77143aa0c86906b4138374a </ins>


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

"libc", "once_cell", "opener", <del> "pretty_assertions", </del> <ins> "pretty_assertions 0.7.2", </ins> "serde", "serde_json", "tar",


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

] [[package]] <ins> name = "crossbeam" version = "0.8.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "4ae5588f6b3c3cb05239e90bd110f257254aecd01e4635400391aeae07497845" dependencies = [ "cfg-if 1.0.0", "crossbeam-channel", "crossbeam-deque", "crossbeam-epoch", "crossbeam-queue", "crossbeam-utils", ] [[package]] </ins> name = "crossbeam-channel" version = "0.5.4" source = "registry+https://github.com/rust-lang/crates.io-index"


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

] [[package]] <ins> name = "crossbeam-queue" version = "0.3.5" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1f25d8400f4a7a5778f0e4e52384a48cbd9b5c495d110786187fc750075277a2" dependencies = [ "cfg-if 1.0.0", "crossbeam-utils", ] [[package]] </ins> name = "crossbeam-utils" version = "0.8.8" source = "registry+https://github.com/rust-lang/crates.io-index"


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

version = "0.1.0" dependencies = [ "colored", <del> "compiletest_rs", </del> "env_logger 0.9.0", "getrandom 0.2.0", <ins> "lazy_static", </ins> "libc", "log", "measureme 9.1.2", "rand 0.8.5", <ins> "regex", </ins> "rustc-workspace-hack", <del> "rustc_version", </del> "shell-escape", "smallvec", <ins> "ui_test", </ins> ] [[package]]


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

] [[package]] <ins> name = "pretty_assertions" version = "1.2.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c89f989ac94207d048d92db058e4f6ec7342b0971fc58d1271ca148b799b3563" dependencies = [ "ansi_term", "ctor", "diff", "output_vt100", ] [[package]] </ins> name = "pretty_env_logger" version = "0.4.0" source = "registry+https://github.com/rust-lang/crates.io-index"


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

checksum = "56dee185309b50d1f11bfedef0fe6d036842e3fb77413abef29f8f8d1c5d4c1c" [[package]] <ins> name = "ui_test" version = "0.1.0" dependencies = [ "colored", "crossbeam", "lazy_static", "pretty_assertions 1.2.1", "regex", "rustc_version", ] [[package]] </ins> name = "unic-char-property" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index"


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

return; } <del> // # Run `cargo test` with `-Zmir-opt-level=4`. cargo.env("MIRIFLAGS", "-O -Zmir-opt-level=4"); if !try_run(builder, &mut cargo) { return; } </del> // # Done! builder.save_toolstate("miri", ToolState::TestPass); } else {


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

<del> Subproject commit 22c97b33e470d0b7c085e98417bef8b362d43d4e </del> <ins> Subproject commit 065ff89e33b67b3527fcdd56cf8b432e593e32d4 </ins>