- Notifications
You must be signed in to change notification settings - Fork259
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Updaterustc version incrementally tonightly-2022-12-06#811
base:master
Are you sure you want to change the base?
Conversation
…ew()` works, too, without changes.
…efault()` change enabled it (it changed to `ThinVec` now).
…rlapping => Intrinsic}`.
…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 evaluatorand 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 thatbecause 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] | |||
There was a problem hiding this comment.
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 thinkc2rust-analyze andc2rust-pdg could be on stable Rust.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
c2rust-analyze andc2rust-pdg use rustc internals, so they need nightly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Forc2rust-transpile and it's dependencies, those can build on stable, butc2rust, if it depends on things likec2rust-analyze (it doesn't currently, but that was the future intention), I'm not sure how to haverust-toolchsin.toml work there, as we want it to build on both nightly and stable.
This is also an issue forrav1d, so figuring out how to do this would be nice.
…e` dependency to build on 1.80.0Our 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 totime-rs/time#693 andrust-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, whichrequires `time` to stay on an old version. But since 1.80 broke `time`(due totime-rs/time#693 andrust-lang/rust#127343), we need to update`time`. Doing this requires `time-macros` to be upgraded, which requiresat least rust 1.67. There's an old PR,#811, for this, but it needsrebasing. So for now, removing `git-testament` and its `time` dependencyis simpler, and we can add it back later once we update to a newernightly.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 versionwith 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)*Fixesimmunant#1109.Our old nightly (1.65) pins `time-macros` to an old version, whichrequires `time` to stay on an old version. But since 1.80 broke `time`(due totime-rs/time#693 andrust-lang/rust#127343), we need to update`time`. Doing this requires `time-macros` to be upgraded, which requiresat least rust 1.67. There's an old PR,immunant#811, for this, but it needsrebasing. So for now, removing `git-testament` and its `time` dependencyis simpler, and we can add it back later once we update to a newernightly.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 versionwith 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 fromrust-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: