Remove Implicit std Prelude from no_std Crates#17086
Merged
alice-i-cecile merged 18 commits intobevyengine:mainfrom Jan 3, 2025
Merged
Remove Implicit std Prelude from no_std Crates#17086alice-i-cecile merged 18 commits intobevyengine:mainfrom
std Prelude from no_std Crates#17086alice-i-cecile merged 18 commits intobevyengine:mainfrom
Conversation
BenjaminBrienen
approved these changes
Jan 2, 2025
alice-i-cecile
approved these changes
Jan 2, 2025
Member
alice-i-cecile
left a comment
There was a problem hiding this comment.
Very reasonable diff: I like that this is more explicit and less likely to cause weird CI problems for contributors. Ping me when CI is behaving :)
Member
|
Ooh, you've unlocked the next, harder level of CI. |
Patch relied on `ToString` which was not already imported anymore. Using `ToOwned` (which is imported) is equivalent. Expectation on `unsafe_code` fails now, so I've moved it closer to the unsafe-sites and now it seems fine?
Contributor
Author
|
Ok @alice-i-cecile I'm ready for the next attempt at merging this thing! |
Contributor
Author
|
Ok one last CI action is failing in the merge queue. Back to the IDE... |
The `run-examples-on-wasm` timeout appears unrelated to my PR, but this commit includes a fix for a warning noticed when running that action. Hoping it solves everything...somehow
Contributor
Author
|
Marking as ready again. I believe I have resolved all CI issues, but the |
mrchantey
pushed a commit
to mrchantey/bevy
that referenced
this pull request
Feb 4, 2025
# Background In `no_std` compatible crates, there is often an `std` feature which will allow access to the standard library. Currently, with the `std` feature _enabled_, the [`std::prelude`](https://doc.rust-lang.org/std/prelude/index.html) is implicitly imported in all modules. With the feature _disabled_, instead the [`core::prelude`](https://doc.rust-lang.org/core/prelude/index.html) is implicitly imported. This creates a subtle and pervasive issue where `alloc` items _may_ be implicitly included (if `std` is enabled), or must be explicitly included (if `std` is not enabled). # Objective - Make the implicit imports for `no_std` crates consistent regardless of what features are/not enabled. ## Solution - Replace the `cfg_attr` "double negative" `no_std` attribute with conditional compilation to _include_ `std` as an external crate. ```rust // Before #![cfg_attr(not(feature = "std"), no_std)] // After #![no_std] #[cfg(feature = "std")] extern crate std; ``` - Fix imports that are currently broken but are only now visible with the above fix. ## Testing - CI ## Notes I had previously used the "double negative" version of `no_std` based on general consensus that it was "cleaner" within the Rust embedded community. However, this implicit prelude issue likely was considered when forming this consensus. I believe the reason why is the items most affected by this issue are provided by the `alloc` crate, which is rarely used within embedded but extensively used within Bevy.
salixsalicaceae
pushed a commit
to fslabs/bevy
that referenced
this pull request
Mar 26, 2026
# Background In `no_std` compatible crates, there is often an `std` feature which will allow access to the standard library. Currently, with the `std` feature _enabled_, the [`std::prelude`](https://doc.rust-lang.org/std/prelude/index.html) is implicitly imported in all modules. With the feature _disabled_, instead the [`core::prelude`](https://doc.rust-lang.org/core/prelude/index.html) is implicitly imported. This creates a subtle and pervasive issue where `alloc` items _may_ be implicitly included (if `std` is enabled), or must be explicitly included (if `std` is not enabled). # Objective - Make the implicit imports for `no_std` crates consistent regardless of what features are/not enabled. ## Solution - Replace the `cfg_attr` "double negative" `no_std` attribute with conditional compilation to _include_ `std` as an external crate. ```rust // Before #![cfg_attr(not(feature = "std"), no_std)] // After #![no_std] #[cfg(feature = "std")] extern crate std; ``` - Fix imports that are currently broken but are only now visible with the above fix. ## Testing - CI ## Notes I had previously used the "double negative" version of `no_std` based on general consensus that it was "cleaner" within the Rust embedded community. However, this implicit prelude issue likely was considered when forming this consensus. I believe the reason why is the items most affected by this issue are provided by the `alloc` crate, which is rarely used within embedded but extensively used within Bevy.
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
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.
Background
In
no_stdcompatible crates, there is often anstdfeature which will allow access to the standard library. Currently, with thestdfeature enabled, thestd::preludeis implicitly imported in all modules. With the feature disabled, instead thecore::preludeis implicitly imported. This creates a subtle and pervasive issue whereallocitems may be implicitly included (ifstdis enabled), or must be explicitly included (ifstdis not enabled).Objective
no_stdcrates consistent regardless of what features are/not enabled.Solution
cfg_attr"double negative"no_stdattribute with conditional compilation to includestdas an external crate.Testing
Notes
I had previously used the "double negative" version of
no_stdbased on general consensus that it was "cleaner" within the Rust embedded community. However, this implicit prelude issue likely was considered when forming this consensus. I believe the reason why is the items most affected by this issue are provided by thealloccrate, which is rarely used within embedded but extensively used within Bevy.