-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Fix caster optimization regression introduced in #3650 #3659
Conversation
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.
Your explanation sounds like it captures the subtlety that I wasn't sure I had completely understood.
Can you update the documentation for the simple_type
and simple_ancestors
? Having it in this PR is ok, but they're really sparse on detail so making them a bit more clear would be good IMO.
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.
Makes sense to me, although I cannot claim that I have a full grasp of all subtleties.
Tagging @jagerman in hopes that he can confirm or correct.
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.
LGTM
Description
So I thought about this some more, and I realized the difference between simple type and simple ancestors in the caster. A non-simple type is any ancestor who has any descendants who have multi-inheritance from C++ classes. The descendant itself is a simple type though, unless it also has descendants. This PR fixes a mistake made in #3650 where the descendants themselves can remain simple types until they are extended. Marking a type as non-simple adds some additional pointer checks in the casters and while this is an edge case, we should be careful not to undo the optimization here.
Ping @virtuald
TLDR: Figured out what the difference is between simple_type and simple_ancestors.
In otherwise,
!simple_ancestors => !simple_type
only if it has PyBind11 descendants.I figured this out by thinking about why the rec.multiple_inheritance pathway didn't cause issues before as long multiple_inheritance was specified. The difference being that the single base pathway failed to update the type of the parent to non-simple.
Suggested changelog entry:
(just a reminder to include both PR numbers)