chore: bump toolchain to 1.94/nightly-2025-12-10 #819
Merged
Conversation
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
bitwalker
force-pushed
the
bitwalker/toolchain-1.94
branch
from
d68e70d to
5097a52
Compare
greenhat
approved these changes
Dec 15, 2025
Contributor
|
There is also https://github.com/0xMiden/project-template that needs to be updated as well. |
…_handler It appears that Rust for the wasm32-* targets now emits a second object file containing stub definitions for the default #[alloc_error_handler] that is defined by liballoc/libstd (the implementations are different depending on whether a crate is #![no_std] or not). The problem is that the signature of these stubs does not match the signature of the actual definitions, i.e. it is `fn() -> !` rather than `fn(core::alloc::Layout) -> !`. Because these stubs are fed to rust-lld, we get conflicting symbol errors due to the stub definition conflicting with the actual definition in liballoc. It isn't clear to me why this second object file is emitted by Rust, nor why the signature is wrong. My assumption is that it has something to do with the fact that we're producing a `cdylib` artifact, or perhaps due to our use of `cargo -Zbuild-std` (more likely), but I wasn't able to confirm either option. Regardless, the fix appears to be to ensure that we define our own `#[alloc_error_handler]` with the correct signature in the crate being compiled. This ensures that only one definition is present, ours, and makes the conflict go away. The downside of this (currently), is that it also requires activation of `#[feature(alloc_error_handler)]`, which cannot be hidden by our proc-macro machinery that hides boilerplate. My hope is that we can figure out the actual underlying issue here, or a fix is shipped in a new nightly and we can make this workaround go away.
When an empty template path was given to `cargo miden new`, it would generate using a template from a different repo (project-template) than our other templates (from the rust-templates repo). Local overrides of the template sources would only work for rust-templates, and would cause any use of project-template templates to fail with an error. This fixes up the handling of local template overrides, and allows overriding both rust-templates and project-template template sources.
bitwalker
force-pushed
the
bitwalker/toolchain-1.94
branch
from
38d99d6 to
421e72a
Compare
Contributor
|
I reverted 0xMiden/project-template#12 because it breaks the The test_all_templates_and_examples test still fails EDIT: when compiling the integration test in the Miden project template from the 0xMiden/project-template#14 using the cargo-miden from this branch. We need to fix it before merging this PR. TLDR; merge #821 to this branch, don't merge 0xMiden/project-template#14 yet. |
fix: use git tag for new Miden project template (`cargo miden new`)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Bumping the toolchain and Rust edition to pick up some nice changes in latest stable and 2024 edition, as well as to finally be able to get rid of the old
hashbrownhack we needed to have in place. I've updated our dependencies as well and removed some unused ones that I found.The main issue I encountered was that something in how Rust is compiling our programs causes an extra object file for the program to be emitted with some kind of default/stub implementation of the
#[alloc_error_handler]required for no-std crates that link against liballoc. The problem is that these stubs have incorrect signatures, and this causesrust-lldto raise an error because it cannot unify the actual implementation defined in liballoc, with the stub implementation. The solution ends up being to define our own#[alloc_error_handler]in the crate itself, but this isn't ideal, as it requires activation ofalloc_error_handlerfeature, which we cannot hide with other boilerplate emitted by our proc-macro infra.We'll have to try and dig in deeper to understand what is actually going on there, but for now I've simply modified everything with the workaround above.
Note that
-Zbuild-std-features=panic_immediate_abortwas removed, it is now an actual panic type that can be activated withpanic = "immediate-abort"or-Cpanic=immediate-abort. Use inCargo.tomlis still behind a nightly Cargo feature calledpanic-immediate-abort, but we're emitting-Cpanic=immediate-abortviaRUSTFLAGS, so we don't actually need to use it via Cargo anyway.