[Merged by Bors] - add more `SAFETY` comments and lint for missing ones in `bevy_ecs` #4835

jakobhellermann · 2022-05-24T18:03:06Z

Objective

SAFETY comments are meant to be placed before unsafe blocks and should contain the reasoning of why in this case the usage of unsafe is okay. This is useful when reading the code because it makes it clear which assumptions are required for safety, and makes it easier to spot possible unsoundness holes. It also forces the code writer to think of something to write and maybe look at the safety contracts of any called unsafe methods again to double-check their correct usage.

There's a clippy lint called undocumented_unsafe_blocks which warns when using a block without such a comment.

Solution

since clippy expects SAFETY instead of SAFE, rename those
add SAFETY comments in more places
for the last remaining 3 places, add an #[allow()] and // TODO since I wasn't comfortable enough with the code to justify their safety
add #![warn(clippy::undocumented_unsafe_blocks)] to bevy_ecs

Note for reviewers

The first commit only renames SAFETY to SAFE so it doesn't need a thorough review.
https://github.com/bevyengine/bevy/pull/4835/files/cb042a416ecbe5e7d74797449969e064d8a5f13c..55cef2d6fa3aa634667a60f6d5abc16f43f16298 is the diff for all other changes.

Safety comments where I'm not too familiar with the code

bevy/crates/bevy_ecs/src/entity/mod.rs

Lines 540 to 546 in 774012e

    
           // SAFETY: as per `flush` safety docs, the archetype id can be set to [`ArchetypeId::INVALID`] if 
        
           // the [`Entity`] has not been assigned to an [`Archetype`][crate::archetype::Archetype], which is the case here 
        
           unsafe { 
        
               self.flush(|_entity, location| { 
        
                   location.archetype_id = ArchetypeId::INVALID; 
        
               }); 
        
           }

bevy/crates/bevy_ecs/src/world/entity_ref.rs

Lines 249 to 252 in 774012e

    
           // SAFETY: `archetype_id` exists because it is referenced in the old `EntityLocation` which is valid, 
        
           // components exist in `bundle_info` because `Bundles::init_info` initializes a `BundleInfo` containing all components of the bundle type `T` 
        
           let new_archetype_id = unsafe { 
        
               remove_bundle_from_archetype(

Locations left undocumented with a `TODO` comment

bevy/crates/bevy_ecs/src/schedule/executor_parallel.rs

Lines 196 to 199 in 5dde944

    
           #[allow(clippy::undocumented_unsafe_blocks)] // TODO: document why this is safe 
        
           unsafe { 
        
               system.run_unsafe((), world) 
        
           };

bevy/crates/bevy_ecs/src/world/entity_ref.rs

Lines 287 to 289 in 5dde944

    
           #[allow(clippy::undocumented_unsafe_blocks)] // TODO: document why this is safe 
        
           unsafe { 
        
               Self::move_entity_from_remove::<false>(

bevy/crates/bevy_ecs/src/world/entity_ref.rs

Lines 413 to 415 in 5dde944

    
           #[allow(clippy::undocumented_unsafe_blocks)] // TODO: document why this is safe 
        
           unsafe { 
        
               Self::move_entity_from_remove::<true>(

crates/bevy_ecs/src/schedule/executor_parallel.rs

alice-i-cecile

This should note that Command: Send as a trait bound.

alice-i-cecile

I'm happy with both the direction and the safety comments added. I think this should wait on @cart as it's a) a change to project style and b) mostly their code.

cart · 2022-06-11T03:05:35Z

Definitely on board for these changes! I'll do one last review once conflicts have been resolved, but I think this is pretty much good to go.

jakobhellermann · 2022-06-20T11:18:16Z

rebased

cart

The new safety docs are correct and checking for undocumented unsafe blocks is a huge improvement. Thanks!

One last round of merge conflict resolutions and then we should merge this asap.

cart · 2022-06-30T20:10:34Z

bors r+

…4835) # Objective `SAFETY` comments are meant to be placed before `unsafe` blocks and should contain the reasoning of why in this case the usage of unsafe is okay. This is useful when reading the code because it makes it clear which assumptions are required for safety, and makes it easier to spot possible unsoundness holes. It also forces the code writer to think of something to write and maybe look at the safety contracts of any called unsafe methods again to double-check their correct usage. There's a clippy lint called `undocumented_unsafe_blocks` which warns when using a block without such a comment. ## Solution - since clippy expects `SAFETY` instead of `SAFE`, rename those - add `SAFETY` comments in more places - for the last remaining 3 places, add an `#[allow()]` and `// TODO` since I wasn't comfortable enough with the code to justify their safety - add ` #![warn(clippy::undocumented_unsafe_blocks)]` to `bevy_ecs` ### Note for reviewers The first commit only renames `SAFETY` to `SAFE` so it doesn't need a thorough review. https://github.com/bevyengine/bevy/pull/4835/files/cb042a416ecbe5e7d74797449969e064d8a5f13c..55cef2d6fa3aa634667a60f6d5abc16f43f16298 is the diff for all other changes. ### Safety comments where I'm not too familiar with the code https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/entity/mod.rs#L540-L546 https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/world/entity_ref.rs#L249-L252 ### Locations left undocumented with a `TODO` comment https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/schedule/executor_parallel.rs#L196-L199 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L287-L289 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L413-L415 Co-authored-by: Jakob Hellermann <[email protected]>

bors · 2022-06-30T20:20:57Z

Build failed:

ci

…undocumented_unsafe_blocks

jakobhellermann · 2022-07-01T07:56:39Z

I documented the blob vec safety in 4de4571, switching the increment in grow_exact to a NonZeroUsize and making it an unsafe fn requiring it not to be called on a ZST layout vec.

I also introduced a new runtime check in reserve_exact:

-        if available_space < additional {
+        if available_space < additional && self.item_layout.size() > 0 {

alice-i-cecile

New changes LGTM. The runtime check is worth it for soundness too. I'll retry this once I get a second approval.

alice-i-cecile · 2022-07-04T13:05:50Z

bors r+

…4835) # Objective `SAFETY` comments are meant to be placed before `unsafe` blocks and should contain the reasoning of why in this case the usage of unsafe is okay. This is useful when reading the code because it makes it clear which assumptions are required for safety, and makes it easier to spot possible unsoundness holes. It also forces the code writer to think of something to write and maybe look at the safety contracts of any called unsafe methods again to double-check their correct usage. There's a clippy lint called `undocumented_unsafe_blocks` which warns when using a block without such a comment. ## Solution - since clippy expects `SAFETY` instead of `SAFE`, rename those - add `SAFETY` comments in more places - for the last remaining 3 places, add an `#[allow()]` and `// TODO` since I wasn't comfortable enough with the code to justify their safety - add ` #![warn(clippy::undocumented_unsafe_blocks)]` to `bevy_ecs` ### Note for reviewers The first commit only renames `SAFETY` to `SAFE` so it doesn't need a thorough review. https://github.com/bevyengine/bevy/pull/4835/files/cb042a416ecbe5e7d74797449969e064d8a5f13c..55cef2d6fa3aa634667a60f6d5abc16f43f16298 is the diff for all other changes. ### Safety comments where I'm not too familiar with the code https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/entity/mod.rs#L540-L546 https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/world/entity_ref.rs#L249-L252 ### Locations left undocumented with a `TODO` comment https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/schedule/executor_parallel.rs#L196-L199 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L287-L289 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L413-L415 Co-authored-by: Jakob Hellermann <[email protected]>

bors · 2022-07-04T13:51:28Z

Build failed (retrying...):

ci

…4835) # Objective `SAFETY` comments are meant to be placed before `unsafe` blocks and should contain the reasoning of why in this case the usage of unsafe is okay. This is useful when reading the code because it makes it clear which assumptions are required for safety, and makes it easier to spot possible unsoundness holes. It also forces the code writer to think of something to write and maybe look at the safety contracts of any called unsafe methods again to double-check their correct usage. There's a clippy lint called `undocumented_unsafe_blocks` which warns when using a block without such a comment. ## Solution - since clippy expects `SAFETY` instead of `SAFE`, rename those - add `SAFETY` comments in more places - for the last remaining 3 places, add an `#[allow()]` and `// TODO` since I wasn't comfortable enough with the code to justify their safety - add ` #![warn(clippy::undocumented_unsafe_blocks)]` to `bevy_ecs` ### Note for reviewers The first commit only renames `SAFETY` to `SAFE` so it doesn't need a thorough review. https://github.com/bevyengine/bevy/pull/4835/files/cb042a416ecbe5e7d74797449969e064d8a5f13c..55cef2d6fa3aa634667a60f6d5abc16f43f16298 is the diff for all other changes. ### Safety comments where I'm not too familiar with the code https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/entity/mod.rs#L540-L546 https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/world/entity_ref.rs#L249-L252 ### Locations left undocumented with a `TODO` comment https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/schedule/executor_parallel.rs#L196-L199 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L287-L289 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L413-L415 Co-authored-by: Jakob Hellermann <[email protected]>

bors · 2022-07-04T14:17:40Z

Build failed:

ci

jakobhellermann · 2022-07-04T14:23:12Z

@alice-i-cecile there were two new undocumented usages of unsafe which are fixed now, I think bors can be retried again

alice-i-cecile · 2022-07-04T14:34:20Z

bors retry

…4835) # Objective `SAFETY` comments are meant to be placed before `unsafe` blocks and should contain the reasoning of why in this case the usage of unsafe is okay. This is useful when reading the code because it makes it clear which assumptions are required for safety, and makes it easier to spot possible unsoundness holes. It also forces the code writer to think of something to write and maybe look at the safety contracts of any called unsafe methods again to double-check their correct usage. There's a clippy lint called `undocumented_unsafe_blocks` which warns when using a block without such a comment. ## Solution - since clippy expects `SAFETY` instead of `SAFE`, rename those - add `SAFETY` comments in more places - for the last remaining 3 places, add an `#[allow()]` and `// TODO` since I wasn't comfortable enough with the code to justify their safety - add ` #![warn(clippy::undocumented_unsafe_blocks)]` to `bevy_ecs` ### Note for reviewers The first commit only renames `SAFETY` to `SAFE` so it doesn't need a thorough review. https://github.com/bevyengine/bevy/pull/4835/files/cb042a416ecbe5e7d74797449969e064d8a5f13c..55cef2d6fa3aa634667a60f6d5abc16f43f16298 is the diff for all other changes. ### Safety comments where I'm not too familiar with the code https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/entity/mod.rs#L540-L546 https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/world/entity_ref.rs#L249-L252 ### Locations left undocumented with a `TODO` comment https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/schedule/executor_parallel.rs#L196-L199 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L287-L289 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L413-L415 Co-authored-by: Jakob Hellermann <[email protected]>

bors · 2022-07-04T15:05:55Z

Pull request successfully merged into main.

Build succeeded:

…evyengine#4835) `SAFETY` comments are meant to be placed before `unsafe` blocks and should contain the reasoning of why in this case the usage of unsafe is okay. This is useful when reading the code because it makes it clear which assumptions are required for safety, and makes it easier to spot possible unsoundness holes. It also forces the code writer to think of something to write and maybe look at the safety contracts of any called unsafe methods again to double-check their correct usage. There's a clippy lint called `undocumented_unsafe_blocks` which warns when using a block without such a comment. - since clippy expects `SAFETY` instead of `SAFE`, rename those - add `SAFETY` comments in more places - for the last remaining 3 places, add an `#[allow()]` and `// TODO` since I wasn't comfortable enough with the code to justify their safety - add ` #![warn(clippy::undocumented_unsafe_blocks)]` to `bevy_ecs` The first commit only renames `SAFETY` to `SAFE` so it doesn't need a thorough review. https://github.com/bevyengine/bevy/pull/4835/files/cb042a416ecbe5e7d74797449969e064d8a5f13c..55cef2d6fa3aa634667a60f6d5abc16f43f16298 is the diff for all other changes. https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/entity/mod.rs#L540-L546 https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/world/entity_ref.rs#L249-L252 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/schedule/executor_parallel.rs#L196-L199 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L287-L289 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L413-L415 Co-authored-by: Jakob Hellermann <[email protected]>

…evyengine#4835) # Objective `SAFETY` comments are meant to be placed before `unsafe` blocks and should contain the reasoning of why in this case the usage of unsafe is okay. This is useful when reading the code because it makes it clear which assumptions are required for safety, and makes it easier to spot possible unsoundness holes. It also forces the code writer to think of something to write and maybe look at the safety contracts of any called unsafe methods again to double-check their correct usage. There's a clippy lint called `undocumented_unsafe_blocks` which warns when using a block without such a comment. ## Solution - since clippy expects `SAFETY` instead of `SAFE`, rename those - add `SAFETY` comments in more places - for the last remaining 3 places, add an `#[allow()]` and `// TODO` since I wasn't comfortable enough with the code to justify their safety - add ` #![warn(clippy::undocumented_unsafe_blocks)]` to `bevy_ecs` ### Note for reviewers The first commit only renames `SAFETY` to `SAFE` so it doesn't need a thorough review. https://github.com/bevyengine/bevy/pull/4835/files/cb042a416ecbe5e7d74797449969e064d8a5f13c..55cef2d6fa3aa634667a60f6d5abc16f43f16298 is the diff for all other changes. ### Safety comments where I'm not too familiar with the code https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/entity/mod.rs#L540-L546 https://github.com/bevyengine/bevy/blob/774012ece50e4add4fcc8324ec48bbecf5546c3c/crates/bevy_ecs/src/world/entity_ref.rs#L249-L252 ### Locations left undocumented with a `TODO` comment https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/schedule/executor_parallel.rs#L196-L199 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L287-L289 https://github.com/bevyengine/bevy/blob/5dde944a3051426ac69fdedc5699f7da97a7e147/crates/bevy_ecs/src/world/entity_ref.rs#L413-L415 Co-authored-by: Jakob Hellermann <[email protected]>

jakobhellermann added C-Code-Quality A section of code that is hard to understand or change X-Controversial There is active debate or serious implications around merging this PR labels May 24, 2022

hymm reviewed May 24, 2022

View reviewed changes

crates/bevy_ecs/src/schedule/executor_parallel.rs Outdated Show resolved Hide resolved

alice-i-cecile added the A-ECS Entities, components, systems, and events label May 25, 2022

alice-i-cecile requested a review from BoxyUwU May 30, 2022 17:17

alice-i-cecile reviewed May 30, 2022

View reviewed changes

alice-i-cecile approved these changes May 30, 2022

View reviewed changes

jakobhellermann force-pushed the checked-safety-comments branch from 55cef2d to a1c63a9 Compare June 20, 2022 11:18

jakobhellermann force-pushed the checked-safety-comments branch from a1c63a9 to 3d67d6e Compare June 20, 2022 11:19

cart approved these changes Jun 28, 2022

View reviewed changes

jakobhellermann force-pushed the checked-safety-comments branch from 3d67d6e to 8aebb8a Compare June 29, 2022 12:33

jakobhellermann and others added 12 commits July 1, 2022 08:22

change 'SAFE:' to 'SAFETY:' to be in the expected format for clippy::…

ebd35c0

…undocumented_unsafe_blocks

add some SAFETY comments

947bd1f

add SAFETY comments to QueryIterationCursor

e34a420

add allows + TODOs for the last remaining undocumented unsafe blocks

dff0fc6

warn for clippy::undocumented_unsafe_blocks in bevy_ecs

15a566d

add SAFETY comments outside of bevy_ecs

d911e9d

document safety of system.run_unsafe

f3b26dd

add safety comments to new usages of unsafe

f99594b

add safety comments to unsafe impls, which are now included in the lint

3530605

add allow for false positive clippy lint

72d993b

query iteration safety comments

f0461b0

document safety in blob vec

4de4571

jakobhellermann force-pushed the checked-safety-comments branch from 8aebb8a to 4de4571 Compare July 1, 2022 07:53

safety comments in tests

20f51f1

alice-i-cecile approved these changes Jul 1, 2022

View reviewed changes

james7132 added the P-Unsound A bug that results in undefined compiler behavior label Jul 2, 2022

james7132 approved these changes Jul 2, 2022

View reviewed changes

james7132 added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Jul 2, 2022

james7132 mentioned this pull request Jul 2, 2022

don't call BlobVec::grow_exact for zero-sized layouts #4769

Closed

Merge branch 'main' into checked-safety-comments

a8b6bbb

jakobhellermann added 2 commits July 4, 2022 16:20

safety comments for ReflectResource

0c1ecf5

safety comment for BlobVec drop

e3fe6b6

jakobhellermann removed the request for review from BoxyUwU July 4, 2022 14:22

alice-i-cecile approved these changes Jul 4, 2022

View reviewed changes

bors bot changed the title ~~add more SAFETY comments and lint for missing ones in bevy_ecs~~ [Merged by Bors] - add more SAFETY comments and lint for missing ones in bevy_ecs Jul 4, 2022

bors bot closed this Jul 4, 2022

jakobhellermann deleted the checked-safety-comments branch July 4, 2022 15:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Merged by Bors] - add more `SAFETY` comments and lint for missing ones in `bevy_ecs` #4835

[Merged by Bors] - add more `SAFETY` comments and lint for missing ones in `bevy_ecs` #4835

jakobhellermann commented May 24, 2022 •

edited

Loading

alice-i-cecile left a comment

alice-i-cecile left a comment

cart commented Jun 11, 2022 •

edited

Loading

jakobhellermann commented Jun 20, 2022

cart left a comment

cart commented Jun 30, 2022

bors bot commented Jun 30, 2022

jakobhellermann commented Jul 1, 2022

alice-i-cecile left a comment •

edited

Loading

alice-i-cecile commented Jul 4, 2022

bors bot commented Jul 4, 2022

bors bot commented Jul 4, 2022

jakobhellermann commented Jul 4, 2022

alice-i-cecile commented Jul 4, 2022

bors bot commented Jul 4, 2022

	// SAFETY: as per `flush` safety docs, the archetype id can be set to [`ArchetypeId::INVALID`] if
	// the [`Entity`] has not been assigned to an [`Archetype`][crate::archetype::Archetype], which is the case here
	unsafe {
	self.flush(\|_entity, location\| {
	location.archetype_id = ArchetypeId::INVALID;
	});
	}

	// SAFETY: `archetype_id` exists because it is referenced in the old `EntityLocation` which is valid,
	// components exist in `bundle_info` because `Bundles::init_info` initializes a `BundleInfo` containing all components of the bundle type `T`
	let new_archetype_id = unsafe {
	remove_bundle_from_archetype(

	#[allow(clippy::undocumented_unsafe_blocks)] // TODO: document why this is safe
	unsafe {
	system.run_unsafe((), world)
	};

	#[allow(clippy::undocumented_unsafe_blocks)] // TODO: document why this is safe
	unsafe {
	Self::move_entity_from_remove::<false>(

	#[allow(clippy::undocumented_unsafe_blocks)] // TODO: document why this is safe
	unsafe {
	Self::move_entity_from_remove::<true>(

[Merged by Bors] - add more SAFETY comments and lint for missing ones in bevy_ecs #4835

[Merged by Bors] - add more SAFETY comments and lint for missing ones in bevy_ecs #4835

Conversation

jakobhellermann commented May 24, 2022 • edited Loading

Objective

Solution

Note for reviewers

Safety comments where I'm not too familiar with the code

Locations left undocumented with a TODO comment

alice-i-cecile left a comment

Choose a reason for hiding this comment

alice-i-cecile left a comment

Choose a reason for hiding this comment

cart commented Jun 11, 2022 • edited Loading

jakobhellermann commented Jun 20, 2022

cart left a comment

Choose a reason for hiding this comment

cart commented Jun 30, 2022

bors bot commented Jun 30, 2022

jakobhellermann commented Jul 1, 2022

alice-i-cecile left a comment • edited Loading

Choose a reason for hiding this comment

alice-i-cecile commented Jul 4, 2022

bors bot commented Jul 4, 2022

bors bot commented Jul 4, 2022

jakobhellermann commented Jul 4, 2022

alice-i-cecile commented Jul 4, 2022

bors bot commented Jul 4, 2022

[Merged by Bors] - add more `SAFETY` comments and lint for missing ones in `bevy_ecs` #4835

[Merged by Bors] - add more `SAFETY` comments and lint for missing ones in `bevy_ecs` #4835

jakobhellermann commented May 24, 2022 •

edited

Loading

Locations left undocumented with a `TODO` comment

cart commented Jun 11, 2022 •

edited

Loading

alice-i-cecile left a comment •

edited

Loading