Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hint users to update nightly on ICEs of outdated nightly #118832

Closed
matthiaskrgr opened this issue Dec 11, 2023 · 0 comments · Fixed by #121658
Closed

hint users to update nightly on ICEs of outdated nightly #118832

matthiaskrgr opened this issue Dec 11, 2023 · 0 comments · Fixed by #121658
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@matthiaskrgr
Copy link
Member

From time to time we get reports of regressions that have already been fixed since several days, but the user uses a nightly that is 1-2 weeks old for example.

We could probably make nightly somewhat self-aware and make it:
grab the current date and compare it to its own version string
calculate when $current_version was released (iirc the time when the master-> nightly promotion happens can be found on the forge somewhere) and add maybe 6 to 12 hours as buffer.
If $current_version.release_timestamp is older than $current_time + 24 hours + buffer and nightly crashes, add a hint to perhaps update to the user but only iff we are on the master/nightly channel!

could look like this:

note: it seems this 'rustc 1.76.0-nightly (d86d65bbc 2023-12-10)' is outdated, nightly 2023-12-11 should have been released in the meantime. 
note: please consider running `rustup update nightly` to update the nightly channel and checking if this problem still persists.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: please attach the file at `/tmp/im/rustc-ice-2023-12-11T16_34_58-2325463.txt` to your bug report

We could also consider hiding/adapting the we would appreciate a bug report line in case we detected a potentially outdated nightly.

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Dec 11, 2023
@Noratrieb Noratrieb added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Dec 11, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 5, 2024
…li-obk

Hint user to update nightly on ICEs produced from outdated nightly

This is a conservative best-effort approach to detect a potentially outdated nightly; it will fallback to the regular ICE-reporting if any of the following cases are true:
- Channel is not nightly
- Version information is not available
- Version date is not parseable as a YYYY-MM-DD or is missing
- System time is at least 36 hours ahead of the user's nightly release datetime.
- Any internal features are used.

Note that I'm not sure how to make a test for this: I tested this manually by `CFG_VER_DATE="2020-02-02" ./x build library --stage 1`, and also changing the channel detection in `rustc_driver_impl` from `Some("nightly")` to `Some("nightly" | "dev")`, and then running `rustc +stage1 test.rs -Ztreat-err-as-bug=1` with a non-existent `test.rs`.

<img width="1145" alt="Screenshot 2024-02-27 at 01 12 28" src="https://github.com/rust-lang/rust/assets/39484203/eff6af2e-4b19-4a70-af57-cd739ecf0e84">

Closes rust-lang#118832.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 5, 2024
…li-obk

Hint user to update nightly on ICEs produced from outdated nightly

This is a conservative best-effort approach to detect a potentially outdated nightly; it will fallback to the regular ICE-reporting if any of the following cases are true:
- Channel is not nightly
- Version information is not available
- Version date is not parseable as a YYYY-MM-DD or is missing
- System time is at least 36 hours ahead of the user's nightly release datetime.
- Any internal features are used.

Note that I'm not sure how to make a test for this: I tested this manually by `CFG_VER_DATE="2020-02-02" ./x build library --stage 1`, and also changing the channel detection in `rustc_driver_impl` from `Some("nightly")` to `Some("nightly" | "dev")`, and then running `rustc +stage1 test.rs -Ztreat-err-as-bug=1` with a non-existent `test.rs`.

<img width="1145" alt="Screenshot 2024-02-27 at 01 12 28" src="https://github.com/rust-lang/rust/assets/39484203/eff6af2e-4b19-4a70-af57-cd739ecf0e84">

Closes rust-lang#118832.
@bors bors closed this as completed in 1b30268 Mar 6, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 6, 2024
Rollup merge of rust-lang#121658 - jieyouxu:ice-outdated-nightly, r=oli-obk

Hint user to update nightly on ICEs produced from outdated nightly

This is a conservative best-effort approach to detect a potentially outdated nightly; it will fallback to the regular ICE-reporting if any of the following cases are true:
- Channel is not nightly
- Version information is not available
- Version date is not parseable as a YYYY-MM-DD or is missing
- System time is at least 36 hours ahead of the user's nightly release datetime.
- Any internal features are used.

Note that I'm not sure how to make a test for this: I tested this manually by `CFG_VER_DATE="2020-02-02" ./x build library --stage 1`, and also changing the channel detection in `rustc_driver_impl` from `Some("nightly")` to `Some("nightly" | "dev")`, and then running `rustc +stage1 test.rs -Ztreat-err-as-bug=1` with a non-existent `test.rs`.

<img width="1145" alt="Screenshot 2024-02-27 at 01 12 28" src="https://github.com/rust-lang/rust/assets/39484203/eff6af2e-4b19-4a70-af57-cd739ecf0e84">

Closes rust-lang#118832.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants