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

non-dependent name treated as if it were dependent, requiring use of template keyword #37647

Closed
llvmbot opened this issue Jul 25, 2018 · 5 comments
Labels
bugzilla Issues migrated from bugzilla c++ duplicate Resolved as duplicate

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Jul 25, 2018

Bugzilla Link 38299
Resolution DUPLICATE
Resolved on Aug 16, 2018 07:52
Version trunk
OS Linux
Reporter LLVM Bugzilla Contributor
CC @dwblaikie,@DougGregor,@zygoloid,@steveire

Extended Description

This example fails to compile on the marked line, but nothing here is dependent.

struct X {
template
void foo();
};

struct Base {
X get();
};

template
struct Derived : Base
{
void foo() {
auto result = Base::get();
result.foo(); // (*)
}
};

template struct Derived;

The error message is:

error: use 'template' keyword to treat 'foo' as a dependent template name
result.foo(); // (*)
^
template
1 error generated.

BTW, g++ accepts the code.

@dwblaikie
Copy link
Collaborator

*** Bug #37644 has been marked as a duplicate of this bug. ***

@dwblaikie
Copy link
Collaborator

Reduced this a little further:

struct foo {
template void f1();
};
template struct bar {
foo f2();
void f1() {
f2().f1();
}
};
template struct bar;

You can assign the result of f2() to a local, so long as the type is written as 'auto' and not 'foo' the behavior is still the same - the f1 call is considered dependent and needs the 'template' keyword when it seems like it shouldn't?

Maybe this test case is less convincing than the original - the original, using a (non-templated/non-depnedent) base class to contain 'f2' maybe makes it clearer that 'f2' is not dependent, whereas I guess the call to f2 could be dependent in some sense? Not sure.

@zygoloid
Copy link
Mannequin

zygoloid mannequin commented Jul 25, 2018

FWIW, there's a FIXME in include/clang/AST/Redeclarable.h where we're working around this bug in Clang's own source code.

@steveire
Copy link
Collaborator

I hit exactly this issue too.

https://bugs.llvm.org//show_bug.cgi?id=17401 also exists, but it doesn't seem to be an exact duplicate as it does not use inheritance in the repro.

*** This bug has been marked as a duplicate of bug #17775 ***

@steveire
Copy link
Collaborator

Another maybe-interesting datapoint - CL.exe 19.14.26430 (ie Visual Studio 15.7 I think) with /permissive- rejected code with the incorrect template keyword.

CL.exe 19.15.26726 (Visual Studio 15.8) with /permissive- accepts it and ignores the extra template keyword.

Presumably customers added the keyword to fix their clang build, and when VC++ permissive mode rejected it, customers complained and the change was backed out.

I hit this issue in FBX SDK headers.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
shafik added a commit to shafik/llvm-project that referenced this issue Nov 6, 2023
As noted in this bug report: llvm#37647

Due to this clang bug we added the template keyword in Redeclarable.h. The bug
has been fixed since then, so removing it.
shafik added a commit that referenced this issue Nov 7, 2023
As noted in this bug report:
#37647

Due to this clang bug we added the template keyword in Redeclarable.h.
The bug has been fixed since then, so removing it.
qihangkong pushed a commit to rvgpu/llvm that referenced this issue Apr 18, 2024
As noted in this bug report:
llvm/llvm-project#37647

Due to this clang bug we added the template keyword in Redeclarable.h.
The bug has been fixed since then, so removing it.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c++ duplicate Resolved as duplicate
Projects
None yet
Development

No branches or pull requests

3 participants