Keep the value in its storage after destroy #4678
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
cargo clippy
.Connections
Fixes #4668
Description
in #4657 the destroy implementation was made to remove the value from the storage and leave an error variant in its place. Unfortunately this causes some issues with the buffer tracking code which expects the ID to be unregistered after the value has been fully destroyed, even if the latter does not need to be in storage anymore. To work around that, this commit adds a
Destroyed
variant in storage which keeps the value so that the previous tracking behavior is preserved while still making sure that most accesses to the destroyed resource lead to validation errors.... Except for submitted command buffers that need to be consumed right away. These are replaced with
Element::Error
like before this commit.It's a fair bit unsavory to have the two ways to do the same thing in principle, but a better solution will take more time to bake and would conflict unnecessarily with the arcanization work.
Testing
An existing test was altered to cover the regression.