Skip to content

Conversation

@hymm
Copy link
Contributor

@hymm hymm commented Dec 15, 2025

Objective

  • narrow the scope of the expect unsafe_op_in_unsafe_fn, so we can progressively remove them.

Testing

  • cargo check showed no warnings

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Code-Quality A section of code that is hard to understand or change X-Uncontroversial This work is generally agreed upon D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged labels Dec 15, 2025
@alice-i-cecile
Copy link
Member

Ping me when CI is green and I'll approve :)

.get_resource_ref::<HotPatchChanges>()
.map(|r| r.last_changed())
.unwrap_or_default();
// SAFETY: No system should mutate `HotPatchChanges`
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not the best safety, but hotpatching is already pretty unsafe and the resource only exists when hotpatching is active.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not really convinced by this safety doc. "Should" seems to imply that HotPatchChanges can be mutated while this reference is held.

The safety doc should prove that the unsafe operation is in-fact safe. For example, if HotPatchChanges cannot be mutated during this, then the safety doc should mention as such. Same with if it's the caller's responsibility to uphold that safety.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not safe. A system could actually try to mutate HotPatchChanges. But I'm don't think it's worth making this safe. We'd have to check if any system that is added tries to mutate HotPatchChanges. But they could only make a system that mutates HotPatchChanges when the hotpatching feature is enabled. Overall hotpatching is probably UB, so if someone ships with hotpatching enabled it's already a problem.

Copy link
Contributor

@LikeLakers2 LikeLakers2 Dec 15, 2025

Choose a reason for hiding this comment

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

It's not safe.

Then the safety doc should be removed, as it's not documenting the safety of the unsafe {} block.

And actually, if we know this to be unsafe, then we should document it as such. This ensures a couple things:

  1. Users perusing the code won't be confused into thinking that thus unsafe operation is somehow safe.
  2. Future safety-related PRs will know that this code is unsafe, giving them an idea of what they're getting into.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe we can use an expect annotation here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we can use an expect annotation here?

Yeah, that might be more clear.

@alice-i-cecile alice-i-cecile added X-Contentious There are nontrivial implications that should be thought through and removed X-Uncontroversial This work is generally agreed upon labels Dec 15, 2025
Copy link
Contributor

@LikeLakers2 LikeLakers2 left a comment

Choose a reason for hiding this comment

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

Sorry for being pedantic in my previous comments. I think it looks okay now.

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.

I like the use of expect here: reading it makes me flinch, as it should lol. This is a good incremental step towards fixing these problems, let's merge it.

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Dec 19, 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 Dec 19, 2025
Merged via the queue into bevyengine:main with commit ffc66f1 Dec 19, 2025
38 checks passed
@hymm hymm deleted the move-allow-to-moduel-level branch December 19, 2025 03:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-ECS Entities, components, systems, and events C-Code-Quality A section of code that is hard to understand or change D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it X-Contentious There are nontrivial implications that should be thought through

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants