Skip to content

ECS metadata stores should operate on Pin<&mut T> #12272

@james7132

Description

@james7132

What problem does this solve or what need does it fill?

#10756 highlighted std::mem::swap and std::mem::take as potential venues for unsoundness: moving the metadata out of the World invalidates the metadata stores, which the entire rest of the ECS implementation relies on.

What solution would you like?

Use the tools that Rust gives us to prevent trivial moves: std::pin::Pin. Core metadata stores like Components, Archetypes, Bundles, etc. should minimize mutable access, and only return mutable access in the form of Pin<&mut T> instead of &mut T.

Note this likely means the Index/IndexMut implementations for these various metadata stores will need to go away, as they require &mut T to be returned.

bevy_ecs already follows the practices of not exposing any mutable access to metadata stores in it's public interface, but I'm of the opinion that the internal APIs should be no different either. There are quite a few cases of pub(crate) access that should be minimized where possible.

What alternative(s) have you considered?

Returning wrappers around &mut ComponentInfo and the other metadata. Requires much more code to implement.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ECSEntities, components, systems, and eventsP-UnsoundA bug that results in undefined compiler behavior

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions