Update rustc version incrementally to nightly-2022-12-06
#811
Conversation
… changes for us.
…ew()` works, too, without changes.
…efault()` change enabled it (it changed to `ThinVec` now).
… changes for us.
…rlapping => Intrinsic}`.
…y changes for us.
…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}`.
… changes for us.
…` as `CastKind::Misc` is gone and this one is a ptr-to-ptr cast.
… changes for us.
| @@ -1,3 +1,3 @@ | |||
| [toolchain] | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
c2rust-analyze and c2rust-pdg use rustc internals, so they need nightly.
There was a problem hiding this comment.
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.
…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.
…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.
|
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. |
…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.
|
The latest version not requiring any changes is now Might be worth bumping just to that to avoid any further backsliding. |
Thanks! Good to know! |
This incrementally updates our
rustcversion tonightly-2022-12-06fromnightly-2022-08-08.I stopped there as the next nightly causes a panic in
c2rust-analyzewhose 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
rustcnightly 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, andrustup docdoesn't seem to contain them anywhere (it contains therustcbook docs, but not therustdocdocs ofrustc'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: