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

llvm-svn: 126797

This fixes few blocks.exp regressions.

llvm-svn: 126795

compare it with getDriver().Dir.c_str(), since that is a pointer
comparison, not a "are these strings equal" comparison.

Instead, just compare with getDriver().Dir directly, so both sides will
get promoted to std::string, and the regular std::string comparison
operator applies.

Patch by Dimitry Andric!

llvm-svn: 126791

Don't warn about unused values in ternary ?: expressions unless both the LHS and RHS are "unused" (side-effect free).

Patch by Justin Bogner!  Fixes PR 8282.

llvm-svn: 126779

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: 126775

llvm-svn: 126772

llvm-svn: 126770

llvm-svn: 126768

llvm-svn: 126767

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

Patch by Dimitry Andric!

llvm-svn: 126763

llvm-svn: 126762

path.  This avoids accidentally including the wrong headers.

Patch by Dimitry Andric!

llvm-svn: 126761

ToolChain's FilePaths.  If clang is installed as a port in /usr/local,
it is *not* supposed to use /usr/local/lib by default, for example.

Additionally, there are no clang-related executables in either
/usr/libexec, or getDriver().Dir + "/../libexec", anymore, so remove
that from the ToolChain's ProgramPaths.

Patch by Dimitry Andric!

llvm-svn: 126760

retrieve the library paths from the ToolChain object instead.

Copy the relevant code from linuxtools::Link::ConstructJob(), and
replace the std::string stuff with llvm::StringRef, while we're here.

Patch by Dimitry Andric!

llvm-svn: 126757

one.

llvm-svn: 126756

llvm-svn: 126755

The prototype for objc_msgSend() is technically variadic - 
`id objc_msgSend(id, SEL, ...)`. 
But all method calls should use a prototype that matches the method, 
not the prototype for objc_msgSend itself().
// rdar://9048030

llvm-svn: 126754

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

CC="clang -use-gold-plugin -emit-llvm"
CXX="clang++ -use-gold-plugin -emit-llvm"

llvm-svn: 126740

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

In preparation for fixing PR 6884, rework CFGElement to have getAs<> return pointers instead of fresh CFGElements.

- Also, consoldiate getDtorKind() and getKind() into one "kind".
- Add empty getDestructorDecl() method to CFGImplicitDtor.

llvm-svn: 126738

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

llvm-svn: 126735

llvm-svn: 126734

functionality intended.

llvm-svn: 126730

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

and hope the wrath of the buildbots will not descend upon me.

llvm-svn: 126728

in functionality intended.

llvm-svn: 126727

llvm-svn: 126726

llvm-svn: 126725

llvm-svn: 126724