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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126776 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126765 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126760 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126757 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126754 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126751 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126749 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126748 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126739 91177308-0d34-0410-b5e6-96231b3b80d8
- Also, consoldiate getDtorKind() and getKind() into one "kind".
- Add empty getDestructorDecl() method to CFGImplicitDtor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126738 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126737 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126729 91177308-0d34-0410-b5e6-96231b3b80d8
- renames evalCastNL and evalCastL to evalCastFromNonLoc and
evalCastFromLoc (avoid abbreviations that aren't well known).
- makes all function parameter names start with a lower case letter
for consistency and distinction from member variables.
- avoids abbreviations in function parameter names.
Reviewed by kremenek@apple.com.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126722 91177308-0d34-0410-b5e6-96231b3b80d8
arithmetic. This is part of PR9256, it would be great if someone else
wired up -fno-strict-overflow in the driver to -fwrapv.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126718 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126716 91177308-0d34-0410-b5e6-96231b3b80d8
CC="clang -use-gold-plugin" CFLAGS=-emit-llvm ../configure...
and not be hit with a warning for each .c file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126713 91177308-0d34-0410-b5e6-96231b3b80d8
source-location information. We don't actually preserve this
information in any of the resulting TypeLocs (yet), so it doesn't
matter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126693 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126681 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126678 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Dan Gohman
Ted Kremenek
Roman Divacky
Daniel Dunbar
Fariborz Jahanian
Rafael Espindola
Chandler Carruth
Argyrios Kyrtzidis
Ken Dyck
Zhanyong Wan
Chris Lattner
Devang Patel