Modify derive_label to support no_std environments#15465
Merged
alice-i-cecile merged 2 commits intobevyengine:mainfrom Sep 27, 2024
Merged
Modify derive_label to support no_std environments#15465alice-i-cecile merged 2 commits intobevyengine:mainfrom
derive_label to support no_std environments#15465alice-i-cecile merged 2 commits intobevyengine:mainfrom
Conversation
We can't generate code that uses `::std::boxed::Box` in `no_std` environments, but we also can't rely on `::alloc::boxed::Box`, since the user might not have declared `extern crate alloc`. To resolve this, the generated code is wrapped in an anonymous constant which contains the `extern crate alloc` invocation. This does mean the macro is no longer hygienic against cases where the user provides an alternate `alloc` crate, however I believe this is an acceptable compromise.
lewiszlw
reviewed
Sep 27, 2024
| fn dyn_clone(&self) -> ::std::boxed::Box<dyn #trait_path> { | ||
| ::std::boxed::Box::new(::core::clone::Clone::clone(self)) | ||
| } | ||
| const _: () = { |
Contributor
Author
There was a problem hiding this comment.
If you check the description of the PR the goal is to allow invoking this macro in no_std crates, which is required for Bevy to become no_std.
We would normally use the fully qualified name:
::std::boxed::BoxHowever, in no_std we can't use the std namespace, so instead we need to use the original definition of Box in the alloc crate:
::alloc::boxed::BoxBut that also doesn't work, because access to the alloc namespace requires explicitly linking it in the end-user's crate:
extern crate alloc;So we need to include that extern statement. However, we can't place it in the global namespace, because it would then clash with other macro invocations.
To ensure alloc is available, but also prevent its name from clashing, we place the implementation inside an anonymous constant:
const _: () = {
// private namespace so no clashes
};
Member
There was a problem hiding this comment.
Just not understand why code put in const _: () = { ... }. Thanks for detailed explanation!
lewiszlw
approved these changes
Sep 27, 2024
alice-i-cecile
approved these changes
Sep 27, 2024
rudderbucky
pushed a commit
to rudderbucky/bevy
that referenced
this pull request
Sep 27, 2024
) # Objective - Contributes to bevyengine#15460 ## Solution - Wrap `derive_label` `quote!` in an anonymous constant which contains an `extern crate alloc` statement, allowing use of the `alloc` namespace even when a user has not brought in the crate themselves. ## Testing - CI passed locally. ## Notes We can't generate code that uses `::std::boxed::Box` in `no_std` environments, but we also can't rely on `::alloc::boxed::Box` either, since the user might not have declared `extern crate alloc`. To resolve this, the generated code is wrapped in an anonymous constant which contains the `extern crate alloc` invocation. This does mean the macro is no longer hygienic against cases where the user provides an alternate `alloc` crate, however I believe this is an acceptable compromise. Additionally, this crate itself doesn't need to be `no_std`, it just needs to _generate_ `no_std` compatible code. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
robtfm
pushed a commit
to robtfm/bevy
that referenced
this pull request
Oct 4, 2024
) # Objective - Contributes to bevyengine#15460 ## Solution - Wrap `derive_label` `quote!` in an anonymous constant which contains an `extern crate alloc` statement, allowing use of the `alloc` namespace even when a user has not brought in the crate themselves. ## Testing - CI passed locally. ## Notes We can't generate code that uses `::std::boxed::Box` in `no_std` environments, but we also can't rely on `::alloc::boxed::Box` either, since the user might not have declared `extern crate alloc`. To resolve this, the generated code is wrapped in an anonymous constant which contains the `extern crate alloc` invocation. This does mean the macro is no longer hygienic against cases where the user provides an alternate `alloc` crate, however I believe this is an acceptable compromise. Additionally, this crate itself doesn't need to be `no_std`, it just needs to _generate_ `no_std` compatible code. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
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
3 participants
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.
Objective
no_stdBevy #15460Solution
derive_labelquote!in an anonymous constant which contains anextern crate allocstatement, allowing use of theallocnamespace even when a user has not brought in the crate themselves.Testing
Notes
We can't generate code that uses
::std::boxed::Boxinno_stdenvironments, but we also can't rely on::alloc::boxed::Boxeither, since the user might not have declaredextern crate alloc. To resolve this, the generated code is wrapped in an anonymous constant which contains theextern crate allocinvocation.This does mean the macro is no longer hygienic against cases where the user provides an alternate
alloccrate, however I believe this is an acceptable compromise.Additionally, this crate itself doesn't need to be
no_std, it just needs to generateno_stdcompatible code.