-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
[clang] __has_unique_object_representations gives inconsistent answer based on instantiation order #95311
Comments
Clang currently has a bug in the __has_unique_object_representations builtin where it doesn't provide consistent answers based on the order of instantiation of templates. This was reported as llvm#95311. This patch adds a workaround in libc++ to avoid breaking users until Clang has been fixed. It also revamps the tests a bit.
@llvm/issue-subscribers-clang-frontend Author: Louis Dionne (ldionne)
The following code reports inconsistent results for `__has_unique_object_representations`:
template <int>
class Foo {
int x;
};
static_assert(__has_unique_object_representations(Foo<0>[]));
static_assert(__has_unique_object_representations(Foo<0>[][3]));
static_assert(__has_unique_object_representations(Foo<0>)); The key here is that if you assert This bug was extracted from this comment: #69241 (comment) Godbolt: https://gcc.godbolt.org/z/Pb9ze7YxM |
Clang currently has a bug in the __has_unique_object_representations builtin where it doesn't provide consistent answers based on the order of instantiation of templates. This was reported as llvm#95311. This patch adds a workaround in libc++ to avoid breaking users until Clang has been fixed. It also revamps the tests a bit.
…95314) Clang currently has a bug in the __has_unique_object_representations builtin where it doesn't provide consistent answers based on the order of instantiation of templates. This was reported as #95311. This patch adds a workaround in libc++ to avoid breaking users until Clang has been fixed. It also revamps the tests a bit.
…lvm#95314) Clang currently has a bug in the __has_unique_object_representations builtin where it doesn't provide consistent answers based on the order of instantiation of templates. This was reported as llvm#95311. This patch adds a workaround in libc++ to avoid breaking users until Clang has been fixed. It also revamps the tests a bit.
…ions` to be complete (llvm#95432) Fixes llvm#95311 Previous behaviour was that `false` was silently returned, templated classes were not instantiated and incomplete classes did not issue an error. --------- Co-authored-by: cor3ntin <[email protected]>
…ions` to be complete (#95432) Summary: Fixes #95311 Previous behaviour was that `false` was silently returned, templated classes were not instantiated and incomplete classes did not issue an error. --------- Co-authored-by: cor3ntin <[email protected]> Test Plan: Reviewers: Subscribers: Tasks: Tags: Differential Revision: https://phabricator.intern.facebook.com/D60250880
The following code reports inconsistent results for
__has_unique_object_representations
:The key here is that if you assert
__has_unique_object_representations(Foo<0>)
first, then everything works. So somehow asking for__has_unique_object_representations(Foo<0>)
must cause something to be instantiated or stored in the AST and that changes the result of a subsequent__has_unique_object_representations(Foo<0>[])
query (notice the array).This bug was extracted from this comment: #69241 (comment)
Godbolt: https://gcc.godbolt.org/z/Pb9ze7YxM
The text was updated successfully, but these errors were encountered: