Skip to content

Conversation

bushrat011899
Copy link
Contributor

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 is implicitly imported in all modules. With the feature disabled, instead the core::prelude 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.
// 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.

@bushrat011899 bushrat011899 added D-Trivial Nice and easy! A great choice to get started with Bevy C-Code-Quality A section of code that is hard to understand or change A-Cross-Cutting Impacts the entire engine X-Uncontroversial This work is generally agreed upon S-Needs-Review Needs reviewer attention (from anyone!) to move forward O-Embedded Weird hardware and no_std platforms labels Jan 2, 2025
@bushrat011899 bushrat011899 added S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Jan 2, 2025
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Jan 2, 2025
@alice-i-cecile alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged labels Jan 2, 2025
@alice-i-cecile alice-i-cecile removed this pull request from the merge queue due to a manual request Jan 2, 2025
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Jan 2, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jan 2, 2025
@alice-i-cecile
Copy link
Member

Ooh, you've unlocked the next, harder level of CI.

@alice-i-cecile alice-i-cecile added S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged and removed S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it labels Jan 2, 2025
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?
@bushrat011899 bushrat011899 added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged labels Jan 2, 2025
@bushrat011899
Copy link
Contributor Author

Ok @alice-i-cecile I'm ready for the next attempt at merging this thing!

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Jan 2, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jan 3, 2025
@bushrat011899 bushrat011899 added S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged and removed S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it labels Jan 3, 2025
@bushrat011899
Copy link
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
@bushrat011899 bushrat011899 added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged labels Jan 3, 2025
@bushrat011899
Copy link
Contributor Author

Marking as ready again. I believe I have resolved all CI issues, but the run-examples-on-wasm validation task is unclear to me. I fixed a warning that task highlighted, but I don't think that was the cause of the timeout or panic.

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Jan 3, 2025
Merged via the queue into bevyengine:main with commit 0403948 Jan 3, 2025
29 checks passed
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Cross-Cutting Impacts the entire engine C-Code-Quality A section of code that is hard to understand or change D-Trivial Nice and easy! A great choice to get started with Bevy O-Embedded Weird hardware and no_std platforms S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it X-Uncontroversial This work is generally agreed upon

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants