0403948aa2
# 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.
111 lines
3.3 KiB
Rust
111 lines
3.3 KiB
Rust
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
|
|
#![forbid(unsafe_code)]
|
|
#![doc(
|
|
html_logo_url = "https://bevyengine.org/assets/icon.png",
|
|
html_favicon_url = "https://bevyengine.org/assets/icon.png"
|
|
)]
|
|
#![no_std]
|
|
|
|
//! Parent-child relationships for Bevy entities.
|
|
//!
|
|
//! You should use the tools in this crate
|
|
//! whenever you want to organize your entities in a hierarchical fashion,
|
|
//! to make groups of entities more manageable,
|
|
//! or to propagate properties throughout the entity hierarchy.
|
|
//!
|
|
//! This crate introduces various tools, including a [plugin]
|
|
//! for managing parent-child relationships between entities.
|
|
//! It provides two components, [`Parent`] and [`Children`],
|
|
//! to store references to related entities.
|
|
//! It also provides [command and world] API extensions
|
|
//! to set and clear those relationships.
|
|
//!
|
|
//! More advanced users may also appreciate
|
|
//! [query extension methods] to traverse hierarchies,
|
|
//! and [events] to notify hierarchical changes.
|
|
//! There is also a [diagnostic plugin] to validate property propagation.
|
|
//!
|
|
//! # Hierarchy management
|
|
//!
|
|
//! The methods defined in this crate fully manage
|
|
//! the components responsible for defining the entity hierarchy.
|
|
//! Mutating these components manually may result in hierarchy invalidation.
|
|
//!
|
|
//! Hierarchical relationships are always managed symmetrically.
|
|
//! For example, assigning a child to an entity
|
|
//! will always set the parent in the other,
|
|
//! and vice versa.
|
|
//! Similarly, unassigning a child in the parent
|
|
//! will always unassign the parent in the child.
|
|
//!
|
|
//! ## Despawning entities
|
|
//!
|
|
//! The commands and methods provided by `bevy_ecs` to despawn entities
|
|
//! are not capable of automatically despawning hierarchies of entities.
|
|
//! In most cases, these operations will invalidate the hierarchy.
|
|
//! Instead, you should use the provided [hierarchical despawn extension methods].
|
|
//!
|
|
//! [command and world]: BuildChildren
|
|
//! [diagnostic plugin]: ValidParentCheckPlugin
|
|
//! [events]: HierarchyEvent
|
|
//! [hierarchical despawn extension methods]: DespawnRecursiveExt
|
|
//! [plugin]: HierarchyPlugin
|
|
//! [query extension methods]: HierarchyQueryExt
|
|
|
|
#[cfg(feature = "std")]
|
|
extern crate std;
|
|
|
|
extern crate alloc;
|
|
|
|
mod components;
|
|
pub use components::*;
|
|
|
|
mod hierarchy;
|
|
pub use hierarchy::*;
|
|
|
|
mod child_builder;
|
|
pub use child_builder::*;
|
|
|
|
mod events;
|
|
pub use events::*;
|
|
|
|
mod valid_parent_check_plugin;
|
|
pub use valid_parent_check_plugin::*;
|
|
|
|
mod query_extension;
|
|
pub use query_extension::*;
|
|
|
|
/// The hierarchy prelude.
|
|
///
|
|
/// This includes the most common types in this crate, re-exported for your convenience.
|
|
pub mod prelude {
|
|
#[doc(hidden)]
|
|
pub use crate::{child_builder::*, components::*, hierarchy::*, query_extension::*};
|
|
|
|
#[doc(hidden)]
|
|
#[cfg(feature = "bevy_app")]
|
|
pub use crate::{HierarchyPlugin, ValidParentCheckPlugin};
|
|
}
|
|
|
|
#[cfg(feature = "bevy_app")]
|
|
use bevy_app::prelude::*;
|
|
|
|
/// Provides hierarchy functionality to a Bevy app.
|
|
///
|
|
/// Check the [crate-level documentation] for all the features.
|
|
///
|
|
/// [crate-level documentation]: crate
|
|
#[cfg(feature = "bevy_app")]
|
|
#[derive(Default)]
|
|
pub struct HierarchyPlugin;
|
|
|
|
#[cfg(feature = "bevy_app")]
|
|
impl Plugin for HierarchyPlugin {
|
|
fn build(&self, app: &mut App) {
|
|
#[cfg(feature = "reflect")]
|
|
app.register_type::<Children>().register_type::<Parent>();
|
|
|
|
app.add_event::<HierarchyEvent>();
|
|
}
|
|
}
|