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

[clang] __has_unique_object_representations gives inconsistent answer based on instantiation order #95311

Closed
ldionne opened this issue Jun 12, 2024 · 1 comment · Fixed by #95432
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@ldionne
Copy link
Member

ldionne commented Jun 12, 2024

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 __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

@ldionne ldionne added the clang Clang issues not falling into any other category label Jun 12, 2024
ldionne added a commit to ldionne/llvm-project that referenced this issue Jun 12, 2024
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.
@EugeneZelenko EugeneZelenko added clang:frontend Language frontend issues, e.g. anything involving "Sema" and removed clang Clang issues not falling into any other category labels Jun 12, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Jun 12, 2024

@llvm/issue-subscribers-clang-frontend

Author: Louis Dionne (ldionne)

The following code reports inconsistent results for `__has_unique_object_representations`:
template &lt;int&gt;
class Foo {
  int x;
};

static_assert(__has_unique_object_representations(Foo&lt;0&gt;[]));
static_assert(__has_unique_object_representations(Foo&lt;0&gt;[][3]));
static_assert(__has_unique_object_representations(Foo&lt;0&gt;));

The key here is that if you assert __has_unique_object_representations(Foo&lt;0&gt;) first, then everything works. So somehow asking for __has_unique_object_representations(Foo&lt;0&gt;) must cause something to be instantiated or stored in the AST and that changes the result of a subsequent __has_unique_object_representations(Foo&lt;0&gt;[]) query (notice the array).

This bug was extracted from this comment: #69241 (comment)

Godbolt: https://gcc.godbolt.org/z/Pb9ze7YxM

ldionne added a commit to ldionne/llvm-project that referenced this issue Jun 17, 2024
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.
ldionne added a commit that referenced this issue Jun 20, 2024
…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.
AlexisPerry pushed a commit to llvm-project-tlp/llvm-project that referenced this issue Jul 9, 2024
…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.
sgundapa pushed a commit to sgundapa/upstream_effort that referenced this issue Jul 23, 2024
…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]>
yuxuanchen1997 pushed a commit that referenced this issue Jul 25, 2024
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
3 participants