-
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
Correct class names for KeysView, ValuesView and ItemsView in bind_map #4353
Conversation
I glanced through: this looks great at first sight but isn't easy to review for me (I don't know much about this code). @bmerry is there a chance that you could help reviewing this code? I ran this with ASAN, MSAN, UBSAN using the Google toolchain: everything passes. I spot-checked the CI failures. It looks like a C++11 and C++14 incompatibility, a
With C++11 and C++14 this can only be used as a Please tag me here if you need a button click to trigger the CI. |
Thanks! I see I've still got quite a lot of issues, so I moved this to to be a draft for a while. My last commits should hopefully resolve most of the issues, except for:
|
It's gone :-) The only one CI failure is definitely unrelated. (PGI key signing issue) |
I'm not sure what's with that failing check on But assuming this is just a random failiure, I think this is ready to be merged, isn't it? |
Yes, that's just one of the annoying flakes we have. Do you know someone with a good background to review this PR? |
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.
After you make this change, and pending completion of updating the smart_holder branch (hopefully very soon), I will run this through Google-internal global testing, which includes testing with a large number of 3rd-party (OSS) projects.
@rwgk Did you happen to run the Google-internal tests? I can't really think of anything else to do, and if those pass it would probably be a pretty strong indication that things work as expected. |
I tried last night but it was too early after the smart_holder update (there is a few hours lag for the batched global testing that I was trying to use). I tried again just now and it accepted the job. It will probably take 6+ hours to finish. I did run the pybind11 unit tests with all sanitizers interactively and that passed. |
Do we have any testing for PyBInd11 without RTTI. I know that was supported before this PR, but I am wondering if the virtual methods will break it. |
I don't really see how any of the current code would work without RTTI. There's already
pybind11/include/pybind11/detail/typeid.h Line 62 in e133c33
Perhaps I misunderstand? I just tried to compile with Edit: see also #526, I think the discussion there implies that pybind11 without RTTI is not supported ever since d7efa4f |
I systematically looked at all files that mention "rtti" (case-insensitive):
I don't see any mention of pybind11 working without RTTI. Then I did a small quick experiment, creating this file:
Then:
Succeeds without error.
See output below. Thinking about it, it occurred to me maybe pytypes.h could work without RTTI, so I tried that, too:
Succeeds without error.
|
The global testing passed. But I need to find a little bit of time to better understand what this PR is doing. |
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.
The approach with the virtual functions looks really smart to me, and economical.
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.
Very nice!
I'm working on getting our CI healthy again under PR #4382. I already confirmed that the sledge-hammer method of globally changing ubuntu-latest
to ubuntu-20.04
works. I'm still working on more targeted (limited) changes. My thinking: let's get that settled & merged first (hopefully today), then rebase this PR to confirm that we're all green again here, too.
All done & green now! |
Amazing! So is it ready to merge? 😄 |
@Skylion007 could you please comment or approve? |
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.
Looks good to me.
include/pybind11/stl_bind.h
Outdated
if (it == map.end()) { | ||
return false; | ||
} | ||
return true; |
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.
if (it == map.end()) { | |
return false; | |
} | |
return true; | |
return it != map.end(); |
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.
Applied with commit 4525c5d
After that it was staring me in the face that map.find(k) != map.end()
is even better.
And then clang-format turned the entire function into a one-liner.
… and implement them on-the-fly when wrapping any specific map type
…and const double, for example, as both wrappers will be named ValuesView[float]
…ypes for similarly-typed maps
…ght have different types
…ing the 'override' keyword when overriding functions
…he struct being defined inside a module, which was also needlessly ugly anyway
…ness they are specified to be static
…ues - I personally think this looks uglier, but it's probably worth it for clang-tidy to be happy
…c constexpr to make sure they are known before linking
Co-authored-by: Aaron Gokaslan <[email protected]>
…ames + stricter asserts
Similar to #2768, I went ahead with a rebase & applying the review suggestions, to get this into the next smart_holder update. Waiting for the CI. |
pybind#4353) * Create templated abstract classes KeysView, ValuesView and ItemsView, and implement them on-the-fly when wrapping any specific map type * We don't want to wrap different ValuesView objects for double values and const double, for example, as both wrappers will be named ValuesView[float] * Fallback to C++ names if key or values types are not wrapped * Added a test for .keys(), .values() and .items() returning the same types for similarly-typed maps * Fixed wrong use of auto in a declarator list: the two descriptions might have different types * Fixes for clang-tidy issues: explicit single-argument constructor, using the 'override' keyword when overriding functions * Bugfix for old versions of clang++, which seem to have trouble with the struct being defined inside a module, which was also needlessly ugly anyway * Bugfix for clang++, which doesn't have some of the names in runtime uness they are specified to be static * A fix for clang-tidy performance-inefficient-string-concatenation issues - I personally think this looks uglier, but it's probably worth it for clang-tidy to be happy * Possible fix for clang++ linking issues - make the descriptions static constexpr to make sure they are known before linking * Correct names for previously-wrapped types as keys/values of maps * Bugfix - typo in type info names which caused things to segfault * Apply suggestions from code review Co-authored-by: Aaron Gokaslan <[email protected]> * Use detail::remove_cvref_t instead of doing remove_cv and remove_reference separately * Avoid names with double underscore, as they are reserved * Improved testing for KeysView, ValuesView and ItemsView: check type names + stricter asserts * Moved description logic to helper function in type_caster_base.h * style: pre-commit fixes * Fix a clang-tidy issue: do not use 'else' after 'return' * Apply suggestion by @Skylion007, with additional trivial simplification. Co-authored-by: Amir <aimir@local> Co-authored-by: aimir <aimir@localhost> Co-authored-by: Aaron Gokaslan <[email protected]> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Ralf W. Grosse-Kunstleve <[email protected]>
Description
Wrap KeysView, ValuesView and ItemsView with correct typing information in mappings wrapped via bind_map.
For example, for a mapping from strings to doubles, its
.keys()
function should have return typeKeysView[str]
.Currently, things have been wrapped like
KeysView[MappingWrapperName]
, which is both misleading and inconsistent with the parallel python classes (especially for ItemsView, which usually has two type arguments, but here has only one).This also means that we get differently-typed
KeysView
objects for different mappings with the same key type, even though they are functionally identical types.This is solved by making
KeysView
etc. an abstract class that's a template on the relevant types only, rather than the entire map, so that maps with similar keys will haveKeysView
with the same type. The actual implementation is provided later, when wrapping the.keys()
function of the mapping class, and similarly for values and items.Closes #3986.
Suggested changelog entry: