| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
tag definitions. Also, add support for template instantiation of
NestedNameSpecifierLocs.
llvm-svn: 126470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
llvm-svn: 126459
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 126358
|
|
|
|
|
|
| |
LabelDecls. Fixes <rdar://problem/9040579>.
llvm-svn: 126304
|
|
|
|
|
|
| |
This fixes PR 8738, 9060 and 9132.
llvm-svn: 126069
|
|
|
|
| |
llvm-svn: 126060
|
|
|
|
| |
llvm-svn: 126050
|
|
|
|
|
|
|
|
|
| |
This removes the final dependency edge from any lib outside of CodeGen
to core. As a result we can, and do, trim the dependency on core
from libclang, PrintFunctionNames, the unit tests and c-index-test.
While at it, review and trim other unneeded dependencies.
llvm-svn: 125820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class and to bind the shared value using OpaqueValueExpr. This fixes an
unnoticed problem with deserialization of these expressions where the
deserialized form would lose the vital pointer-equality trait; or rather,
it fixes it because this patch also does the right thing for deserializing
OVEs.
Change OVEs to not be a "temporary object" in the sense that copy elision is
permitted.
This new representation is not totally unawkward to work with, but I think
that's really part and parcel with the semantics we're modelling here. In
particular, it's much easier to fix things like the copy elision bug and to
make the CFG look right.
I've tried to update the analyzer to deal with this in at least some
obvious cases, and I think we get a much better CFG out, but the printing
of OpaqueValueExprs probably needs some work.
llvm-svn: 125744
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LabelDecl and LabelStmt. There is a 1-1 correspondence between the
two, but this simplifies a bunch of code by itself. This is because
labels are the only place where we previously had references to random
other statements, causing grief for AST serialization and other stuff.
This does cause one regression (attr(unused) doesn't silence unused
label warnings) which I'll address next.
This does fix some minor bugs:
1. "The only valid attribute " diagnostic was capitalized.
2. Various diagnostics printed as ''labelname'' instead of 'labelname'
3. This reduces duplication of label checking between functions and blocks.
Review appreciated, particularly for the cindex and template bits.
llvm-svn: 125733
|
|
|
|
|
|
|
|
|
| |
code-completion results accessed via libclang, to extend the lifetime
of the allocator used for cached global code-completion results at
least until these completion results are destroyed. Fixes
<rdar://problem/8997369>.
llvm-svn: 125678
|
|
|
|
|
|
|
| |
Stmt::const_child_range, then make a bunch of places use them instead
of the individual iterator accessors.
llvm-svn: 125450
|
|
|
|
| |
llvm-svn: 125275
|
|
|
|
| |
llvm-svn: 125217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
there were only three virtual methods of any significance.
The primary way to grab child iterators now is with
Stmt::child_range children();
Stmt::const_child_range children() const;
where a child_range is just a std::pair of iterators suitable for
being llvm::tie'd to some locals. I've left the old child_begin()
and child_end() accessors in place, but it's probably a substantial
penalty to grab the iterators individually now, since the
switch-based dispatch is kindof inherently slower than vtable
dispatch. Grabbing them together is probably a slight win over the
status quo, although of course we could've achieved that with vtables, too.
I also reclassified SwitchCase (correctly) as an abstract Stmt
class, which (as the first such class that wasn't an Expr subclass)
required some fiddling in a few places.
There are somewhat gross metaprogramming hooks in place to ensure
that new statements/expressions continue to implement
getSourceRange() and children(). I had to work around a recent clang
bug; dgregor actually fixed it already, but I didn't want to
introduce a selfhosting dependency on ToT.
llvm-svn: 125183
|
|
|
|
|
|
|
| |
It is not possible to simply change that target name to `clang'
because we already have one.
llvm-svn: 124972
|
|
|
|
| |
llvm-svn: 124920
|
|
|
|
|
|
| |
not the USR of the class category or extension.
llvm-svn: 124859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whose inode has changed since the file was first created and that is
being seen through a different path name (e.g., due to symlinks or
relative path elements), such that its FileEntry pointer doesn't match
a known FileEntry pointer. Since this requires a system call (to
stat()), we only perform this deeper checking if we can't find the
file by comparing FileEntry pointers.
Also, add a micro-optimization where we don't bother to compute line
numbers when given the location (1, 1). This improves the
efficiency of clang_getLocationForOffset().
llvm-svn: 124800
|
|
|
|
| |
llvm-svn: 124700
|
|
|
|
|
|
|
| |
the string copying goes through a single place that can have
associated state.
llvm-svn: 124698
|
|
|
|
|
|
|
|
|
|
|
|
| |
BumpPtrAllocator, rather than manually new/delete'ing them. This
optimization also allows us to avoid allocating memory for and copying
constant strings (e.g., "return", "class").
This also required embedding the priority and availability of results
within the code completion string, to avoid extra memory allocation
within libclang.
llvm-svn: 124673
|
|
|
|
|
|
| |
qualifiers on a CXType. Patch from Stefan Seefeld, test by me.
llvm-svn: 124377
|
|
|
|
|
|
|
|
| |
clang_getDeclObjCTypeEncoding(); use ASTContext's methods instead,
which will (lazily) create the type as needed. Otherwise, we can end
up with null QualTypes.
llvm-svn: 124133
|
|
|
|
| |
llvm-svn: 123848
|
|
|
|
| |
llvm-svn: 123846
|
|
|
|
|
|
| |
thousand other things which were (generally inadvertantly) relying on that.
llvm-svn: 123814
|
|
|
|
|
|
| |
clang_createTranslationUnitFromSourceFile().
llvm-svn: 123793
|
|
|
|
|
|
| |
-Wint-to-pointer-cast.
llvm-svn: 123719
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template template parameter pack that cannot be fully expanded because
its enclosing pack expansion could not be expanded. This form of
TemplateName plays the same role as SubstTemplateTypeParmPackType and
SubstNonTypeTemplateParmPackExpr do for template type parameter packs
and non-type template parameter packs, respectively.
We should now handle these multi-level pack expansion substitutions
anywhere. The largest remaining gap in our variadic-templates support
is that we cannot cope with non-type template parameter packs whose
type is a pack expansion.
llvm-svn: 123521
|
|
|
|
|
|
|
|
|
| |
that captures the substitution of a non-type template argument pack
for a non-type template parameter pack within a pack expansion that
cannot be fully expanded. This follows the approach taken by
SubstTemplateTypeParmPackType.
llvm-svn: 123506
|
|
|
|
|
|
|
| |
more accurate, and makes it make sense for it to hold a delegating constructor
call.
llvm-svn: 123084
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansions with something that is easier to use correctly: a new
template argment kind, rather than a bit on an existing kind. Update
all of the switch statements that deal with template arguments, fixing
a few latent bugs in the process. I"m happy with this representation,
now.
And, oh look! Template instantiation and deduction work for template
template argument pack expansions.
llvm-svn: 122896
|
|
|
|
|
|
|
|
|
| |
parameter pack.
Note that we're missing proper libclang support for the new
SizeOfPackExpr expression node.
llvm-svn: 122813
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template argument (described by an expression, of course). For
example:
template<int...> struct int_tuple { };
template<int ...Values>
struct square {
typedef int_tuple<(Values*Values)...> type;
};
It also lays the foundation for pack expansions in an initializer-list.
llvm-svn: 122751
|
|
|
|
|
|
| |
also adds a method in ASTContext which encodes FunctionDecls using the same encoding format that is used for Objective-C methods.
llvm-svn: 122639
|
|
|
|
|
|
|
| |
16-bits in size. Implement this by splitting WChar into two enums, like we have
for char. This fixes a miscompmilation of XULRunner, PR8856.
llvm-svn: 122558
|
|
|
|
| |
llvm-svn: 122394
|
|
|
|
|
|
|
|
| |
take into account the region of interest. Otherwise, we may fail to
traverse some important preprocessed entity cursors.
Fixes <rdar://problem/8554072>.
llvm-svn: 122350
|
|
|
|
|
|
|
|
| |
clang_getCursorLexicalParent() to cope with class and function
templates, along with the parent of the translation unit. Fixes PR8761
and PR8766.
llvm-svn: 122324
|
|
|
|
|
|
|
| |
area of printing template arguments. The functionality changes here
are limited to cases of variadic templates that aren't yet enabled.
llvm-svn: 122250
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pack expansions, e.g. given
template<typename... Types> struct tuple;
template<typename... Types>
struct tuple_of_refs {
typedef tuple<Types&...> types;
};
the type of the "types" typedef is a PackExpansionType whose pattern
is Types&.
This commit introduces support for creating pack expansions for
template type arguments, as above, but not for any other kind of pack
expansion, nor for any form of instantiation.
llvm-svn: 122223
|
|
|
|
| |
llvm-svn: 122117
|
|
|
|
| |
llvm-svn: 121795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
common base for ExtQuals and Type that stores the underlying type
pointer. This results in a 2% performance win for -emit-llvm on a
typical C file, with 1% memory growth in the AST.
Note that there is an API change in this optimization:
QualType::getTypePtr() can no longer be invoked on a NULL
QualType. If the QualType might be NULL, use
QualType::getTypePtrOrNull(). I've audited all uses of getTypePtr() in
the code base and changed the appropriate uses over to
getTypePtrOrNull().
A future optimization opportunity would be to distinguish between
cast/dyn_cast and cast_or_null/dyn_cast_or_null; for the former, we
could use getTypePtr() rather than getTypePtrOrNull(), to take another
branch out of the cast/dyn_cast implementation.
llvm-svn: 121489
|
|
|
|
| |
llvm-svn: 121488
|
|
|
|
|
|
| |
another preprocessing cursor, since we want the outermost one.
llvm-svn: 121470
|
|
|
|
|
|
| |
definition we found
llvm-svn: 121451
|
|
|
|
| |
llvm-svn: 121341
|
|
|
|
| |
llvm-svn: 121334
|