bevy/crates/bevy_app/src/lib.rs

38 lines
987 B
Rust
Raw Normal View History

#![cfg_attr(docsrs, feature(doc_auto_cfg))]
Forbid unsafe in most crates in the engine (#12684) # Objective Resolves #3824. `unsafe` code should be the exception, not the norm in Rust. It's obviously needed for various use cases as it's interfacing with platforms and essentially running the borrow checker at runtime in the ECS, but the touted benefits of Bevy is that we are able to heavily leverage Rust's safety, and we should be holding ourselves accountable to that by minimizing our unsafe footprint. ## Solution Deny `unsafe_code` workspace wide. Add explicit exceptions for the following crates, and forbid it in almost all of the others. * bevy_ecs - Obvious given how much unsafe is needed to achieve performant results * bevy_ptr - Works with raw pointers, even more low level than bevy_ecs. * bevy_render - due to needing to integrate with wgpu * bevy_window - due to needing to integrate with raw_window_handle * bevy_utils - Several unsafe utilities used by bevy_ecs. Ideally moved into bevy_ecs instead of made publicly usable. * bevy_reflect - Required for the unsafe type casting it's doing. * bevy_transform - for the parallel transform propagation * bevy_gizmos - For the SystemParam impls it has. * bevy_assets - To support reflection. Might not be required, not 100% sure yet. * bevy_mikktspace - due to being a conversion from a C library. Pending safe rewrite. * bevy_dynamic_plugin - Inherently unsafe due to the dynamic loading nature. Several uses of unsafe were rewritten, as they did not need to be using them: * bevy_text - a case of `Option::unchecked` could be rewritten as a normal for loop and match instead of an iterator. * bevy_color - the Pod/Zeroable implementations were replaceable with bytemuck's derive macros.
2024-03-27 03:30:08 +00:00
#![forbid(unsafe_code)]
#![doc(
html_logo_url = "https://bevyengine.org/assets/icon.png",
html_favicon_url = "https://bevyengine.org/assets/icon.png"
)]
//! This crate is about everything concerning the highest-level, application layer of a Bevy app.
2020-04-06 03:19:02 +00:00
mod app;
mod main_schedule;
mod panic_handler;
2020-04-06 03:19:02 +00:00
mod plugin;
mod plugin_group;
2020-07-17 01:47:51 +00:00
mod schedule_runner;
2020-04-06 03:19:02 +00:00
pub use app::*;
2020-08-08 03:22:17 +00:00
pub use bevy_derive::DynamicPlugin;
pub use main_schedule::*;
pub use panic_handler::*;
2020-04-06 21:20:53 +00:00
pub use plugin::*;
pub use plugin_group::*;
2020-07-17 01:47:51 +00:00
pub use schedule_runner::*;
#[allow(missing_docs)]
2020-07-17 01:47:51 +00:00
pub mod prelude {
#[doc(hidden)]
Move the CoreStage::Startup to a seperate StartupSchedule label (#2434) # Objective - `CoreStage::Startup` is unique in the `CoreStage` enum, in that it represents a `Schedule` and not a `SystemStage`. - This can lead to confusion about how `CoreStage::Startup` and the `StartupStage` enum are related. - Beginners sometimes try `.add_system_to_stage(CoreStage::Startup, setup.system())` instead of `.add_startup_system(setup.system())`, which causes a Panic: ``` thread 'main' panicked at 'Stage 'Startup' does not exist or is not a SystemStage', crates\bevy_ecs\src\schedule\mod.rs:153:13 stack backtrace: 0: std::panicking::begin_panic_handler at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b\/library\std\src\panicking.rs:493 1: std::panicking::begin_panic_fmt at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b\/library\std\src\panicking.rs:435 2: bevy_ecs::schedule::{{impl}}::add_system_to_stage::stage_not_found at .\crates\bevy_ecs\src\schedule\mod.rs:153 3: bevy_ecs::schedule::{{impl}}::add_system_to_stage::{{closure}}<tuple<bevy_ecs::system::function_system::IsFunctionSystem, tuple<bevy_ecs::system::commands::Commands, bevy_ecs::change_detection::ResMut<bevy_asset::assets::Assets<bevy_render::mesh::mesh::Me at .\crates\bevy_ecs\src\schedule\mod.rs:161 4: core::option::Option<mut bevy_ecs::schedule::stage::SystemStage*>::unwrap_or_else<mut bevy_ecs::schedule::stage::SystemStage*,closure-0> at C:\Users\scher\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\option.rs:427 5: bevy_ecs::schedule::Schedule::add_system_to_stage<tuple<bevy_ecs::system::function_system::IsFunctionSystem, tuple<bevy_ecs::system::commands::Commands, bevy_ecs::change_detection::ResMut<bevy_asset::assets::Assets<bevy_render::mesh::mesh::Mesh>>, bevy_ec at .\crates\bevy_ecs\src\schedule\mod.rs:159 6: bevy_app::app_builder::AppBuilder::add_system_to_stage<tuple<bevy_ecs::system::function_system::IsFunctionSystem, tuple<bevy_ecs::system::commands::Commands, bevy_ecs::change_detection::ResMut<bevy_asset::assets::Assets<bevy_render::mesh::mesh::Mesh>>, be at .\crates\bevy_app\src\app_builder.rs:196 7: 3d_scene::main at .\examples\3d\3d_scene.rs:4 8: core::ops::function::FnOnce::call_once<fn(),tuple<>> at C:\Users\scher\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ops\function.rs:227 ``` ## Solution - Replace the `CoreStage::Startup` Label with the new `StartupSchedule` unit type. Resolves #2229
2022-02-08 00:03:50 +00:00
pub use crate::{
app::App,
main_schedule::{
First, FixedFirst, FixedLast, FixedPostUpdate, FixedPreUpdate, FixedUpdate, Last, Main,
PostStartup, PostUpdate, PreStartup, PreUpdate, SpawnScene, Startup, StateTransition,
Update,
},
DynamicPlugin, Plugin, PluginGroup,
Move the CoreStage::Startup to a seperate StartupSchedule label (#2434) # Objective - `CoreStage::Startup` is unique in the `CoreStage` enum, in that it represents a `Schedule` and not a `SystemStage`. - This can lead to confusion about how `CoreStage::Startup` and the `StartupStage` enum are related. - Beginners sometimes try `.add_system_to_stage(CoreStage::Startup, setup.system())` instead of `.add_startup_system(setup.system())`, which causes a Panic: ``` thread 'main' panicked at 'Stage 'Startup' does not exist or is not a SystemStage', crates\bevy_ecs\src\schedule\mod.rs:153:13 stack backtrace: 0: std::panicking::begin_panic_handler at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b\/library\std\src\panicking.rs:493 1: std::panicking::begin_panic_fmt at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b\/library\std\src\panicking.rs:435 2: bevy_ecs::schedule::{{impl}}::add_system_to_stage::stage_not_found at .\crates\bevy_ecs\src\schedule\mod.rs:153 3: bevy_ecs::schedule::{{impl}}::add_system_to_stage::{{closure}}<tuple<bevy_ecs::system::function_system::IsFunctionSystem, tuple<bevy_ecs::system::commands::Commands, bevy_ecs::change_detection::ResMut<bevy_asset::assets::Assets<bevy_render::mesh::mesh::Me at .\crates\bevy_ecs\src\schedule\mod.rs:161 4: core::option::Option<mut bevy_ecs::schedule::stage::SystemStage*>::unwrap_or_else<mut bevy_ecs::schedule::stage::SystemStage*,closure-0> at C:\Users\scher\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\option.rs:427 5: bevy_ecs::schedule::Schedule::add_system_to_stage<tuple<bevy_ecs::system::function_system::IsFunctionSystem, tuple<bevy_ecs::system::commands::Commands, bevy_ecs::change_detection::ResMut<bevy_asset::assets::Assets<bevy_render::mesh::mesh::Mesh>>, bevy_ec at .\crates\bevy_ecs\src\schedule\mod.rs:159 6: bevy_app::app_builder::AppBuilder::add_system_to_stage<tuple<bevy_ecs::system::function_system::IsFunctionSystem, tuple<bevy_ecs::system::commands::Commands, bevy_ecs::change_detection::ResMut<bevy_asset::assets::Assets<bevy_render::mesh::mesh::Mesh>>, be at .\crates\bevy_app\src\app_builder.rs:196 7: 3d_scene::main at .\examples\3d\3d_scene.rs:4 8: core::ops::function::FnOnce::call_once<fn(),tuple<>> at C:\Users\scher\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ops\function.rs:227 ``` ## Solution - Replace the `CoreStage::Startup` Label with the new `StartupSchedule` unit type. Resolves #2229
2022-02-08 00:03:50 +00:00
};
2020-07-17 01:47:51 +00:00
}