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.

Sign up for GitHub

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

Jump to bottom

Decltype of external struct’s member, used in templated class, fails to resolve #58674

Open
mikmorg opened this issue Oct 28, 2022 · 1 comment
Open

Decltype of external struct’s member, used in templated class, fails to resolve #58674

mikmorg opened this issue Oct 28, 2022 · 1 comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@mikmorg
Copy link

mikmorg commented Oct 28, 2022 •
edited by VoltrexKeyva
Loading

Initial discussion here: https://discourse.llvm.org/t/decltype-of-external-structs-member-used-in-templated-class-fails-to-resolve/66216/1

When I use decltype(Foo::value_) from a method in a templated class, inheriting from a templated base class, decltype fails with "… is not a member of 'this' class".

https://gcc.godbolt.org/z/xPrvEax48

struct Foo {
    float value_;
};

float bar;

template <typename T>
struct Animal{};

template <typename T=void>
class Cat : public Animal<T> {
public:
    using value_type_ok = decltype(::Foo::value_);

    void meow() {
        using value_type_fails = decltype(::Foo::value_);

        using value_type_also_ok = decltype(::bar);
    }
};

int main() {
    Cat<>{}.meow();
}
<source>:16:50: error: 'Foo::value_' is not a member of class 'Cat<>'
        using value_type_fails = decltype(::Foo::value_);
                                          ~~~~~~~^
<source>:23:13: note: in instantiation of member function 'Cat<>::meow' requested here
    Cat<>{}.meow();

@AaronBallman states -

[dcl.type.decltype]p1 basically says that we do the lookup of the qualified id and the resulting type is the type of what we find. There’s nothing special about doing the lookup from within a member function. So we should be able to find that member. And we do find that member if Cat is not a template type or (even more oddly) if Cat does not inherit from anything, so something is definitely wonky here.
The code is accepted by GCC, MSVC, and ICC, which also suggests we’re in the wrong.
@EugeneZelenko EugeneZelenko added clang:frontend Language frontend issues, e.g. anything involving "Sema" and removed new issue labels Oct 28, 2022
@llvmbot
Copy link
Member

llvmbot commented Oct 28, 2022

@llvm/issue-subscribers-clang-frontend

erichkeane pushed a commit that referenced this issue Jan 4, 2023
@limingliv
[clang] Add the check of membership in decltype for the issue #58674#
8596004 
Originally, the code would take a lookup result as a member in the
current scope and build a member expression accordingly, if the lookup
result was not an operand of the address operator, or it was a field
declaration. However, a field declaration may come from another class,
and cause the issue #58674.

Thus, this patch fixes the issue via checking where does the field
declaration comes from, and if it comes from another class, then marks
it as not member in the current scope. The parent scopes of the current
scope are also checked, as the current scope may be associated to a
lambda or friend declaration.

Differential Revision: https://reviews.llvm.org/D137531
erichkeane pushed a commit that referenced this issue Jan 4, 2023
Revert "[clang] Add the check of membership in decltype for the issue #…
3ba051b 
…58674#"

This reverts commit 8596004.

The powerpc64le self-built buildbot had an assertion during self-build,
that seems like it is possibly related here, reverting so the author can
take a look.
limingliv added a commit that referenced this issue Jan 29, 2023
@limingliv
[clang] Add the check of membership in decltype for the issue #58674
01adf96 
D137531 had once fixed the issue. However, it caused a crash during compiling
llvm/unittests/IR/PatternMatch.cpp in stage-2. The reason is the predicator
isDerivedFrom does not consider independent types if the derived type is
dependent.

This patch improves D137531 by adding an option to make isDerivedFrom consider
independent types.

Differential Revision: https://reviews.llvm.org/D142437
limingliv added a commit that referenced this issue Feb 22, 2023
@limingliv
[clang] Add the check of membership for the issue #58674 and improve …
8498ba6 
…the lookup process

This patch includes the commit 01adf96 and a fix of unhandled declaration
references.

When looking up base classes, Clang first checks whether a base class is a
template and takes the specialized template based on it. However, the base class
might be instantiated, and the above behavior can lose information.

This patch fixes the problem by first checking whether a base class is a record
declaration, so the instantiated one will be taken.

Differential Revision: https://reviews.llvm.org/D143840
alexfh added a commit that referenced this issue Feb 23, 2023
@alexfh
Revert "[clang] Add the check of membership for the issue #58674 and …
1812e13 
…improve the lookup process"

The commit causes clang to crash. See https://reviews.llvm.org/D143840#4147234

This reverts commit 8498ba6.
limingliv added a commit that referenced this issue Mar 13, 2023
@limingliv
[clang] Replace Member Expressions During Instantiation If Necessary
3951c28 
This patch replaces member accesses to declaration references during template
instantiation if the context is the unevaluated context and the class does not
contain the declaration.

The replacement fixes the issue #58674. Unlike previous fixes such as D143840,
it checks the membership during instantiation rather than right after parsing,
so the check is more accurate and efficient.

This patch also includes cases that previous fixes had once failed on.

Differential Revision: https://reviews.llvm.org/D145491
eymay pushed a commit to eymay/llvm-project that referenced this issue Mar 21, 2023
@limingliv @eymay
[clang] Replace Member Expressions During Instantiation If Necessary
7afb09e 
This patch replaces member accesses to declaration references during template
instantiation if the context is the unevaluated context and the class does not
contain the declaration.

The replacement fixes the issue llvm#58674. Unlike previous fixes such as D143840,
it checks the membership during instantiation rather than right after parsing,
so the check is more accurate and efficient.

This patch also includes cases that previous fixes had once failed on.

Differential Revision: https://reviews.llvm.org/D145491
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mikmorg @EugeneZelenko @llvmbot