Reapply "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)" (#90

Reapply "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)" (#90152)

Reapplies #84050, addressing a bug which cases a crash when an
expression with the type of the current instantiation is used as the
_postfix-expression_ in a class member access expression (arrow form).

show more ...

Revert "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)"

This

Revert "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)"

This reverts commit a8fd0d029dca7d17eee72d0445223c2fe1ee7758.

show more ...

[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)

Consider the

[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)

Consider the following:
```cpp
template<typename T>
struct A
{
auto f()
{
return this->x;
}
};
```
Although `A` has no dependent base classes and the lookup context for
`x` is the current instantiation, we currently do not diagnose the
absence of a member `x` until `A<T>::f` is instantiated. This patch
moves the point of diagnosis for such expressions to occur at the point
of definition (i.e. prior to instantiation).

show more ...

Print nested name specifiers for typedefs and type aliases

Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other

Print nested name specifiers for typedefs and type aliases

Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other types that always
yield the full typename including namespaces.

Patch by Michael Reiher!

Differential Revision: https://reviews.llvm.org/D29944

llvm-svn: 297465

show more ...

PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).

Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circu

PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).

Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).

As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).

When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.

llvm-svn: 292518

show more ...

[libclang] Make token annotation of type/storage qualifiers accurate.

Previously type/storage qualifiers would not be annotated as the declaration they belonged to.
Just use the resulting source ran

[libclang] Make token annotation of type/storage qualifiers accurate.

Previously type/storage qualifiers would not be annotated as the declaration they belonged to.
Just use the resulting source range of getRawCursorExtent() which is more correct
than what AnnotateTokensWorker::Visit() was adjusting it to.

llvm-svn: 171774

show more ...

Expose more statement, expression, and declaration kinds in libclang,
from Manuel Holtgrewe!

llvm-svn: 141200

Enable -fdelayed-template-parsing by default on Win32.
I had to force -fno-delayed-template-parsing on some Index tests because delayed template parsing will change the output of some tests.

llvm-sv

Enable -fdelayed-template-parsing by default on Win32.
I had to force -fno-delayed-template-parsing on some Index tests because delayed template parsing will change the output of some tests.

llvm-svn: 138942

show more ...

Based on the new information in the AST provided by r130628, write
3 lines of code and improve a bunch of information in the libclang view
of the code.

Updates the two tests that exercise this with

Based on the new information in the AST provided by r130628, write
3 lines of code and improve a bunch of information in the libclang view
of the code.

Updates the two tests that exercise this with the new data, checking
that each new source location actually points back to the declared
template parameter.

llvm-svn: 130656

show more ...

Use ElaboratedType also for C.

llvm-svn: 127755

Finish updated test

llvm-svn: 126948

Eliminate redundant nested-name-specifiers on
TemplateSpecializationTypes, which also fixes PR9388.

llvm-svn: 126946

Fix the source range for a member access expression that includes a
nested-name-specifier and improve the detection of implicit 'this'
bases. Fixes <rdar://problem/8750392>.

llvm-svn: 126880

Teach libclang how to visit the children of a C++ base-class specifier
(i.e., the TypeLoc describing the base class type).

llvm-svn: 126861

Push nested-name-specifier source location information into template
template arguments. I believe that this is the last place in the AST
where we were storing a source range for a nested-name-specif

Push nested-name-specifier source location information into template
template arguments. I believe that this is the last place in the AST
where we were storing a source range for a nested-name-specifier
rather than a proper nested-name-specifier location structure. (Yay!)

There is still a lot of cleanup to do in the TreeTransform, which
doesn't take advantage of nested-name-specifiers with source-location
information everywhere it could.

llvm-svn: 126844

show more ...

Push nested-name-specifier source-location information into dependent
template specialization types. This also required some parser tweaks,
since we were losing track of the nested-name-specifier's s

Push nested-name-specifier source-location information into dependent
template specialization types. This also required some parser tweaks,
since we were losing track of the nested-name-specifier's source
location information in several places in the parser. Other notable
changes this required:

- Sema::ActOnTagTemplateIdType now type-checks and forms the
appropriate type nodes (+ source-location information) for an
elaborated-type-specifier ending in a template-id. Previously, we
used a combination of ActOnTemplateIdType and
ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped
around a DependentTemplateSpecializationType, which duplicated the
keyword ("class", "struct", etc.) and nested-name-specifier
storage.

- Sema::ActOnTemplateIdType now gets a nested-name-specifier, which
it places into the returned type-source location information.

- Sema::ActOnDependentTag now creates types with source-location
information.

llvm-svn: 126808

show more ...

Push nested-name-specifier source-location information into dependent
template specialization types. There are still a few rough edges to
clean up with some of the parser actions dropping
nested-name

Push nested-name-specifier source-location information into dependent
template specialization types. There are still a few rough edges to
clean up with some of the parser actions dropping
nested-name-specifiers too early.

llvm-svn: 126776

show more ...

Reinstate the introduction of source-location information for
nested-name-speciciers within elaborated type names, e.g.,

enum clang::NestedNameSpecifier::SpecifierKind

Fixes in this iteration in

Reinstate the introduction of source-location information for
nested-name-speciciers within elaborated type names, e.g.,

enum clang::NestedNameSpecifier::SpecifierKind

Fixes in this iteration include:

(1) Compute the type-source range properly for a dependent template
specialization type that starts with "template template-id ::", as
in a member access expression

dep->template f<T>::f()

This is a latent bug I triggered with this change (because now we're
checking the computed source ranges for dependent template
specialization types). But the real problem was...

(2) Make sure to set the qualifier range on a dependent template
specialization type appropriately. This will go away once we push
nested-name-specifier locations into dependent template
specialization types, but it was the source of the
valgrind errors on the buildbots.


llvm-svn: 126765

show more ...

Revert r126748, my second attempt at nested-name-specifier source
location information for elaborated types. *sigh*

llvm-svn: 126753

Reinstate r126737, extending the generation of type-source location
information for qualifier type names throughout the parser to address
several problems.

The commit message from r126737:

Push nes

Reinstate r126737, extending the generation of type-source location
information for qualifier type names throughout the parser to address
several problems.

The commit message from r126737:

Push nested-name-specifier source location information into elaborated
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".

Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.

With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.

llvm-svn: 126748

show more ...

Revert r126737, the most recent nested-name-specifier location change, for buildbot breakage.

llvm-svn: 126746

Push nested-name-specifier source location information into elaborated
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".

Aside from the normal changes, this also required some twea

Push nested-name-specifier source location information into elaborated
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".

Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.

With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.

llvm-svn: 126737

show more ...

Push nested-name-specifier source location information into
DependentNameTypeLoc. Teach the recursive AST visitor and libclang how to
walk DependentNameTypeLoc nodes.

Also, teach libclang about Type

Push nested-name-specifier source location information into
DependentNameTypeLoc. Teach the recursive AST visitor and libclang how to
walk DependentNameTypeLoc nodes.

Also, teach libclang about TypedefDecl source ranges, so that we get
those. The massive churn in test/Index/recursive-cxx-member-calls.cpp
is a good thing: we're annotating a lot more of this test correctly
now.

llvm-svn: 126729

show more ...

Push nested-name-specifier location information into DeclRefExpr and
MemberExpr, the last of the expressions with qualifiers!

llvm-svn: 126688

Push nested-name-specifier source location information into
UnresolvedLookupExpr and UnresolvedMemberExpr.

Also, improve the computation that checks whether the base of a member
expression (either u

Push nested-name-specifier source location information into
UnresolvedLookupExpr and UnresolvedMemberExpr.

Also, improve the computation that checks whether the base of a member
expression (either unresolved or dependent-scoped) is implicit. The
previous check didn't cover all of the cases we use in our
representation, which threw off source-location information for these
expressions (which, in turn, caused some breakage in libclang's token
annotation).

llvm-svn: 126681

show more ...