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

Update rustc version incrementally to nightly-2022-12-06 #811

Open
wants to merge 19 commits into
base: master
Choose a base branch
from

Conversation

kkysen
Copy link
Contributor

@kkysen kkysen commented Feb 1, 2023

This incrementally updates our rustc version to nightly-2022-12-06 from nightly-2022-08-08.

I stopped there as the next nightly causes a panic in c2rust-analyze whose fix will probably be a bit more involved.

This helps us get closer back to the latest nightly so we don't stay too far behind, which makes updating later much harder.

And as a result, the published rustc nightly docs become increasingly accurate as we near the latest nightly. Docs are only published for the latest nightly, not the old versions we're using, and rustup doc doesn't seem to contain them anywhere (it contains the rustc book docs, but not the rustdoc docs of rustc's code itself). Docs could be built directly from rust-lang/rust, but that's a major pain as the build system is not trivial.

The changes should be a lot easier to see/review by commit rather than all at once.

The commits of meaningful changes are:

Of these, really only these are significant changes/fixes:

…efault()` change enabled it (it changed to `ThinVec` now).
…from_bits`, not `ty::Const::from_bits`, since the latter requires `ConstantKind::Ty`.

When using `ConstantKind::Ty` explicitly, it tells `rustc` that the constant is coming from the type system.
This is not the case for our `u32` indices that have nothing to do with the type system (e.x. a const generic parameter).
A change in `nightly-2022-09-19` reworked the constant evaluator
and requires such `ConstantKind::Ty`s to use `ConstKind::Param` (e.x. a const generic parameter),
but `ty::Const::from_bits` uses `ConstKind::Value`, and thus there is a runtime crash.
Thus, now we switch to using `ConstantKind::from_bits` directly,
which lets the `rustc` code choose the correct `ConstantKind` (in practice, `ConstantKind::Val`),
which avoids the `ConstKind::Param` runtime check.

Although this change arose from a crash due to additions in `nightly-2022-09-19`,
I'm including it as a separate commit before that
because it appears we were using `ConstantKind::Ty` wrong the whole time,
and this recent change just added more stirngent checks and exposed our error.
…ding `pointers::REALLOC` (the pointer to `realloc` used for an extra indirection to fool us) as `_`.
…Elem::OpaqueCast` similar to `ProjectionElem::{Subslice,Downcast}`.
…` as `CastKind::Misc` is gone and this one is a ptr-to-ptr cast.
@@ -1,3 +1,3 @@
[toolchain]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also commented on Slack: could we split this file into one per package? That way we can update some of them independently. E.g. I think c2rust-analyze and c2rust-pdg could be on stable Rust.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

c2rust-analyze and c2rust-pdg use rustc internals, so they need nightly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For c2rust-transpile and it's dependencies, those can build on stable, but c2rust, if it depends on things like c2rust-analyze (it doesn't currently, but that was the future intention), I'm not sure how to have rust-toolchsin.toml work there, as we want it to build on both nightly and stable.

This is also an issue for rav1d, so figuring out how to do this would be nice.

kkysen added a commit that referenced this pull request Aug 28, 2024
…e` dependency to build on 1.80.0

Our old nightly (1.65) pins `time-macros` to an old version, which requires `time` to stay on an old version.
But since 1.80 broke `time` (due to time-rs/time#693 and rust-lang/rust#127343),
we need to update `time`.  Doing this requires `time-macros` to be upgraded, which requires at least rust 1.67.
There's an old PR, #811, for this, but it needs rebasing.
So for now, removing `git-testament` and its `time` dependency is simpler,
and we can add it back later once we update to a newer nightly.
kkysen added a commit that referenced this pull request Aug 28, 2024
…e` dependency to build on 1.80.0 (#1115)

* Fixes #1109.

Our old nightly (1.65) pins `time-macros` to an old version, which
requires `time` to stay on an old version. But since 1.80 broke `time`
(due to time-rs/time#693 and
rust-lang/rust#127343), we need to update
`time`. Doing this requires `time-macros` to be upgraded, which requires
at least rust 1.67. There's an old PR, #811, for this, but it needs
rebasing. So for now, removing `git-testament` and its `time` dependency
is simpler, and we can add it back later once we update to a newer
nightly.

With this fix, both `cargo build -p c2rust` (the pinned nightly) and
`cargo +stable build -p c2rust` (1.80.1) now work.

If this is good, and once we merge this, we'll release a new version
with the fix.
@kkysen
Copy link
Contributor Author

kkysen commented Aug 29, 2024

This still isn't a priority right now (#1115 fixed the issue, though ideally that removal is temporary), but we do eventually want to do this, and I'd like to avoid situations like #1114 where someone ends up redoing work that was already done (and just needs a rebase), so I'll reopen this and just let it sit there.

@kkysen kkysen reopened this Aug 29, 2024
dgherzka pushed a commit to dgherzka/c2rust that referenced this pull request Sep 4, 2024
…e` dependency to build on 1.80.0 (immunant#1115)

* Fixes immunant#1109.

Our old nightly (1.65) pins `time-macros` to an old version, which
requires `time` to stay on an old version. But since 1.80 broke `time`
(due to time-rs/time#693 and
rust-lang/rust#127343), we need to update
`time`. Doing this requires `time-macros` to be upgraded, which requires
at least rust 1.67. There's an old PR, immunant#811, for this, but it needs
rebasing. So for now, removing `git-testament` and its `time` dependency
is simpler, and we can add it back later once we update to a newer
nightly.

With this fix, both `cargo build -p c2rust` (the pinned nightly) and
`cargo +stable build -p c2rust` (1.80.1) now work.

If this is good, and once we merge this, we'll release a new version
with the fix.
@GPHemsley
Copy link
Contributor

The latest version not requiring any changes is now nightly-2022-08-15, after #942 and rust-lang/rust#100441.

Might be worth bumping just to that to avoid any further backsliding.

@kkysen
Copy link
Contributor Author

kkysen commented Sep 22, 2024

The latest version not requiring any changes is now nightly-2022-08-15, after #942 and rust-lang/rust#100441.

Might be worth bumping just to that to avoid any further backsliding.

Thanks! Good to know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants