Introduce CFGImplicitDtor::isNoReturn() to query whether a destructor actually returns.  Use this for -Wreturn-type to prune false positives reported in PR 6884.

llvm-svn: 126875

llvm-svn: 126857

TreeTransform::TransformDependentTemplateSpecializationType() with
poor source-location information handling. All of the
CXXScopeSpec::MakeTrivial() and
NestedNameSpecifierLocBuilder::MakeTrivial() callers actually make
sense now.

llvm-svn: 126856

them, which are no longer used.

llvm-svn: 126855

Eliminate an unnecessary use of CXXScopeSpec::MakeTrivial. We have proper nested-name-specifier source-location information in DependentTemplateSpecializationTypeLocs now

llvm-svn: 126854

source-location-preserving
TreeTransform::TranformNestedNameSpecifierLoc(). No functionality
change: the victim had no callers (that themselves had callers) anyway.

llvm-svn: 126853

poor source-location information.

llvm-svn: 126852

overloads (the one with the poor source-location information).

llvm-svn: 126851

that preserve source-location information. This commit adds more
redundancy than it removes; WIP.

llvm-svn: 126849

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

llvm-svn: 126841

using a custom plural form.  Split out the range diagnostics as their
own message.

llvm-svn: 126840

of an Objective-C method to be overridden on a case-by-case basis.  This
is a higher-level tool than ns_returns_retained &c.;  it lets users specify
that not only does a method have different retain/release semantics, but
that it semantically acts differently than one might assume from its name.
This in turn is quite useful to static analysis.

llvm-svn: 126839

used for attributes that are okay to inherit when written on a parameter.
Dependent on LLVM r126827.

llvm-svn: 126828

whether C++ exceptions are enabled, not exceptions in general.  PR9358.

llvm-svn: 126820

of an expansion, and we have a paramameter that is not a parameter
pack, don't suppress substitution of parameter packs within this
context.

llvm-svn: 126819

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

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

llvm-svn: 126770

llvm-svn: 126766

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

llvm-svn: 126762

location information for elaborated types. *sigh*

llvm-svn: 126753

llvm-svn: 126752

diagnose ignored qualifiers on return types, only assume that there is
a pointer chunk if the type is *structurally* a pointer type, not if
it's a typedef of a pointer type. Fixes PR9328/<rdar://problem/9055428>.

llvm-svn: 126751

a dependent template name rather than (indirectly and incorrectly)
trying to determine whether we can compute a context for the
nested-name-specifier. Fixes a GCC testsuite regression,
<rdar://problem/9068589>.

llvm-svn: 126749

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

llvm-svn: 126746

possible for these to show up due to metaprogramming both in unevaluated
contexts and compile-time dead branches.

Those aren't the bugs we're looking for.

llvm-svn: 126739

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

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

source-location information into a NestedNameSpecifierLocBuilder
class, which lives within the AST library and centralize all knowledge
of the format of nested-name-specifier location information here.

No functionality change.

llvm-svn: 126716

source-location information. We don't actually preserve this
information in any of the resulting TypeLocs (yet), so it doesn't
matter.

llvm-svn: 126693

MemberExpr, the last of the expressions with qualifiers!

llvm-svn: 126688

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

CXXDependentScopeMemberExpr, and clean up instantiation of
nested-name-specifiers with dependent template specialization types in
the process.

llvm-svn: 126663

dependent template names. There is still a lot of redundant code in
TreeTransform to cope with TemplateSpecializationTypes, which I'll
remove in stages.

llvm-svn: 126656

C++ exceptions, even when exceptions have been turned off using -fno-exceptions.
Make the -fobjc-exceptions flag do the same thing, but for Objective-C exceptions.

C++ and Objective-C exceptions can also be disabled using -fno-cxx-excptions and
-fno-objc-exceptions.

llvm-svn: 126630

nested-name-specifier, e.g., 

  T::template apply<U>::

represent the dependent template name specialization as a
DependentTemplateSpecializationType, rather than a
TemplateSpecializationType with a dependent TemplateName.

llvm-svn: 126593

specifiers such as

  typename T::template apply<U>

Previously, we would turn T::template apply<U> into a
TemplateSpecializationType. Then, we'd reprocess that
TemplateSpecializationType and turn it into either a
TemplateSpecializationType wrapped in an ElaboratedType (when we could
resolve "apply" to a template declaration) or a
DependentTemplateSpecializationType. We now produce the same ASTs but
without generating the intermediate TemplateSpecializationType.

The end goal here is to avoid generating TemplateSpecializationTypes
with dependent template-names, ever. We're not there yet.

llvm-svn: 126589