walk the preprocessing record *before* walking the declarations, so
they we pretend that we actually respect the phases of translation.
We still walk the preprocessing record after the declarations when
performing token annotation or finding the cursor at a location, since
those routines depend on those semantics.
Fixes <rdar://problem/9137195>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127776 91177308-0d34-0410-b5e6-96231b3b80d8
the program name, if it includes it as proper prefix. This makes calling
clang with -ccc-host-triple x86_64-linux the same as calling it with the
name x86_64-linux-clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127753 91177308-0d34-0410-b5e6-96231b3b80d8
The previous syntax created a list with the usual semicolon as
separator, which breaks the link command.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127579 91177308-0d34-0410-b5e6-96231b3b80d8
On Windows only the shared library is created. The reason for this is
that clang.lib the static library would clash with clang.lib the
export library of the dll.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127566 91177308-0d34-0410-b5e6-96231b3b80d8
Cygwin's ctype.h says;
/* These macros are intentionally written in a manner that will trigger
a gcc -Wall warning if the user mistakenly passes a 'char' instead
of an int containing an 'unsigned char'.
(snip) */
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127308 91177308-0d34-0410-b5e6-96231b3b80d8
should report the original file name for contents of files that were overriden by other files,
otherwise it should report the name of the new file. Default is true.
Also add similar field in PreprocessorOptions and pass similar parameter in ASTUnit::LoadFromCommandLine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127289 91177308-0d34-0410-b5e6-96231b3b80d8
Allow remapping a file by specifying another filename whose contents should be loaded if the original
file gets loaded. This allows to override files without having to create & load buffers in advance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127052 91177308-0d34-0410-b5e6-96231b3b80d8
nested-name-specifier and improve the detection of implicit 'this'
bases. Fixes <rdar://problem/8750392>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126880 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126844 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
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
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
CXXDependentScopeMemberExpr, and clean up instantiation of
nested-name-specifiers with dependent template specialization types in
the process.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126663 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't totally complete. Right now scan-build uses some heuristics to determine
which checkers are enabled by default, but it cannot always tell which checkers
are not enabled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126521 91177308-0d34-0410-b5e6-96231b3b80d8
DependentScopeDeclRefExpr. Plus, give NestedNameSpecifierLoc == and !=
operators, since we're going to need 'em elsewhere.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126508 91177308-0d34-0410-b5e6-96231b3b80d8
pseudo-destructor expressions. Also, clean up some
template-instantiation and type-checking issues with
pseudo-destructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126498 91177308-0d34-0410-b5e6-96231b3b80d8
UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the
extremely-lossy NestedNameSpecifier/SourceRange pair it used to use,
improving source-location information.
Various infrastructure updates to support NestedNameSpecifierLoc:
- AST/PCH (de-)serialization
- Recursive AST visitor
- libclang traversal (including the first tests of this
functionality)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126459 91177308-0d34-0410-b5e6-96231b3b80d8
way it keeps track of namespaces. Previously, we would map from the
namespace alias to its underlying namespace when building a
nested-name-specifier, losing source information in the process.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126358 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Ted Kremenek
Joerg Sonnenberger
Oscar Fuentes
Abramo Bagnara
Peter Collingbourne
NAKAMURA Takumi
Argyrios Kyrtzidis
Benjamin Kramer
Daniel Dunbar
Richard Smith
Rafael Espindola