Previously, any undeclared unqualified id starting a nested name
specifier in a dependent context would have its lookup retried during
template instantiation. Now we limit that retry hack to methods of a
class with dependent bases. Free function templates in particular are
no longer affected by this hack.
Also, diagnose this as a Microsoft extension. This has the downside that
template authors may see this warning *and* an error during
instantiation time about this identifier. Fixing that will probably
require formalizing some kind of "delayed" identifier, instead of our
ad-hoc solutions of forming dependent AST nodes when lookup fails.
Based on a patch by Kim Gräsman!
Differential Revision: http://reviews.llvm.org/D4854
llvm-svn: 215683
If we want to resolve the remaining FIXMEs here, we probably want to
extend the main lookup mechanism to perform lookup into dependent bases,
but we would have to tread lightly. Adding more name lookup has major
impact on compile time.
If we did extend the main mechanism, we would add a flag to LookupResult
that allows us to find names from dependent base classes where the base
is a specialization of a known template. The final LookupResult would
still return LookupResult::NotFoundInCurrentInstantiation, but it would
have a collection of Decls. If we find a real lookup result, we would
clear the flag and the existing lookup results and begin accumulating
only real lookup results.
We would structure the lookup as a secondary lookup between normal
lookup and typo correction for normal compilation, but for MSVC
compatibility mode, we would always enable this extra lookup into
dependent bases.
llvm-svn: 212566
MSVC appears to perform name lookup into dependent base classes when the
dependent base class has a known primary template. This allows them to
know whether some unqualified ids are types or not, which allows them to
parse more class templates without typename keywords.
We can do the same thing when type name lookup fails, and if we find a
single type decl in one of our dependent base classes, recover as though
the user wrote 'typename MyClass::TypeFromBase'.
This allows us to parse some COM smart pointer classes in wrl/client.h
from the Windows 8 SDK.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D4237
llvm-svn: 212561
We currently allow unqualified lookup for instance methods but not
static methods because we can't recover with a semantic 'this->'
insertion.
ATL headers have static methods that do unqualified lookup into
dependent base classes. The pattern looks like:
template <typename T> struct Foo : T {
static int *getBarFromT() { return Bar; }
};
Now we recover as if the user had written:
template <typename T> struct Foo : T {
static int *getBarFromT() { return Foo::Bar; }
};
... which will eventually look up Bar in T at instantiation time.
Now we emit a diagnostic in both cases, and delay lookup in other
contexts where 'this' is available and refers to a class with dependent
bases.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4079
llvm-svn: 210611
This patch was submitted to the list for review and didn't receive a LGTM.
(In fact one explicit objection and one query were raised.)
This reverts commit r197295.
llvm-svn: 197299
Previously, a line like
// expected-error-re {{foo}}
treats the entirety of foo as a regex. This is inconvenient when matching type
names containing regex characters. For example, to match
"void *(class test8::A::*)(void)" inside such a regex, one would have to type
"void \*\(class test8::A::\*\)\(void\)".
This patch changes the semantics of expected-error-re to only treat the parts
of the directive wrapped in double curly braces as regexes. This avoids the
escaping problem and leads to nicer patterns for those cases; see e.g. the
change to test/Sema/format-strings-scanf.c.
(The balanced search for closing }} of a directive also makes us handle the
full directive in test\SemaCXX\constexpr-printing.cpp:41 and :53.)
Differential Revision: http://llvm-reviews.chandlerc.com/D2388
llvm-svn: 197092
If unqualified id lookup fails while parsing a class template with a
dependent base, clang with -fms-compatibility will pretend the user
prefixed the name with 'this->' in order to delay the lookup. However,
if there was a unary ampersand, Sema::ActOnDependentIdExpression() will
create a DependentDeclRefExpr, which is not what we wanted at all. Fix
this by building the CXXDependentScopeMemberExpr directly instead.
In order to be fully MSVC compatible, we would have to defer all
attempts at name lookup to instantiation time. However, until we have
real problems with system headers that can't be parsed, we'll put off
implementing that.
Fixes PR16014.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1892
llvm-svn: 192727
a dependent-scope id expression when a templated member function of a
non-templated class references an unknown identifier, since instantiation won't
rebuild it (and we can tell at parse time that it'll never work). Based on a
patch by Faisal Vali!
llvm-svn: 180701
in microsoft mode. Fixes PR12701.
The code for this was already in 2 of the 3 branches of a
conditional and missing in the 3rd branch, so lift it above
the conditional.
llvm-svn: 158842
Basically typo correction will try to offer a correction instead of looking into type dependent base classes.
I found this problem while parsing Microsoft ATL code with clang.
llvm-svn: 145772
Basically we have to look into the parent *lexical* DeclContext for friend functions at class scope. That's because calling GetParent() return the namespace or file DeclContext.
This fixes all remaining cases of "Unqualified lookup into dependent bases of class templates" when parsing MFC code with clang.
llvm-svn: 145127
This is a little bit tricky because during default argument instantiation the CurContext points to a CXXMethodDecl but we can't use the keyword this or have an implicit member call generated.
This fixes 2 errors when parsing MFC code with clang.
llvm-svn: 144881
Nikola Smiljanic