Skip to content
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

Differing behavior of std::type_index hash and equality from libc++ and libstdc++ #61848

Closed
Skylion007 opened this issue Mar 30, 2023 · 3 comments
Labels
duplicate Resolved as duplicate libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.

Comments

@Skylion007
Copy link

Skylion007 commented Mar 30, 2023

Full background can be found on the linked discussion pybind/pybind11#4319 (comment) Essentially the behavior of std::type_index is different between the two standard libraries. This behavior seems like a bug in LLVM's implementation and requires us to be careful whenever storing std::type_index in a hashmap when using libc++;

@EugeneZelenko EugeneZelenko added libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. and removed new issue labels Mar 30, 2023
@VoltrexKeyva VoltrexKeyva changed the title Differing behavior of std::type_index hash and equality from libc++ and libstdc+++ Differing behavior of std::type_index hash and equality from libc++ and libstdc++ Mar 30, 2023
@frederick-vs-ja
Copy link
Contributor

frederick-vs-ja commented Apr 3, 2023

Why is this considered a bug rather than a permissible implemenation divergence?

I think it's intended that libc++'s type_info can be ABI-compatible with other implemenations, but I'm not sure whether it's a goal for libc++'s type_info::hash_code to have the same results as others.


Oh, libc++'s type_info doesn't seem to handle the leading '*' in the mangled name, which is probably the bug.

@frederick-vs-ja
Copy link
Contributor

Is this a duplicate of #59790? #34255 is possibly related.

@philnik777
Copy link
Contributor

Closing for now, since we can't fix it until Clang is fixed, and it's a duplicate (of a clang bug).

@philnik777 philnik777 closed this as not planned Won't fix, can't repro, duplicate, stale Apr 7, 2023
@philnik777 philnik777 added the duplicate Resolved as duplicate label Apr 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate Resolved as duplicate libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.
Projects
None yet
Development

No branches or pull requests

4 participants