Question:
When I used the character in comment, combined with some (invalid) code preceding it, the compiler panicked. I tried this code: I expected to see this happen: rustc compiles this code. Instead, this happened: rustc panicked with the following output : Backtrace:
Regressed in 1.34.0. Used to be:
cc
Miminized: Probably some span handcrafting?
Probably some span handcrafting? +1
I was idly curious, so I took a brief look at this. The diagnostic that triggers this was introduced in , but I don't think it is responsible for the error (it's just stepping through characters looking for a closing brace). There is some strange math in  (introduced in ). It oscillates between zero-length and 1+ length spans as it is stepping over characters. When it hits a multi-byte character, it returns an invalid span. Example: Starting with a span of (0,1), using would result in (1,1), then (1,2), then (2,2), then (2,4). That last one slices into the middle of the multi-byte character (because of , where width is 3), causing a panic. I'm not familiar enough with this stuff to say how it should behave. It seems like is being used for two different purposes (getting the next zero-length span, and getting the "next" character), and it's not clear to me what the behavior should be since it is used in a variety of places. I don't think it can be changed to always return zero-length spans, and it can't be changed to always return non-zero length spans. Perhaps there should be two different functions?
triage: P-medium, removing nomination; the ICE to me appears to include enough information for a user to identify the offending character and work-around the problem (namely by getting rid of the character). I do agree with that there should probably be two distinct functions corresponding to the two distinct purposes that they identified for the current callers of .
More test cases have been brought up in
I guess this is the same bug, but the examples I've seen here concern non-ASCII characters in comments. I'm getting a similar rustc panic from an erroneous code without comments: Compilation attempt:
Please file a new issue and reference this one.
I think it's fixed, try .
confirmed fixed by .

<ins> error[E0423]: expected value, found struct `X` --> $DIR/issue-61226.rs:3:10 | LL |     vec![X]; //… |          ^ did you mean `X { /* fields */ }`? error: aborting due to previous error For more information about this error, try `rustc --explain E0423`. </ins>


Question:
Creating a recursive type with infinite size by removing a leads to an internal compiler error. Might be the same issue as . To reproduce this bug, run on this code: Replace by and run again: I expected to see this happen: Instead, this happened: :
triage: P-high. Removing nomination.
assigning to with expectation that they will delegate.
nominating to try to find someone to investigate this.
well spotted ;) Because this issue has the tag and the other doesn't I will post the incremental test here:
triage: Reassigning to self and in hopes that one of us will find time to investigate, since it seems to be an issue with the dep-graph/incr-comp infrastructure.
triage: Downgrading to P-medium. I still want to resolve this, but it simply does not warrant revisiting every week during T-compiler triage.
I encountered the same bug. I starting to create a new issue, but it's exactly the same than this one. In case it's needed, I uploaded the code on on the branch (there is two commits, the first is fine, the second generate the ICE) in case you want to validate your patch when you will eventually have time to fix it.
I am running into this issue as well. Since the corresponding pr has been merged 24 days ago and the latest version was tagged 14 days ago, I am not sure, if this error should have been fixed with . (I did not find the commit on the master but I am also unsure if it was squashed with other commits.) Therefore, I thought I would at least post my error as well, just in case this is supposed to work. In my case I have an enum which holds a struct which in turn references that enum. I know that this can't work and I know how the correct way of handling this scenario is, I just wanted to let you know that this crashes the compiler. If you need a more detailed code sample, let me know and I will try to reproduce the error outside of my project.

return None } None => { <del> if !tcx.sess.has_errors() { </del> <ins> if !tcx.sess.has_errors_or_delayed_span_bugs() { </ins> bug!("try_mark_previous_green() - Forcing the DepNode  should have set its color") } else { <del> // If the query we just forced has resulted // in some kind of compilation error, we // don't expect that the corresponding // dep-node color has been updated. </del> <ins> // If the query we just forced has resulted in // some kind of compilation error, we cannot rely on // the dep-node color having been properly updated. // This means that the query system has reached an // invalid state. We let the compiler continue (by // returning `None`) so it can emit error messages // and wind down, but rely on the fact that this // invalid state will not be persisted to the // incremental compilation cache because of // compilation errors being present. debug!("try_mark_previous_green({:?}) - END -  dependency {:?} resulted in compilation error", dep_node, dep_dep_node); return None </ins> } } }


Question:
Creating a recursive type with infinite size by removing a leads to an internal compiler error. Might be the same issue as . To reproduce this bug, run on this code: Replace by and run again: I expected to see this happen: Instead, this happened: :
triage: P-high. Removing nomination.
assigning to with expectation that they will delegate.
nominating to try to find someone to investigate this.
well spotted ;) Because this issue has the tag and the other doesn't I will post the incremental test here:
triage: Reassigning to self and in hopes that one of us will find time to investigate, since it seems to be an issue with the dep-graph/incr-comp infrastructure.
triage: Downgrading to P-medium. I still want to resolve this, but it simply does not warrant revisiting every week during T-compiler triage.
I encountered the same bug. I starting to create a new issue, but it's exactly the same than this one. In case it's needed, I uploaded the code on on the branch (there is two commits, the first is fine, the second generate the ICE) in case you want to validate your patch when you will eventually have time to fix it.
I am running into this issue as well. Since the corresponding pr has been merged 24 days ago and the latest version was tagged 14 days ago, I am not sure, if this error should have been fixed with . (I did not find the commit on the master but I am also unsure if it was squashed with other commits.) Therefore, I thought I would at least post my error as well, just in case this is supposed to work. In my case I have an enum which holds a struct which in turn references that enum. I know that this can't work and I know how the correct way of handling this scenario is, I just wanted to let you know that this crashes the compiler. If you need a more detailed code sample, let me know and I will try to reproduce the error outside of my project.

<ins> // revisions: rpass cfail enum A { //[cfail]~^ ERROR 3:1: 3:7: recursive type `A` has infinite size [E0072] B(C), } #[cfg(rpass)] struct C(Box<A>); #[cfg(cfail)] struct C(A); //[cfail]~^ ERROR 12:1: 12:13: recursive type `C` has infinite size [E0072] fn main() {} </ins>


Question:
The code: It produced error: Although RFC not yet implemented, this code must work already. Or I'm wrong and this syntax does not supported by const-generics?
Not sure where you see the ICE, removing that.
This is glitch after the previous 2 issues.. It is not ICE.
To Minimal code: produce error: The variant also give this error.
Now it is ICE:
It's back to the original error.
Now it produce this errors:
The behaviour is now as expected. We just need a test now.
Const Generic RFC leads the code as possible: Is there another issue that is tracking it?
Yes, there are some subtle issues about making sure that constants in types are well-formed. The tracking issue for this is

<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub struct MyArray<const COUNT: usize>([u8; COUNT + 1]); //~^ ERROR constant expression depends on a generic parameter impl<const COUNT: usize> MyArray<COUNT> { fn inner(&self) -> &[u8; COUNT + 1] { //~^ ERROR constant expression depends on a generic parameter &self.0 } } fn main() {} </ins>


Question:
The code: It produced error: Although RFC not yet implemented, this code must work already. Or I'm wrong and this syntax does not supported by const-generics?
Not sure where you see the ICE, removing that.
This is glitch after the previous 2 issues.. It is not ICE.
To Minimal code: produce error: The variant also give this error.
Now it is ICE:
It's back to the original error.
Now it produce this errors:
The behaviour is now as expected. We just need a test now.
Const Generic RFC leads the code as possible: Is there another issue that is tracking it?
Yes, there are some subtle issues about making sure that constants in types are well-formed. The tracking issue for this is

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61522-array-len-succ.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error: constant expression depends on a generic parameter --> $DIR/issue-61522-array-len-succ.rs:4:40 | LL | pub struct MyArray<const COUNT: usize>([u8; COUNT + 1]); |                                        ^^^^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: constant expression depends on a generic parameter --> $DIR/issue-61522-array-len-succ.rs:8:24 | LL |     fn inner(&self) -> &[u8; COUNT + 1] { |                        ^^^^^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to 2 previous errors </ins>


Question:
The code: It produced error: Although RFC not yet implemented, this code must work already. Or I'm wrong and this syntax does not supported by const-generics?
Not sure where you see the ICE, removing that.
This is glitch after the previous 2 issues.. It is not ICE.
To Minimal code: produce error: The variant also give this error.
Now it is ICE:
It's back to the original error.
Now it produce this errors:
The behaviour is now as expected. We just need a test now.
Const Generic RFC leads the code as possible: Is there another issue that is tracking it?
Yes, there are some subtle issues about making sure that constants in types are well-formed. The tracking issue for this is

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash trait Trait<const NAME: &'static str> { type Assoc; } impl Trait<"0"> for () { type Assoc = (); } fn main() { let _: <() as Trait<"0">>::Assoc = (); } </ins>


Question:
The code: It produced error: Although RFC not yet implemented, this code must work already. Or I'm wrong and this syntax does not supported by const-generics?
Not sure where you see the ICE, removing that.
This is glitch after the previous 2 issues.. It is not ICE.
To Minimal code: produce error: The variant also give this error.
Now it is ICE:
It's back to the original error.
Now it produce this errors:
The behaviour is now as expected. We just need a test now.
Const Generic RFC leads the code as possible: Is there another issue that is tracking it?
Yes, there are some subtle issues about making sure that constants in types are well-formed. The tracking issue for this is

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-66596-impl-trait-for-str-const-arg.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>


Question:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.

And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust. <del> The enforcement policies listed above apply to all official Rust venues; including official IRC channels (#rust, #rust-internals, #rust-tools, #rust-libs, #rustc, #rust-beginners, #rust-docs, #rust-community, #rust-lang, and #cargo); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. </del> <ins> The enforcement policies listed above apply to all official Rust venues; including all communication channels (Rust Discord server, Rust Zulip server); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. </ins> *Adapted from the [Node.js Policy on Trolling](https://blog.izs.me/2012/08/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).*


Question:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.

* [Helpful Links and Information](#helpful-links-and-information) If you have questions, please make a post on [internals.rust-lang.org][internals] or <del> hop on the [Rust Discord server][rust-discord], [Rust Zulip server][rust-zulip] or [#rust-internals][pound-rust-internals]. </del> <ins> hop on the [Rust Discord server][rust-discord] or [Rust Zulip server][rust-zulip]. </ins> As a reminder, all contributors are expected to follow our [Code of Conduct][coc].


Question:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.

If this is your first time contributing, the [walkthrough] chapter of the guide can give you a good example of how a typical contribution would go. <del> [pound-rust-internals]: https://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust-internals </del> [internals]: https://internals.rust-lang.org [rust-discord]: http://discord.gg/rust-lang [rust-zulip]: https://rust-lang.zulipchat.com


Question:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.

There are a number of other ways to contribute to Rust that don't deal with this repository. <del> Answer questions in [#rust][pound-rust], or on [users.rust-lang.org][users], </del> <ins> Answer questions in the _Get Help!_ channels from the [Rust Discord server][rust-discord], on [users.rust-lang.org][users], </ins> or on [StackOverflow][so]. Participate in the [RFC process](https://github.com/rust-lang/rfcs).


Question:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.

it to [Crates.io](http://crates.io). Easier said than done, but very, very valuable! <del> [pound-rust]: http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust </del> <ins> [rust-discord]: https://discord.gg/rust-lang </ins> [users]: https://users.rust-lang.org/ [so]: http://stackoverflow.com/questions/tagged/rust [community-library]: https://github.com/rust-lang/rfcs/labels/A-community-library


Question:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.

To contribute to Rust, please see [CONTRIBUTING](CONTRIBUTING.md). <del> Rust has an [IRC] culture and most real-time collaboration happens in a variety of channels on Mozilla's IRC network, irc.mozilla.org. The most popular channel is [#rust], a venue for general discussion about Rust. And a good place to ask for help would be [#rust-beginners]. </del> <ins> Most real-time collaboration happens in a variety of channels on the [Rust Discord server][rust-discord], with channels dedicated for getting help, community, documentation, and all major contribution areas in the Rust ecosystem. A good place to ask for help would be the #help channel. </ins> The [rustc guide] might be a good place to start if you want to find out how various parts of the compiler work. Also, you may find the [rustdocs for the compiler itself][rustdocs] useful. <del> [IRC]: https://en.wikipedia.org/wiki/Internet_Relay_Chat [#rust]: irc://irc.mozilla.org/rust [#rust-beginners]: irc://irc.mozilla.org/rust-beginners </del> <ins> [rust-discord]: https://discord.gg/rust-lang </ins> [rustc guide]: https://rust-lang.github.io/rustc-guide/about-this-guide.html [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/


Question:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.

`Config` struct. * Adding a sanity check? Take a look at `bootstrap/sanity.rs`. <del> If you have any questions feel free to reach out on `#rust-infra` on IRC or ask on internals.rust-lang.org. When you encounter bugs, please file issues on the rust-lang/rust issue tracker. </del> <ins> If you have any questions feel free to reach out on `#infra` channel in the [Rust Discord server][rust-discord] or ask on internals.rust-lang.org. When you encounter bugs, please file issues on the rust-lang/rust issue tracker. [rust-discord]: https://discord.gg/rust-lang </ins>


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.

[[package]] name = "directories" <del> version = "1.0.2" </del> <ins> version = "2.0.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ <del> "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "cfg-if 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", "dirs-sys 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.

] [[package]] <ins> name = "dirs-sys" version = "0.3.3" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "cfg-if 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.54 (registry+https://github.com/rust-lang/crates.io-index)", "redox_users 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] </ins> name = "dlmalloc" version = "0.1.3" 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 no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.

version = "0.1.0" dependencies = [ "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", <del> "cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "cargo_metadata 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "colored 1.6.0 (registry+https://github.com/rust-lang/crates.io-index)", "compiletest_rs 0.3.22 (registry+https://github.com/rust-lang/crates.io-index)", <del> "directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "directories 2.0.1 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", "hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (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 no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.

"checksum diff 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)" = "3c2b69f912779fbb121ceb775d74d51e915af17aaebc38d28a592843a2dd0a3a" "checksum difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "524cbf6897b527295dff137cec09ecf3a05f4fddffd7dfcd1585403449e74198" "checksum digest 0.7.6 (registry+https://github.com/rust-lang/crates.io-index)" = "03b072242a8cbaf9c145665af9d250c59af3b958f83ed6824e13533cf76d5b90" <del> "checksum directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)" = "72d337a64190607d4fcca2cb78982c5dd57f4916e19696b48a575fa746b6cb0f" </del> <ins> "checksum directories 2.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "2ccc83e029c3cebb4c8155c644d34e3a070ccdb4ff90d369c74cd73f7cb3c984" </ins> "checksum dirs 1.0.5 (registry+https://github.com/rust-lang/crates.io-index)" = "3fd78930633bd1c6e35c4b42b1df7b0cbc6bc191146e512bb3bedf243fcc3901" <ins> "checksum dirs-sys 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "937756392ec77d1f2dd9dc3ac9d69867d109a2121479d72c364e42f4cab21e2d" </ins> "checksum dlmalloc 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "f283302e035e61c23f2b86b3093e8c6273a4c3125742d6087e96ade001ca5e63" "checksum either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3be565ca5c557d7f59e7cfcf1844f9e3033650c929c6566f511e8005f205c1d0" "checksum elasticlunr-rs 2.3.4 (registry+https://github.com/rust-lang/crates.io-index)" = "a99a310cd1f9770e7bf8e48810c7bcbb0e078c8fb23a8c7bcf0da4c2bf61a455"


Question:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.

<del> Subproject commit e1a0f66373a1a185334a6e3be24e94161e3b4a43 </del> <ins> Subproject commit 965160d4d7976ddead182b4a65b73f59818537de </ins>


Question:
Probably one should never write this, and I wonder if it will be disallowed in the future. Happens on stable, beta and nightly, in all const-forms existing (includes const generics) <details<summaryBacktrace:</summary</details
Note: You could also write it the following way, in order to not need the attribute, as the previous code complains about recursion without that attribute.
Regression introduced in
cc due to Edit: I think I have a fix for this.

self.ty_inhabitedness_forest(ty).contains(self, module) } <del> pub fn is_ty_uninhabited_from_all_modules(self, ty: Ty<'tcx>) -> bool { </del> <ins> pub fn is_ty_uninhabited_from_any_module(self, ty: Ty<'tcx>) -> bool { </ins> !self.ty_inhabitedness_forest(ty).is_empty() }


Question:
Probably one should never write this, and I wonder if it will be disallowed in the future. Happens on stable, beta and nightly, in all const-forms existing (includes const generics) <details<summaryBacktrace:</summary</details
Note: You could also write it the following way, in order to not need the attribute, as the previous code complains about recursion without that attribute.
Regression introduced in
cc due to Edit: I think I have a fix for this.

)); } } else { <del> let callee_layout = self.layout_of_local(self.frame(), mir::RETURN_PLACE, None)?; if !callee_layout.abi.is_uninhabited() { return err!(FunctionRetMismatch( self.tcx.types.never, callee_layout.ty )); </del> <ins> let local = mir::RETURN_PLACE; let ty = self.frame().body.local_decls[local].ty; if !self.tcx.is_ty_uninhabited_from_any_module(ty) { return err!(FunctionRetMismatch(self.tcx.types.never, ty)); </ins> } } Ok(())


Question:
Probably one should never write this, and I wonder if it will be disallowed in the future. Happens on stable, beta and nightly, in all const-forms existing (includes const generics) <details<summaryBacktrace:</summary</details
Note: You could also write it the following way, in order to not need the attribute, as the previous code complains about recursion without that attribute.
Regression introduced in
cc due to Edit: I think I have a fix for this.

<ins> // compile-fail pub const unsafe fn fake_type<T>() -> T { hint_unreachable() } pub const unsafe fn hint_unreachable() -> ! { fake_type() //~ ERROR any use of this value will cause an error } trait Const { const CONSTANT: i32 = unsafe { fake_type() }; } impl <T> Const for T {} pub fn main() -> () { dbg!(i32::CONSTANT); //~ ERROR erroneous constant used } </ins>


Question:
Probably one should never write this, and I wonder if it will be disallowed in the future. Happens on stable, beta and nightly, in all const-forms existing (includes const generics) <details<summaryBacktrace:</summary</details
Note: You could also write it the following way, in order to not need the attribute, as the previous code complains about recursion without that attribute.
Regression introduced in
cc due to Edit: I think I have a fix for this.

<ins> error: any use of this value will cause an error --> $DIR/uninhabited-const-issue-61744.rs:8:5 | LL |     fake_type() |     ^^^^^^^^^^^ |     | |     tried to call a function with return type T passing return place of type ! |     inside call to `hint_unreachable` at $DIR/uninhabited-const-issue-61744.rs:4:5 |     inside call to `fake_type::<i32>` at $DIR/uninhabited-const-issue-61744.rs:12:36 ... LL |     const CONSTANT: i32 = unsafe { fake_type() }; |     --------------------------------------------- | = note: #[deny(const_err)] on by default error[E0080]: erroneous constant used --> $DIR/uninhabited-const-issue-61744.rs:18:10 | LL |     dbg!(i32::CONSTANT); |          ^^^^^^^^^^^^^ referenced constant has errors error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0080`. </ins>


Question:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test

let span = self.tcx.def_span(generator_did); // Do not ICE on closure typeck (#66868). <del> if let None = self.tcx.hir().as_local_hir_id(generator_did) { </del> <ins> if self.tcx.hir().as_local_hir_id(generator_did).is_none() { </ins> return false; }


Question:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Const<const N: usize>; impl<const C: usize> Const<{C}> { fn successor() -> Const<{C + 1}> { Const } } fn main() { let _x: Const::<2> = Const::<1>::successor(); } </ins>


Question:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61747.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>


Question:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test

<ins> // check-pass #![allow(incomplete_features, dead_code, unconditional_recursion)] #![feature(const_generics)] fn fact<const N: usize>() { fact::<{ N - 1 }>(); } fn main() {} </ins>


Question:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test

<ins> // Fixed by #67160 trait Trait1 { type A; } trait Trait2 { type Type1<B>: Trait1<A=B>; //~^ ERROR: generic associated types are unstable //~| ERROR: type-generic associated types are not yet implemented } fn main() {} </ins>


Question:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test

<ins> error[E0658]: generic associated types are unstable --> $DIR/issue-67424.rs:8:5 | LL |     type Type1<B>: Trait1<A=B>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44265 = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable error: type-generic associated types are not yet implemented --> $DIR/issue-67424.rs:8:5 | LL |     type Type1<B>: Trait1<A=B>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44265 error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>


Question:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test

<ins> // Regression test for #66270, fixed by #66246 struct Bug { incorrect_field: 0, //~^ ERROR expected type } struct Empty {} fn main() { let Bug { any_field: Empty {}, } = Bug {}; } </ins>


Question:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test

<ins> error: expected type, found `0` --> $DIR/issue-66270-pat-struct-parser-recovery.rs:4:22 | LL |     incorrect_field: 0, |                      ^ expected type error: aborting due to previous error </ins>


Question:
With we are now suggesting people to use when they have a raw pointer and need a reference. With gets some expanded documentation on UB avoidance. It might be a good idea to mention that also in the actual suggestion, so people don't have to open the docs to be aware of this. Cc
Can I take this on, since no one seems to have done it yet?
Sure, it's yours!

err.note("try using `<*const T>::as_ref()` to get a reference to the  type behind the pointer: https://doc.rust-lang.org/std/ primitive.pointer.html#method.as_ref"); <ins> err.note("using `<*const T>::as_ref()` on a pointer  which is unaligned or points to invalid  or uninitialized memory is undefined behavior"); </ins> } err }


Question:
With we are now suggesting people to use when they have a raw pointer and need a reference. With gets some expanded documentation on UB avoidance. It might be a good idea to mention that also in the actual suggestion, so people don't have to open the docs to be aware of this. Cc
Can I take this on, since no one seems to have done it yet?
Sure, it's yours!

|                      ^^^^^^^^^ | = note: try using `<*const T>::as_ref()` to get a reference to the type behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref <ins> = note: using `<*const T>::as_ref()` on a pointer which is unaligned or points to invalid or uninitialized memory is undefined behavior </ins> = note: the method `to_string` exists but the following trait bounds were not satisfied: `*const u8 : std::string::ToString`


Question:
I compiled the following code expecting some sort of error message. Instead, the compiler panicked unexpectedly. () errors: errors: :
Triage: Likely dupe of cc Preliminarily assigning P-high before compiler team meeting.

(Reservation(WriteKind::MutableBorrow(bk)), BorrowKind::Shallow) | (Reservation(WriteKind::MutableBorrow(bk)), BorrowKind::Shared) if { <del> tcx.migrate_borrowck() </del> <ins> tcx.migrate_borrowck() && this.borrow_set.location_map.contains_key(&location) </ins> } => { let bi = this.borrow_set.location_map[&location]; debug!(


Question:
I compiled the following code expecting some sort of error message. Instead, the compiler panicked unexpectedly. () errors: errors: :
Triage: Likely dupe of cc Preliminarily assigning P-high before compiler team meeting.

<ins> fn f1<'a>(_: &'a mut ()) {} fn f2<P>(_: P, _: ()) {} fn f3<'a>(x: &'a ((), &'a mut ())) { f2(|| x.0, f1(x.1)) //~^ ERROR cannot borrow `*x.1` as mutable, as it is behind a `&` reference //~| ERROR cannot borrow `*x.1` as mutable because it is also borrowed as immutable } fn main() {} </ins>


Question:
I compiled the following code expecting some sort of error message. Instead, the compiler panicked unexpectedly. () errors: errors: :
Triage: Likely dupe of cc Preliminarily assigning P-high before compiler team meeting.

<ins> error[E0596]: cannot borrow `*x.1` as mutable, as it is behind a `&` reference --> $DIR/issue-61623.rs:6:19 | LL | fn f3<'a>(x: &'a ((), &'a mut ())) { |              -------------------- help: consider changing this to be a mutable reference: `&'a mut ((), &'a mut ())` LL |     f2(|| x.0, f1(x.1)) |                   ^^^ `x` is a `&` reference, so the data it refers to cannot be borrowed as mutable error[E0502]: cannot borrow `*x.1` as mutable because it is also borrowed as immutable --> $DIR/issue-61623.rs:6:19 | LL |     f2(|| x.0, f1(x.1)) |     -- -- -       ^^^ mutable borrow occurs here |     |  |  | |     |  |  first borrow occurs due to use of `x` in closure |     |  immutable borrow occurs here |     immutable borrow later used by call error: aborting due to 2 previous errors Some errors have detailed explanations: E0502, E0596. For more information about an error, try `rustc --explain E0502`. </ins>


Question:
One of the many new (or newly enabled by default) warnings in Servo in today’s Nightly: The suggestion is wrong, which means also fails and therefore does not apply fixes for (the many) other warnings where the suggestion is correct.
Triage: Preliminarily assigning P-high before Felix reviews this.
Also cc since iirc you did some macro related work here.
Possible solution: when a warning’s span is exactly a macro invocation, don’t emit a “suggested fix” that is likely wrong. (But still emit a warning.)
We have that check for most suggestions, but it might be missing for . Was this in latest nightly? I know a couple of these have been fixed in the past few weeks.
This is in rustc 1.37.0-nightly ( 2019-06-18). works around this and allows ’ing the rest of the warnings (namely old syntax for inclusive ranges) or warnings in other crates.
Oh. I just noticed the suggestion. I’d missed it in that blob of text.
Apologies for the time this has taken - I've struggled to find time to dig in to this. So far, I've managed to make a smaller example (it still depends on , and ) that reproduces the issue, you can find it in (run in the directory).
Thanks to some help from I've now got a minimal test case w/out any dependencies that outputs the same tokens that the reduced example from servo did (you can see it in ). When inspecting the span that the lint is emitted for, it isn't marked as coming from a macro expansion, and it appears that it was created that way during the macro expansion. I'd appreciate any opinions on what the correct fix is here - is it a bug in / that they output what appears to be incorrect spans? Should rustc be able to handle this case? If so, where should I be looking to mark the span or what check should I be performing to identify it as a result of macro expansion?
cc
I believe this is a compiler bug, not something that needs a fix in syn or quote. is a call_site span. It is the span of tokens in macro output that are not attributable to any particular input token. Usually that will be most of the tokens in any macro output; diagnostics need to take this into account.

} fn maybe_lint_bare_trait(&self, span: Span, id: NodeId, is_global: bool) { <del> self.sess.buffer_lint_with_diagnostic( builtin::BARE_TRAIT_OBJECTS, id, span, "trait objects without an explicit `dyn` are deprecated", builtin::BuiltinLintDiagnostics::BareTraitObject(span, is_global), ) </del> <ins> // FIXME(davidtwco): This is a hack to detect macros which produce spans of the // call site which do not have a macro backtrace. See #61963. let is_macro_callsite = self.sess.source_map() .span_to_snippet(span) .map(|snippet| snippet.starts_with("#[")) .unwrap_or(true); if !is_macro_callsite { self.sess.buffer_lint_with_diagnostic( builtin::BARE_TRAIT_OBJECTS, id, span, "trait objects without an explicit `dyn` are deprecated", builtin::BuiltinLintDiagnostics::BareTraitObject(span, is_global), ) } </ins> } fn wrap_in_try_constructor(


Question:
One of the many new (or newly enabled by default) warnings in Servo in today’s Nightly: The suggestion is wrong, which means also fails and therefore does not apply fixes for (the many) other warnings where the suggestion is correct.
Triage: Preliminarily assigning P-high before Felix reviews this.
Also cc since iirc you did some macro related work here.
Possible solution: when a warning’s span is exactly a macro invocation, don’t emit a “suggested fix” that is likely wrong. (But still emit a warning.)
We have that check for most suggestions, but it might be missing for . Was this in latest nightly? I know a couple of these have been fixed in the past few weeks.
This is in rustc 1.37.0-nightly ( 2019-06-18). works around this and allows ’ing the rest of the warnings (namely old syntax for inclusive ranges) or warnings in other crates.
Oh. I just noticed the suggestion. I’d missed it in that blob of text.
Apologies for the time this has taken - I've struggled to find time to dig in to this. So far, I've managed to make a smaller example (it still depends on , and ) that reproduces the issue, you can find it in (run in the directory).
Thanks to some help from I've now got a minimal test case w/out any dependencies that outputs the same tokens that the reduced example from servo did (you can see it in ). When inspecting the span that the lint is emitted for, it isn't marked as coming from a macro expansion, and it appears that it was created that way during the macro expansion. I'd appreciate any opinions on what the correct fix is here - is it a bug in / that they output what appears to be incorrect spans? Should rustc be able to handle this case? If so, where should I be looking to mark the span or what check should I be performing to identify it as a result of macro expansion?
cc
I believe this is a compiler bug, not something that needs a fix in syn or quote. is a call_site span. It is the span of tokens in macro output that are not attributable to any particular input token. Usually that will be most of the tokens in any macro output; diagnostics need to take this into account.

<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::{Group, TokenStream, TokenTree}; // This macro exists as part of a reproduction of #61963 but without using quote/syn/proc_macro2. #[proc_macro_derive(DomObject)] pub fn expand_token_stream(input: TokenStream) -> TokenStream { // Construct a dummy span - `#0 bytes(0..0)` - which is present in the input because // of the specially crafted generated tokens in the `attribute-crate` proc-macro. let dummy_span = input.clone().into_iter().nth(0).unwrap().span(); // Define what the macro would output if constructed properly from the source using syn/quote. let output: TokenStream = "impl Bar for ((), Qux<Qux<Baz> >) { } impl Bar for ((), Box<Bar>) { }".parse().unwrap(); let mut tokens: Vec<_> = output.into_iter().collect(); // Adjust token spans to match the original crate (which would use `quote`). Some of the // generated tokens point to the dummy span. for token in tokens.iter_mut() { if let TokenTree::Group(group) = token { let mut tokens: Vec<_> = group.stream().into_iter().collect(); for token in tokens.iter_mut().skip(2) { token.set_span(dummy_span); } let mut stream = TokenStream::new(); stream.extend(tokens); *group = Group::new(group.delimiter(), stream); } } let mut output = TokenStream::new(); output.extend(tokens); output } </ins>


Question:
One of the many new (or newly enabled by default) warnings in Servo in today’s Nightly: The suggestion is wrong, which means also fails and therefore does not apply fixes for (the many) other warnings where the suggestion is correct.
Triage: Preliminarily assigning P-high before Felix reviews this.
Also cc since iirc you did some macro related work here.
Possible solution: when a warning’s span is exactly a macro invocation, don’t emit a “suggested fix” that is likely wrong. (But still emit a warning.)
We have that check for most suggestions, but it might be missing for . Was this in latest nightly? I know a couple of these have been fixed in the past few weeks.
This is in rustc 1.37.0-nightly ( 2019-06-18). works around this and allows ’ing the rest of the warnings (namely old syntax for inclusive ranges) or warnings in other crates.
Oh. I just noticed the suggestion. I’d missed it in that blob of text.
Apologies for the time this has taken - I've struggled to find time to dig in to this. So far, I've managed to make a smaller example (it still depends on , and ) that reproduces the issue, you can find it in (run in the directory).
Thanks to some help from I've now got a minimal test case w/out any dependencies that outputs the same tokens that the reduced example from servo did (you can see it in ). When inspecting the span that the lint is emitted for, it isn't marked as coming from a macro expansion, and it appears that it was created that way during the macro expansion. I'd appreciate any opinions on what the correct fix is here - is it a bug in / that they output what appears to be incorrect spans? Should rustc be able to handle this case? If so, where should I be looking to mark the span or what check should I be performing to identify it as a result of macro expansion?
cc
I believe this is a compiler bug, not something that needs a fix in syn or quote. is a call_site span. It is the span of tokens in macro output that are not attributable to any particular input token. Usually that will be most of the tokens in any macro output; diagnostics need to take this into account.

<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::{Group, Spacing, Punct, TokenTree, TokenStream}; // This macro exists as part of a reproduction of #61963 but without using quote/syn/proc_macro2. #[proc_macro_attribute] pub fn dom_struct(_: TokenStream, input: TokenStream) -> TokenStream { // Construct the expected output tokens - the input but with a `#[derive(DomObject)]` applied. let attributes: TokenStream = "#[derive(DomObject)]".to_string().parse().unwrap(); let output: TokenStream = attributes.into_iter() .chain(input.into_iter()).collect(); let mut tokens: Vec<_> = output.into_iter().collect(); // Adjust the spacing of `>` tokens to match what `quote` would produce. for token in tokens.iter_mut() { if let TokenTree::Group(group) = token { let mut tokens: Vec<_> = group.stream().into_iter().collect(); for token in tokens.iter_mut() { if let TokenTree::Punct(p) = token { if p.as_char() == '>' { *p = Punct::new('>', Spacing::Alone); } } } let mut stream = TokenStream::new(); stream.extend(tokens); *group = Group::new(group.delimiter(), stream); } } let mut output = TokenStream::new(); output.extend(tokens); output } </ins>


Question:
One of the many new (or newly enabled by default) warnings in Servo in today’s Nightly: The suggestion is wrong, which means also fails and therefore does not apply fixes for (the many) other warnings where the suggestion is correct.
Triage: Preliminarily assigning P-high before Felix reviews this.
Also cc since iirc you did some macro related work here.
Possible solution: when a warning’s span is exactly a macro invocation, don’t emit a “suggested fix” that is likely wrong. (But still emit a warning.)
We have that check for most suggestions, but it might be missing for . Was this in latest nightly? I know a couple of these have been fixed in the past few weeks.
This is in rustc 1.37.0-nightly ( 2019-06-18). works around this and allows ’ing the rest of the warnings (namely old syntax for inclusive ranges) or warnings in other crates.
Oh. I just noticed the suggestion. I’d missed it in that blob of text.
Apologies for the time this has taken - I've struggled to find time to dig in to this. So far, I've managed to make a smaller example (it still depends on , and ) that reproduces the issue, you can find it in (run in the directory).
Thanks to some help from I've now got a minimal test case w/out any dependencies that outputs the same tokens that the reduced example from servo did (you can see it in ). When inspecting the span that the lint is emitted for, it isn't marked as coming from a macro expansion, and it appears that it was created that way during the macro expansion. I'd appreciate any opinions on what the correct fix is here - is it a bug in / that they output what appears to be incorrect spans? Should rustc be able to handle this case? If so, where should I be looking to mark the span or what check should I be performing to identify it as a result of macro expansion?
cc
I believe this is a compiler bug, not something that needs a fix in syn or quote. is a call_site span. It is the span of tokens in macro output that are not attributable to any particular input token. Usually that will be most of the tokens in any macro output; diagnostics need to take this into account.

<ins> // aux-build:issue-61963.rs // aux-build:issue-61963-1.rs #![deny(bare_trait_objects)] #[macro_use] extern crate issue_61963; #[macro_use] extern crate issue_61963_1; // This test checks that the bare trait object lint does not trigger on macro attributes that // generate code which would trigger the lint. pub struct Baz; pub trait Bar { } pub struct Qux<T>(T); #[dom_struct] pub struct Foo { qux: Qux<Qux<Baz>>, bar: Box<Bar>, //~^ ERROR trait objects without an explicit `dyn` are deprecated [bare_trait_objects] } fn main() {} </ins>


Question:
One of the many new (or newly enabled by default) warnings in Servo in today’s Nightly: The suggestion is wrong, which means also fails and therefore does not apply fixes for (the many) other warnings where the suggestion is correct.
Triage: Preliminarily assigning P-high before Felix reviews this.
Also cc since iirc you did some macro related work here.
Possible solution: when a warning’s span is exactly a macro invocation, don’t emit a “suggested fix” that is likely wrong. (But still emit a warning.)
We have that check for most suggestions, but it might be missing for . Was this in latest nightly? I know a couple of these have been fixed in the past few weeks.
This is in rustc 1.37.0-nightly ( 2019-06-18). works around this and allows ’ing the rest of the warnings (namely old syntax for inclusive ranges) or warnings in other crates.
Oh. I just noticed the suggestion. I’d missed it in that blob of text.
Apologies for the time this has taken - I've struggled to find time to dig in to this. So far, I've managed to make a smaller example (it still depends on , and ) that reproduces the issue, you can find it in (run in the directory).
Thanks to some help from I've now got a minimal test case w/out any dependencies that outputs the same tokens that the reduced example from servo did (you can see it in ). When inspecting the span that the lint is emitted for, it isn't marked as coming from a macro expansion, and it appears that it was created that way during the macro expansion. I'd appreciate any opinions on what the correct fix is here - is it a bug in / that they output what appears to be incorrect spans? Should rustc be able to handle this case? If so, where should I be looking to mark the span or what check should I be performing to identify it as a result of macro expansion?
cc
I believe this is a compiler bug, not something that needs a fix in syn or quote. is a call_site span. It is the span of tokens in macro output that are not attributable to any particular input token. Usually that will be most of the tokens in any macro output; diagnostics need to take this into account.

<ins> error: trait objects without an explicit `dyn` are deprecated --> $DIR/issue-61963.rs:20:14 | LL |     bar: Box<Bar>, |              ^^^ help: use `dyn`: `dyn Bar` | note: lint level defined here --> $DIR/issue-61963.rs:3:9 | LL | #![deny(bare_trait_objects)] |         ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>


Question:
Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error. A consequence of this error is that adding a non-public function to a module (e.g. the in B) may break code that imports from that module. This causes surprises when refactoring. Shouldn't "A non-empty glob must import something with the glob's visibility" be a lint? The original discussion is here:
The error was introduced in as a part of import modularization, and discussed in one of the related issues, but I can't find where exactly. The error was introduced by analogy with errors for single imports (and just to be conservative): The error is not technically necessary, and we should be able to report it as a lint for glob imports while keeping it an error for single imports.
Would this be a "good first issue" or is it complex to fix?
No, not complex. Find where "non-empty glob must import something" is reported. Replace with .
I want to do this issue but the problem I have is with a test (ui/imports/reexports) that checks for this error, I don't know the compiler structure so I don't know when compiling this file the lint will not be reported because of the other errors or not. Else I changed the to

if !is_prelude && max_vis.get() != ty::Visibility::Invisible && // Allow empty globs. !max_vis.get().is_at_least(directive.vis.get(), &*self) { <del> let msg = "A non-empty glob must import something with the glob's visibility"; self.r.session.span_err(directive.span, msg); </del> <ins> let msg = "glob import doesn't reexport anything because no candidate is public enough"; self.r.session.buffer_lint(UNUSED_IMPORTS, directive.id, directive.span, msg); </ins> } return None; }


Question:
Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error. A consequence of this error is that adding a non-public function to a module (e.g. the in B) may break code that imports from that module. This causes surprises when refactoring. Shouldn't "A non-empty glob must import something with the glob's visibility" be a lint? The original discussion is here:
The error was introduced in as a part of import modularization, and discussed in one of the related issues, but I can't find where exactly. The error was introduced by analogy with errors for single imports (and just to be conservative): The error is not technically necessary, and we should be able to report it as a lint for glob imports while keeping it an error for single imports.
Would this be a "good first issue" or is it complex to fix?
No, not complex. Find where "non-empty glob must import something" is reported. Replace with .
I want to do this issue but the problem I have is with a test (ui/imports/reexports) that checks for this error, I don't know the compiler structure so I don't know when compiling this file the lint will not be reported because of the other errors or not. Else I changed the to

<ins> #![warn(unused_imports)] </ins> mod a { fn foo() {} mod foo {} mod a { pub use super::foo; //~ ERROR cannot be re-exported <del> pub use super::*; //~ ERROR must import something with the glob's visibility </del> <ins> pub use super::*; //~^ WARNING glob import doesn't reexport anything because no candidate is public enough </ins> } } mod b { pub fn foo() {} <del> mod foo { pub struct S; } </del> <ins> mod foo { pub struct S; } </ins> pub mod a { pub use super::foo; // This is OK since the value `foo` is visible enough.


Question:
Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error. A consequence of this error is that adding a non-public function to a module (e.g. the in B) may break code that imports from that module. This causes surprises when refactoring. Shouldn't "A non-empty glob must import something with the glob's visibility" be a lint? The original discussion is here:
The error was introduced in as a part of import modularization, and discussed in one of the related issues, but I can't find where exactly. The error was introduced by analogy with errors for single imports (and just to be conservative): The error is not technically necessary, and we should be able to report it as a lint for glob imports while keeping it an error for single imports.
Would this be a "good first issue" or is it complex to fix?
No, not complex. Find where "non-empty glob must import something" is reported. Replace with .
I want to do this issue but the problem I have is with a test (ui/imports/reexports) that checks for this error, I don't know the compiler structure so I don't know when compiling this file the lint will not be reported because of the other errors or not. Else I changed the to

error[E0364]: `foo` is private, and cannot be re-exported <del> --> $DIR/reexports.rs:6:17 </del> <ins> --> $DIR/reexports.rs:8:17 </ins> | LL |         pub use super::foo; |                 ^^^^^^^^^^ | note: consider marking `foo` as `pub` in the imported module <del> --> $DIR/reexports.rs:6:17 </del> <ins> --> $DIR/reexports.rs:8:17 </ins> | LL |         pub use super::foo; |                 ^^^^^^^^^^ <del> error: A non-empty glob must import something with the glob's visibility --> $DIR/reexports.rs:7:17 | LL |         pub use super::*; |                 ^^^^^^^^ </del> error[E0603]: module `foo` is private <del> --> $DIR/reexports.rs:28:15 </del> <ins> --> $DIR/reexports.rs:33:15 </ins> | LL |     use b::a::foo::S; |               ^^^ error[E0603]: module `foo` is private <del> --> $DIR/reexports.rs:29:15 </del> <ins> --> $DIR/reexports.rs:34:15 </ins> | LL |     use b::b::foo::S as T; |               ^^^ <del> error: aborting due to 4 previous errors </del> <ins> warning: glob import doesn't reexport anything because no candidate is public enough --> $DIR/reexports.rs:9:17 | LL |         pub use super::*; |                 ^^^^^^^^ | note: lint level defined here --> $DIR/reexports.rs:1:9 | LL | #![warn(unused_imports)] |         ^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins> Some errors have detailed explanations: E0364, E0603. For more information about an error, try `rustc --explain E0364`.


Question:
The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.
It also may be worth to drop support of Windows XP and Vista (especially considering that panics are broken on XP since June 2016, see: ). Previously it was discussed . cc
Besides , which other things would we be able to clean up?
Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: (mentioned above, in 2.6.23) ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") to atomically set the flag on the pipe fds ( in 2.6.27) ( in 2.6.27) to permit use of ( in 2.6.28) ( in 4.5, not fixed by this proposal) As you can see, the workarounds fixed by this proposal all have a similar flavor.
I am Red Hat's maintainer for Rust on RHEL -- thanks for the cc. I try to keep an eye on new issues, but this one slipped past me. Red Hat only ships the Rust toolchain to customers for RHEL 7 and RHEL 8. If our customers would like to use Rust on older RHEL, they can do so via , and we'll support them in the same way we would for any other third-party software. Internally we do also build and use on RHEL 6, mostly because it's needed to ship Firefox updates. This is where it gets a little hairy, because each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel. I would have to apply local workarounds if upstream Rust loses the ability to run on 2.6.18 kernels. We prefer to keep fixes upstream as much as possible, both for open sharing and to avoid bitrot. Is there much of a benefit to removing the current workarounds? I agree all of that code is annoying and cumbersome, but it's already written, and as far as I know it hasn't been a maintenance burden. Do you see otherwise? If there are any known issues with such Linux compatibility code, I am definitely willing to take assignment for fixing them.
(Not a Rust maintainer, but I'm a Rust user and maintain a lot of other OSS software so I have well-developed feelings around supporting Very Old Software :-)) Do you have any sense of on what timeline Rust would be able to drop support for 2.6.18 kernels without causing you pain? In general I don't think people mind supporting configurations that have users and are painful to work around, but needing to support them for forever is a bitter pill to swallow! Particularly as they get harder and harder to test over time (already I have no idea how to test on really old kernels besides building it myself). So if there was an estimate "we'd like to be able to support this until Q2 2020", even if it's not set in stone, I think that would be very helpful!
The other benefit would be that Rust wouldn't have to use CentOS 5 for CI, which means we don't have to patch LLVM (and Emscripten LLVM) to compile on those systems. Of course that's also fairly limited in scope.
As soon as we stop shipping Firefox and Thunderbird updates on RHEL 6, I won't need Rust there anymore. AFAIK this does correspond to the end of Maintenance Support, November 30, 2020. Then I'll be on to RHEL 7 builders as my minimum, probably still with some RHEL 6 2.6.32 kernels involved. It should be fine for me if we update CI to CentOS 6. This is mostly concerned with how the release binaries are linked to GLIBC symbol versions, which is all in userspace. It's a broader community question whether any other Rust users still care about running on RHEL or CentOS 5. (Small caveat - glibc support for a symbol can still return , .)
I noticed that Red Hat also has Extended Life Cycle Support (ELS) for RHEL 6 until June 30, 2024. Will you need RHEL 5 to work during this time? I don't know how ELS works with Firefox updates. Also, is there any reason RHEL 4 support wasn't an issue prior to March 31, 2017 (while RHEL 5 was still normally supported)? This issue came up for me when dealing with opening files in , see for more info. No single RHEL 5 issue is that bad, it's mainly just the sum of a bunch of tiny issues.
I'm not on that team, but AFAIK we don't ship Firefox updates for ELS. The last build I see for RHEL 5 was . Maybe there could be an exception for a severe security issue, but I really doubt we'd rebase to newer Firefox for that, which means Rust requirements won't change. New Firefox ESR versions do require a newer Rust toolchain too, which is generally why we have to keep up. Otherwise we could just freeze some older compat rustc while upstream moves on. Rust wasn't required until Firefox 52.
that makes perfect sense to me, thanks for clarifying. So the proposed policy would be: Support RHEL until RHEL is retired (i.e. ends normal support). This would mean: Supporting RHEL 5 (v2.6.18) until November 30, 2020 Supporting RHEL 6 (v2.6.32) until June 30, 2024 Supporting RHEL 7 (v3.10) until May, 2029 This is a much longer support tail than any other Linux distros (that I know of), so it would also be the effective minimum kernel version of , , and their dependencies. How does that sound to people? EDIT: The alternative to this would be Support RHEL until it is retired, taking the table above and incrementing the RHEL versions by 1. It would also mean being able to drop RHEL 5 support now.
Sure, that's ideal for me. :smile: As mentioned, is just needed for kernel support, as far as I'm concerned. Userspace concerns like GLIBC symbol versions can stick to currently supported for my needs.
Red Hat should backport the features we need (CLOEXEC and getrandom, in particular) to whatever kernels that it wants Rust to support. I don't know any good reason why they don't do so, other than it's cheaper to convince the whole world to keep supporting older kernel versions than it is to do the backports. We should change that dynamic.
The alternative to this would be Support RHEL N until it is retired I think we should not officially support retired OS versions (well, maybe with some grace period), so I prefer this option. Supporting 14 year old kernels seems a bit too much to me. each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel Is it possible to apply kernel patches to those builders to add support for functionality like CLOEXEC? Or build Firefox separately on RHEL 6?
I think it won't be fruitful for us to debate the merits of stable enterprise kernels, but no, this is not a possibility. An alternative take is "Red Hat should be responsible for the work in Rust to maintain the support they want" -- here I am, ready and willing. I definitely can't change those kernels. The ones that are stuck on N-1 are precisely to avoid rocking the boat, and backporting features is a big change. Some of our arches do eventually update the builders to their matching N kernel, but some don't, and I don't know all the reasons. If the workarounds are removed, then I will have to reapply them in our own builds. This assumes I keep using only our own binaries -- if I ever have to re-bootstrap from upstream binaries for stage0, I would also have to use some interception (like ) to hack in the workarounds. This is all possible, but much worse than the status quo of maintaining support here.
I think this sounds reasonable. We aren't going to be able to update these kernels, it's just a question of when we would drop support for these OSes. Especially given that we wont need RHEL 5 CI support, I think that leaving things as they are is fine. I opened this issue to verify two things: 1) That we weren't intending on supporting RHEL 5 "forever", and had a clear date when to drop support. 2) That someone from Red Hat actively cared about supporting these older kernels. It looks like both these things are true. We should remove RHEL 5 workarounds after November 30, 2020. This issue can be postponed until then. EDIT: For our use case in , we were able to add compatibility for RHEL 5 .
See for a recent case where supporting such ancient kernels required extra manual work ( to the 2 lines mentioned by above). I am not sure how often that comes up, but probably the hardest part is to even notice that it happens -- and even then those codepaths will likely linger untested.
Yes, but this will still be true in general. If the CI kernel is newer than whatever kernel baseline we choose, it will be possible for newer syscalls to pass undetected. I don't know if we have any control over that -- can we choose a particular VM image? So that leaves us with a stated policy of support. The more that developers are aware of such issues, the better, but I'm the one most likely to notice when my build actually fails. If I come back with a fix, I at least need the project to be receptive. I haven't been in the habit of building nightly on our RHEL6 builders, but maybe I should! Catching this early is better for everyone involved...
That seems reasonable. How quick is the Rust related bootstrapping? Could it be run automatically (or more frequently)? This is an interesting point. If I hadn't made that change, would have kept working on RHEL 5, it just would have leaked an FD. I'm not sure how we would even test for this sort of thing. This isn't a RHEL 5 specific concern, I just don't know how Rust tests these types of resource leak issues in general.
About 2 hours. Automation is harder, since I believe our build system needs my credentials, but I'll look into what is possible here. Yeah, that's a lot more subtle than an !

COPY host-x86_64/dist-x86_64-linux/build-binutils.sh /tmp/ RUN ./build-binutils.sh <del> # libssh2 (a dependency of Cargo) requires cmake 2.8.11 or higher but CentOS # only has 2.6.4, so build our own COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Need a newer version of gcc than centos has to compile LLVM nowadays </del> <ins> # Need at least GCC 5.1 to compile LLVM nowadays </ins> COPY host-x86_64/dist-x86_64-linux/build-gcc.sh /tmp/ <del> RUN ./build-gcc.sh </del> <ins> RUN ./build-gcc.sh && apt-get remove -y gcc g++ </ins> <del> # CentOS 5.5 has Python 2.4 by default, but LLVM needs 2.7+ </del> <ins> # Debian 6 has Python 2.6 by default, but LLVM needs 2.7+ </ins> COPY host-x86_64/dist-x86_64-linux/build-python.sh /tmp/ RUN ./build-python.sh <del> # Now build LLVM+Clang 7, afterwards configuring further compilations to use the </del> <ins> # LLVM needs cmake 3.4.3 or higher, and is planning to raise to 3.13.4. COPY host-x86_64/dist-x86_64-linux/build-cmake.sh /tmp/ RUN ./build-cmake.sh # Now build LLVM+Clang, afterwards configuring further compilations to use the </ins> # clang/clang++ compilers. <del> COPY host-x86_64/dist-x86_64-linux/build-clang.sh host-x86_64/dist-x86_64-linux/llvm-project-centos.patch /tmp/ </del> <ins> COPY host-x86_64/dist-x86_64-linux/build-clang.sh /tmp/ </ins> RUN ./build-clang.sh ENV CC=clang CXX=clang++ <del> # Apparently CentOS 5.5 desn't have `git` in yum, but we're gonna need it for # cloning, so download and build it here. COPY host-x86_64/dist-x86_64-linux/build-git.sh /tmp/ RUN ./build-git.sh # for sanitizers, we need kernel headers files newer than the ones CentOS ships # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-headers.sh /tmp/ RUN ./build-headers.sh # OpenSSL requires a more recent version of perl # with so we install newer ones here COPY host-x86_64/dist-x86_64-linux/build-perl.sh /tmp/ RUN ./build-perl.sh </del> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh


Question:
The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.
It also may be worth to drop support of Windows XP and Vista (especially considering that panics are broken on XP since June 2016, see: ). Previously it was discussed . cc
Besides , which other things would we be able to clean up?
Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: (mentioned above, in 2.6.23) ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") to atomically set the flag on the pipe fds ( in 2.6.27) ( in 2.6.27) to permit use of ( in 2.6.28) ( in 4.5, not fixed by this proposal) As you can see, the workarounds fixed by this proposal all have a similar flavor.
I am Red Hat's maintainer for Rust on RHEL -- thanks for the cc. I try to keep an eye on new issues, but this one slipped past me. Red Hat only ships the Rust toolchain to customers for RHEL 7 and RHEL 8. If our customers would like to use Rust on older RHEL, they can do so via , and we'll support them in the same way we would for any other third-party software. Internally we do also build and use on RHEL 6, mostly because it's needed to ship Firefox updates. This is where it gets a little hairy, because each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel. I would have to apply local workarounds if upstream Rust loses the ability to run on 2.6.18 kernels. We prefer to keep fixes upstream as much as possible, both for open sharing and to avoid bitrot. Is there much of a benefit to removing the current workarounds? I agree all of that code is annoying and cumbersome, but it's already written, and as far as I know it hasn't been a maintenance burden. Do you see otherwise? If there are any known issues with such Linux compatibility code, I am definitely willing to take assignment for fixing them.
(Not a Rust maintainer, but I'm a Rust user and maintain a lot of other OSS software so I have well-developed feelings around supporting Very Old Software :-)) Do you have any sense of on what timeline Rust would be able to drop support for 2.6.18 kernels without causing you pain? In general I don't think people mind supporting configurations that have users and are painful to work around, but needing to support them for forever is a bitter pill to swallow! Particularly as they get harder and harder to test over time (already I have no idea how to test on really old kernels besides building it myself). So if there was an estimate "we'd like to be able to support this until Q2 2020", even if it's not set in stone, I think that would be very helpful!
The other benefit would be that Rust wouldn't have to use CentOS 5 for CI, which means we don't have to patch LLVM (and Emscripten LLVM) to compile on those systems. Of course that's also fairly limited in scope.
As soon as we stop shipping Firefox and Thunderbird updates on RHEL 6, I won't need Rust there anymore. AFAIK this does correspond to the end of Maintenance Support, November 30, 2020. Then I'll be on to RHEL 7 builders as my minimum, probably still with some RHEL 6 2.6.32 kernels involved. It should be fine for me if we update CI to CentOS 6. This is mostly concerned with how the release binaries are linked to GLIBC symbol versions, which is all in userspace. It's a broader community question whether any other Rust users still care about running on RHEL or CentOS 5. (Small caveat - glibc support for a symbol can still return , .)
I noticed that Red Hat also has Extended Life Cycle Support (ELS) for RHEL 6 until June 30, 2024. Will you need RHEL 5 to work during this time? I don't know how ELS works with Firefox updates. Also, is there any reason RHEL 4 support wasn't an issue prior to March 31, 2017 (while RHEL 5 was still normally supported)? This issue came up for me when dealing with opening files in , see for more info. No single RHEL 5 issue is that bad, it's mainly just the sum of a bunch of tiny issues.
I'm not on that team, but AFAIK we don't ship Firefox updates for ELS. The last build I see for RHEL 5 was . Maybe there could be an exception for a severe security issue, but I really doubt we'd rebase to newer Firefox for that, which means Rust requirements won't change. New Firefox ESR versions do require a newer Rust toolchain too, which is generally why we have to keep up. Otherwise we could just freeze some older compat rustc while upstream moves on. Rust wasn't required until Firefox 52.
that makes perfect sense to me, thanks for clarifying. So the proposed policy would be: Support RHEL until RHEL is retired (i.e. ends normal support). This would mean: Supporting RHEL 5 (v2.6.18) until November 30, 2020 Supporting RHEL 6 (v2.6.32) until June 30, 2024 Supporting RHEL 7 (v3.10) until May, 2029 This is a much longer support tail than any other Linux distros (that I know of), so it would also be the effective minimum kernel version of , , and their dependencies. How does that sound to people? EDIT: The alternative to this would be Support RHEL until it is retired, taking the table above and incrementing the RHEL versions by 1. It would also mean being able to drop RHEL 5 support now.
Sure, that's ideal for me. :smile: As mentioned, is just needed for kernel support, as far as I'm concerned. Userspace concerns like GLIBC symbol versions can stick to currently supported for my needs.
Red Hat should backport the features we need (CLOEXEC and getrandom, in particular) to whatever kernels that it wants Rust to support. I don't know any good reason why they don't do so, other than it's cheaper to convince the whole world to keep supporting older kernel versions than it is to do the backports. We should change that dynamic.
The alternative to this would be Support RHEL N until it is retired I think we should not officially support retired OS versions (well, maybe with some grace period), so I prefer this option. Supporting 14 year old kernels seems a bit too much to me. each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel Is it possible to apply kernel patches to those builders to add support for functionality like CLOEXEC? Or build Firefox separately on RHEL 6?
I think it won't be fruitful for us to debate the merits of stable enterprise kernels, but no, this is not a possibility. An alternative take is "Red Hat should be responsible for the work in Rust to maintain the support they want" -- here I am, ready and willing. I definitely can't change those kernels. The ones that are stuck on N-1 are precisely to avoid rocking the boat, and backporting features is a big change. Some of our arches do eventually update the builders to their matching N kernel, but some don't, and I don't know all the reasons. If the workarounds are removed, then I will have to reapply them in our own builds. This assumes I keep using only our own binaries -- if I ever have to re-bootstrap from upstream binaries for stage0, I would also have to use some interception (like ) to hack in the workarounds. This is all possible, but much worse than the status quo of maintaining support here.
I think this sounds reasonable. We aren't going to be able to update these kernels, it's just a question of when we would drop support for these OSes. Especially given that we wont need RHEL 5 CI support, I think that leaving things as they are is fine. I opened this issue to verify two things: 1) That we weren't intending on supporting RHEL 5 "forever", and had a clear date when to drop support. 2) That someone from Red Hat actively cared about supporting these older kernels. It looks like both these things are true. We should remove RHEL 5 workarounds after November 30, 2020. This issue can be postponed until then. EDIT: For our use case in , we were able to add compatibility for RHEL 5 .
See for a recent case where supporting such ancient kernels required extra manual work ( to the 2 lines mentioned by above). I am not sure how often that comes up, but probably the hardest part is to even notice that it happens -- and even then those codepaths will likely linger untested.
Yes, but this will still be true in general. If the CI kernel is newer than whatever kernel baseline we choose, it will be possible for newer syscalls to pass undetected. I don't know if we have any control over that -- can we choose a particular VM image? So that leaves us with a stated policy of support. The more that developers are aware of such issues, the better, but I'm the one most likely to notice when my build actually fails. If I come back with a fix, I at least need the project to be receptive. I haven't been in the habit of building nightly on our RHEL6 builders, but maybe I should! Catching this early is better for everyone involved...
That seems reasonable. How quick is the Rust related bootstrapping? Could it be run automatically (or more frequently)? This is an interesting point. If I hadn't made that change, would have kept working on RHEL 5, it just would have leaked an FD. I'm not sure how we would even test for this sort of thing. This isn't a RHEL 5 specific concern, I just don't know how Rust tests these types of resource leak issues in general.
About 2 hours. Automation is harder, since I believe our build system needs my credentials, but I'll look into what is possible here. Yeah, that's a lot more subtle than an !

# libcurl, instead it should compile its own. ENV LIBCURL_NO_PKG_CONFIG 1 <ins> # There was a bad interaction between "old" 32-bit binaries on current 64-bit # kernels with selinux enabled, where ASLR mmap would sometimes choose a low # address and then block it for being below `vm.mmap_min_addr` -> `EACCES`. # This is probably a kernel bug, but setting `ulimit -Hs` works around it. # See also `src/ci/run.sh` where this takes effect. ENV SET_HARD_RLIMIT_STACK 1 </ins> ENV DIST_REQUIRE_ALL_TOOLS 1