-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Use register_dynamic for merging #18028
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use register_dynamic for merging #18028
Conversation
No migration guide for bug fixes in general :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good test: that clearly demonstrated the problem to me.
@alice-i-cecile The additional cloning during merging was annoying us. I was going to have to fix it anyway for #17871, but since we aren't going in that direction anymore, I went ahead and fixed it here. I added I kept |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's axe register_dynamic
(just have a little migration guide showing the snippet you currently have). It really doesn't seem to add much value here. Once that's done, this LGTM.
Done! Also needs |
Co-authored-by: Joona Aalto <jondolf.dev@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense to me. Nice catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes make sense, looks good!
Co-Authored-By: Joona Aalto <jondolf.dev@gmail.com>
# Objective - Fixes #19863 by removing `inheritance_depth` - Fixed #19333 by properly using depth-first order priority - Helps with #19300 (not sure if it could be closed with this PR) - Fixes #20173 - Overall, fix the weird situation that required components are in, where some operations respect a depth-first order priority while other respect a breadth-first order priority. ## Solution - Switch everything to a depth-first order priority as @cart originally intended it. - Effectively revert #18028, which tried to give priority to components with higher inheritance depth (i.e. with a breadth-first order priority). ## Testing Most existing tests pass, except a couple that were removed due to testing inheritance depth or the breadth-first order priority that this PR will remove. Some tests were also added, some of which as regression tests and others to add more coverage.
…0110) # Objective - Fixes bevyengine#19863 by removing `inheritance_depth` - Fixed bevyengine#19333 by properly using depth-first order priority - Helps with bevyengine#19300 (not sure if it could be closed with this PR) - Fixes bevyengine#20173 - Overall, fix the weird situation that required components are in, where some operations respect a depth-first order priority while other respect a breadth-first order priority. ## Solution - Switch everything to a depth-first order priority as @cart originally intended it. - Effectively revert bevyengine#18028, which tried to give priority to components with higher inheritance depth (i.e. with a breadth-first order priority). ## Testing Most existing tests pass, except a couple that were removed due to testing inheritance depth or the breadth-first order priority that this PR will remove. Some tests were also added, some of which as regression tests and others to add more coverage.
Objective
I found a bug while working on #17871. When required components are registered, ones that are more specific (smaller inheritance depth) are preferred to others. So, if a ComponentA is already required, but it is registered as required again, it will be updated if and only if the new requirement has a smaller inheritance depth (is more specific). However, this logic was not reflected in merging
RequriedComponents
s together. Hence, for complicated requirement trees, the wrong initializer could be used.Solution
Re-write merging to work by extending the collection via
require_dynamic
instead of blindly combining the inner storage.Testing
I created this test to ensure this bug doesn't creep back in. This test fails on main, but passes on this branch.
Note that when the inheritance depth is 0 (Like if there were no middle man above), the order of the components in the bundle still matters.
Migration Guide
RequiredComponents::register_dynamic
has been changed toRequiredComponents::register_dynamic_with
.Old:
New:
This can prevent unnecessary cloning.