-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Update 'inactive_override_cache' key #2772
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -82,10 +82,16 @@ struct type_equal_to { | |
template <typename value_type> | ||
using type_map = std::unordered_map<std::type_index, value_type, type_hash, type_equal_to>; | ||
|
||
// Adapted from boost::hash_combine(). See also: | ||
// https://stackoverflow.com/a/27952689/7829525. | ||
inline void hash_combine(size_t& lhs, size_t rhs ) { | ||
lhs ^= rhs + 0x9e3779b9 + (lhs << 6) + (lhs >> 2); | ||
} | ||
|
||
struct override_hash { | ||
inline size_t operator()(const std::pair<const PyObject *, const char *>& v) const { | ||
inline size_t operator()(const std::pair<const PyObject *, std::string>& v) const { | ||
size_t value = std::hash<const void *>()(v.first); | ||
value ^= std::hash<const void *>()(v.second) + 0x9e3779b9 + (value<<6) + (value>>2); | ||
hash_combine(value, std::hash<std::string>()(v.second)); | ||
return value; | ||
} | ||
}; | ||
Comment on lines
+85
to
97
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, this at least doesn't regress the hash like #2092 does. However this is still not what Boost's size_t seed = 0;
size_t lhs = std::hash<const void*>()(v.first); // Same as here
size_t rhs = std::hash<std::string>()(v.second); // Same as here
seed ^= lhs + 0x9e3779b9 + (seed << 6) + (seed >> 2); // This line is missing!
seed ^= rhs + 0x9e3779b9 + (seed << 6) + (seed >> 2); Right now, instead of the first Full disclaimer, I do not claim to be an expert on good hashing functions. I'm just noticing the slight difference. I don't actually know if this should be addressed. I would however trust Boost's implementation on the grounds of " |
||
|
@@ -97,7 +103,7 @@ struct internals { | |
type_map<type_info *> registered_types_cpp; // std::type_index -> pybind11's type information | ||
std::unordered_map<PyTypeObject *, std::vector<type_info *>> registered_types_py; // PyTypeObject* -> base type_info(s) | ||
std::unordered_multimap<const void *, instance*> registered_instances; // void * -> instance* | ||
std::unordered_set<std::pair<const PyObject *, const char *>, override_hash> inactive_override_cache; | ||
std::unordered_set<std::pair<const PyObject *, std::string>, override_hash> inactive_override_cache; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Er... mayhaps this change requires a bump on the internal version. I can't think of an easy to way to keep There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Definitely needs to bump that, yes :-/ That does complicate things slightly, release-wise? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ouch, not going to do that until the next release, at least. We should bundle all such changes together and then do a bump, I think. Also, I thought standard library templated classes were not valid in an ABI (@jpivarski)? I take it this is why we have so many issues with the ABI? Could we redesign this to just be simple classes and do our own memory management here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I think that could be done! I'll check out Boris's suggestion in Betsy's original PR, tho, and see if that gives us From Boris:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Dern, looking at #2520, it's There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TLDR: for now, if we can keep the ABI the same, that's best. Eventually we will need a bump. In the future, maybe we can design internals that work cross-compiler? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I see. Cool, I'll re-open and re-scope #2773 to capture this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I made an "abi break" - very-brighly colored - label ( abi break ). Let's use this to indicate PRs that break the ABI and should be pooled together? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @henryiii Agreed that it would be amazing if we can get rid of these and use something that's basically shared between all compilers (guess that's POD types and There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The current workaround is fine, but something we'd like to possibly redesign to enable wider compatibility in the future, perhaps. In the current design, std::string should be fine, I think it's not worse than unordered map or anything else. I know std::vector is not allowed, so guessing pretty much everything else is out. Somewhere I think @bstaletic just listed the options, which I think is what I was thinking; either we do everything ourselves, or we pay a cost. (Though I feel like we can probably do pretty well). But also haven't really looked at this part of the code much at all, mostly pretty general observations ATM. |
||
type_map<std::vector<bool (*)(PyObject *, void *&)>> direct_conversions; | ||
std::unordered_map<const PyObject *, std::vector<PyObject *>> patients; | ||
std::forward_list<void (*) (std::exception_ptr)> registered_exception_translators; | ||
|
@@ -150,7 +156,7 @@ struct type_info { | |
}; | ||
|
||
/// Tracks the `internals` and `type_info` ABI version independent of the main library version | ||
#define PYBIND11_INTERNALS_VERSION 4 | ||
#define PYBIND11_INTERNALS_VERSION 5 | ||
|
||
/// On MSVC, debug and release builds are not ABI-compatible! | ||
#if defined(_MSC_VER) && defined(_DEBUG) | ||
|
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.
Note: the change to this hash is probably also breaking ABI?