| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
(transforming each in turn) into calls into one central routine
(TransformExprs) that transforms a list of expressions. This
refactoring is preparatory work for pack expansions whose in an
expression-list.
No functionality change.
llvm-svn: 122761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 122365
|
|
|
|
|
|
| |
in an exception specification.
llvm-svn: 122297
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lists, so that all such transformations go through a single,
iterator-based transformation function. This is the only place where
we need to implement the logic for transforming pack expansions whose
pattern is a template argument.
Unfortunately, the new cases this refactoring brings into the fold
can't be meaningfully tested yet. We need template argument deduction
to work well enough for variadic function templates first.
llvm-svn: 122289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whose patterns are template arguments. We can now instantiate, e.g.,
typedef tuple<pair<OuterTypes, InnerTypes>...> type;
where OuterTypes and InnerTypes are template type parameter packs.
There is a horrible inefficiency in
TemplateArgumentLoc::getPackExpansionPattern(), where we need to
create copies of TypeLoc data because our interfaces traffic in
TypeSourceInfo pointers where they should traffic in TypeLocs
instead. I've isolated in efficiency in this one routine; once we
refactor our interfaces to traffic in TypeLocs, we can eliminate it.
llvm-svn: 122278
|
|
|
|
| |
llvm-svn: 122257
|
|
|
|
|
|
| |
centralizing the transformation into two routines. No functionality change.
llvm-svn: 122253
|
|
|
|
|
|
| |
the list traversal. Part 1, no functionality change.
llvm-svn: 122252
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 121516
|
|
|
|
| |
llvm-svn: 121488
|
|
|
|
|
|
| |
BinaryTypeTraitExpr.
llvm-svn: 121298
|
|
|
|
|
|
| |
New AST node introduced: BinaryTypeTraitExpr; to be reused for more intrinsics.
llvm-svn: 121074
|
|
|
|
|
|
| |
reason this is limited to C++, and it's certainly not limited to temporaries.
llvm-svn: 120996
|
|
|
|
|
|
|
|
| |
ObjCPropertyRefExpr
into the latter.
llvm-svn: 120643
|
|
|
|
|
|
| |
using it
llvm-svn: 120628
|
|
|
|
|
|
|
|
|
|
| |
expands to nothing"
and use a better and more general approach, where NullStmt has a flag to indicate whether it was preceded by an empty macro.
Thanks to Abramo Bagnara for the hint!
llvm-svn: 119887
|
|
|
|
|
|
|
|
|
| |
if (condition)
CALL(0); // empty macro but don't warn for empty body.
Fixes rdar://8436021.
llvm-svn: 119838
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
|
|
|
|
|
|
|
| |
certain internal type-checking procedures as well as for representing
certain implicitly-generated operations. Uses to follow.
llvm-svn: 119289
|
|
|
|
|
|
|
|
|
| |
parameters to the Transform*Type functions and instead call out
the specific cases where an object type and the unqualified lookup
results are important. Fixes an assert and failed compile on
a testcase from PR7248.
llvm-svn: 118887
|
|
|
|
|
|
|
|
|
| |
NEON vector types need to be mangled in a special way to comply with ARM's ABI,
similar to some of the AltiVec-specific vector types. This patch is mostly
just renaming a bunch of "AltiVecSpecific" things, since they will no longer
be specific to AltiVec. Besides that, it just adds the new "NeonVector" enum.
llvm-svn: 118724
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
llvm-svn: 118385
|
|
|
|
|
|
| |
making something up. Fixes PR8129.
llvm-svn: 118258
|
|
|
|
|
|
| |
anymore.
llvm-svn: 117357
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds them where missing, and traces them through PCH. We fix at least one
bug in the extents found by the Index library, and make a lot of refactoring
tools which care about the exact formulation of a constructor call easier to
write. Also some minor cleanups to more consistently follow the friend pattern
instead of the setter pattern when rebuilding a serialized AST.
Patch originally by Samuel Benzaquen.
llvm-svn: 117254
|
|
|
|
|
|
|
| |
'super' as receiver of property or a setter/getter
methods. //rdar: //8525788
llvm-svn: 116483
|
|
|
|
|
|
|
| |
i.e. expressions with an internally-convenient type which should not be
appearing in generally valid, complete ASTs.
llvm-svn: 116281
|
|
|
|
|
|
|
|
| |
arguments in either the placement or constructor arguments. This is
important if the default arguments refer to a declaration or create a
temporary.
llvm-svn: 115700
|
|
|
|
|
|
|
|
|
|
| |
auto f(int) -> int
from Daniel Wallin!
(With a few minor bug fixes from me).
llvm-svn: 115322
|
|
|
|
|
|
| |
rdar://8483139.
llvm-svn: 114954
|
|
|
|
|
|
|
|
|
| |
"used", at the time that the default argument itself is used, also
mark destructors that will be called by this expression. This fixes a
regression that I introduced in r113700, which broke WebKit, and fixes
<rdar://problem/8427926>.
llvm-svn: 113883
|
|
|
|
| |
llvm-svn: 113623
|
|
|
|
|
|
| |
eliminating an unnecessary use of TemporaryBase in the process.
llvm-svn: 113500
|
|
|
|
|
|
|
| |
are still a few (legitimate, unfortunate) uses of this hack around,
but at least now there are fewer.
llvm-svn: 113498
|
|
|
|
|
|
|
|
| |
with comma-separated lists. We never actually used the comma
locations, nor did we store them in the AST, but we did manage to
waste time during template instantiation to produce fake locations.
llvm-svn: 113495
|
|
|
|
|
|
| |
libclang visitation.
llvm-svn: 113492
|
|
|
|
|
|
|
|
| |
TreeTransform, since we were getting an empty source range where we
shouldn't. Sadly, the test case is Boost.Proto, and isn't worth
reducing.
llvm-svn: 113446
|
|
|
|
| |
llvm-svn: 113356
|
|
|
|
|
|
|
|
| |
CXXTemporaryObjectExpr, CXXScalarValueInitExpr, and
CXXUnresolvedConstructExpr, getting rid of a bunch of FIXMEs in the
process.
llvm-svn: 113319
|
|
|
|
|
|
| |
the TypeSourceInfo for the allocated type. Fixes PR7501.
llvm-svn: 113291
|
|
|
|
|
|
| |
well-intentioned but completely unused code.
llvm-svn: 112868
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiating the parameters. In a perfect world, this wouldn't
matter, and compilers are free to instantiate in any order they
want. However, every other compiler seems to instantiate the return
type first, and some code (in this case, Boost.Polygon) depends on
this and SFINAE to avoid instantiating something that shouldn't be
instantiated.
We could fight this battle, and insist that Clang is allowed to do
what it does, but it's not beneficial: it's more predictable to
instantiate this way, in source order. When we implement
late-specified return types, we'll need to instantiate the return type
last when it was late-specified, hence the FIXME.
We now compile Boost.Polygon properly.
llvm-svn: 112561
|
|
|
|
|
|
| |
some issues being sorted out.
llvm-svn: 112493
|
|
|
|
|
|
|
|
|
|
| |
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
|
|
|
|
|
|
|
|
|
|
|
| |
For large floats/integers, APFloat/APInt will allocate memory from the heap to represent these numbers.
Unfortunately, when we use a BumpPtrAllocator to allocate IntegerLiteral/FloatingLiteral nodes the memory associated with
the APFloat/APInt values will never get freed.
I introduce the class 'APNumericStorage' which uses ASTContext's allocator for memory allocation and is used internally by FloatingLiteral/IntegerLiteral.
Fixes rdar://7637185
llvm-svn: 112361
|
|
|
|
|
|
|
| |
we don't see a DeclStmt (failure to instantiate which generally causes
panic).
llvm-svn: 112282
|
|
|
|
|
|
|
|
|
| |
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
llvm-svn: 112244
|
|
|
|
|
|
|
| |
Clients of Sema don't need to know (for example) the list of diagnostics we
support.
llvm-svn: 112093
|