WEB3-645: chore: declare rust-version 1.94 and bump docs nightly - #135
Open
Wollac wants to merge 3 commits into
Open
WEB3-645: chore: declare rust-version 1.94 and bump docs nightly#135Wollac wants to merge 3 commits into
Wollac wants to merge 3 commits into
Conversation
The workspace toolchain is already 1.94 and the op-alloy/op-revm dependency stack hard-requires rustc 1.94, but the crates still declared rust-version = "1.88". Consumers on an older toolchain got a confusing dependency error instead of cargo's clean "requires rustc 1.94" message. Declare the real MSRV. This in turn requires bumping the docs nightly: nightly-2025-10-30 identifies as rustc 1.93.0-nightly, which cargo rejects once the crates declare rust-version = "1.94". This was found during the v3.0.0 release prep (release-3.0), which hit exactly this failure in the docs-rs job.
github-actions
Bot
changed the title
The guest-side OpHeader is alloy_consensus::Header directly, to keep op-alloy-network (and its mandatory alloy-provider dependency) out of guest builds. Upstream currently defines <Optimism as Network>::Header as exactly this type. Add a host-gated compile-time check so that, should the OP-Stack ever introduce a distinct header type, the build fails here instead of silently diverging from the network type.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Small fixes found during the v3.0.0 release prep (#134 /
release-3.0), ported to main:rust-version = "1.94"inrisc0-steelandrisc0-op-steel. The workspace toolchain is already 1.94 and the op-alloy/op-revm dependency stack hard-requires rustc 1.94, but the crates still declared the stale1.88. Consumers on an older toolchain currently get a confusing dependency-level error instead of cargo's clean "package requires rustc 1.94" message.nightly-2025-10-30→nightly-2026-06-01in thedocs-rsCI job and the documentation workflow. The old pin identifies as rustc 1.93.0-nightly, which cargo rejects the moment the crates declarerust-version = "1.94"— this is exactly the failure the release-3.0 CI hit, and main would hit it at release-prep time otherwise. (Main currently passes only because the under-declared 1.88 lets the stale nightly through the MSRV check.)OpHeaderstays theOptimismnetwork header type. The guest-sideOpHeaderisalloy_consensus::Headerdirectly, to keepop-alloy-network(whosealloy-providerdependency is mandatory) out of guest builds — but nothing tied it to<Optimism as Network>::Header, which upstream currently defines as exactly this type. A host-gated assertion function now makes the build fail loudly if the OP-Stack ever introduces a distinct header type, instead of silently diverging.Also extends the existing CHANGELOG line about the 1.94 toolchain bump to mention the MSRV declaration.