| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
llvm-svn: 77510
|
| |
|
|
| |
llvm-svn: 77492
|
| |
|
|
| |
llvm-svn: 77368
|
| |
|
|
| |
llvm-svn: 77349
|
| |
|
|
| |
llvm-svn: 77267
|
| |
|
|
| |
llvm-svn: 77249
|
| |
|
|
|
|
| |
place but will be removed shortly. The new struct builder works on big endian systems.
llvm-svn: 77185
|
| |
|
|
|
|
| |
support for inserting part of a bitfield in the previous byte.
llvm-svn: 77180
|
| |
|
|
| |
llvm-svn: 77177
|
| |
|
|
|
|
| |
packed struct when necessary.
llvm-svn: 77038
|
| |
|
|
|
|
| |
structs but throw away the result.
llvm-svn: 77021
|
| |
|
|
| |
llvm-svn: 77012
|
| |
|
|
| |
llvm-svn: 76985
|
| |
|
|
| |
llvm-svn: 76969
|
| |
|
|
|
|
| |
since it's meaning is completely different than for non-bit fields.
llvm-svn: 76882
|
| |
|
|
|
|
| |
contain a single element and either a single i8 element or an array of i8s, there's no reason to use a packed struct.
llvm-svn: 76854
|
| |
|
|
|
|
|
|
|
| |
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
llvm-svn: 76193
|
| |
|
|
|
|
| |
Type::getAsMemberPointerType(), Type::getAsTagType(), and Type::getAsRecordType() with their Type::getAs<XXX> equivalents.
llvm-svn: 76139
|
| |
|
|
| |
llvm-svn: 75705
|
| |
|
|
| |
llvm-svn: 75569
|
| |
|
|
| |
llvm-svn: 75446
|
| |
|
|
| |
llvm-svn: 75028
|
| |
|
|
| |
llvm-svn: 74986
|
| |
|
|
|
|
|
| |
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
llvm-svn: 74506
|
| |
|
|
|
|
| |
static intializers for structs.
llvm-svn: 73349
|
| |
|
|
|
|
|
|
| |
preprocessor and initialize it early in clang-cc. This
ensures that __has_builtin works in all modes, not just
when ASTContext is around.
llvm-svn: 73319
|
| |
|
|
|
|
| |
of a reference correctly.
llvm-svn: 72463
|
| |
|
|
| |
llvm-svn: 71937
|
| |
|
|
|
|
|
|
|
| |
to allow us to support generation of deferred ctors/dtors.
It looks like codegen isn't emitting a call to the dtor in
member-functions.cpp:test2, but when it does, its body should
get emitted.
llvm-svn: 71594
|
| |
|
|
|
|
| |
LLVM.
llvm-svn: 71350
|
| |
|
|
| |
llvm-svn: 71194
|
| |
|
|
|
|
| |
constant initializers.
llvm-svn: 70483
|
| |
|
|
|
|
| |
implies an all-zero bit pattern.
llvm-svn: 68994
|
| |
|
|
| |
llvm-svn: 68852
|
| |
|
|
| |
llvm-svn: 68764
|
| |
|
|
|
|
| |
No functionality change (really).
llvm-svn: 68726
|
| |
|
|
|
|
| |
when the destination has a reference type. (No functionality change yet)
llvm-svn: 68593
|
| |
|
|
|
|
| |
Patch by Jean-Daniel Dupas. Thanks!
llvm-svn: 68203
|
| |
|
|
|
|
|
|
| |
functionality change.
Changed GenerateConstantString() to take an ObjCStringLiteral (instead of a std::string). While this isn't strictly necessary, it seems cleaner and allows us to cache to "containsNonAscii" if necessary (to avoid checking in both Sema and CodeGen).
llvm-svn: 68114
|
| |
|
|
| |
llvm-svn: 65951
|
| |
|
|
| |
llvm-svn: 65746
|
| |
|
|
| |
llvm-svn: 65487
|
| |
|
|
|
|
|
| |
The big difference here is that (like string literal) @encode has
array type, not pointer type.
llvm-svn: 65391
|
| |
|
|
|
|
|
| |
variables.
- PR3657.
llvm-svn: 65381
|
| |
|
|
| |
llvm-svn: 65267
|
| |
|
|
|
|
|
| |
appear to be constant. I'll probably redo this and throw it all away
later once we have codegen for BlockDeclRefExprs.
llvm-svn: 65070
|
| |
|
|
|
|
|
|
|
| |
only occur for pointer types; they are also possible for integer types
now.
- No intended functionality change, IntExprEvaluate doesn't return
LValue results yet.
llvm-svn: 65066
|
| |
|
|
|
|
| |
The size calculation is improved.
llvm-svn: 64994
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRgen no longer relies on isConstantInitializer, instead we just try
to emit the constant. If that fails then in C we emit an error
unsupported (this occurs when Sema accepted something that it doesn't
know how to fold, and IRgen doesn't know how to emit) and in C++ we
emit a guarded initializer.
This ends up handling a few more cases, because IRgen was actually
able to emit some of the constants Sema accepts but can't Evaluate().
For example, PR3398.
llvm-svn: 64780
|
| |
|
|
|
|
| |
starting to work for blocks.
llvm-svn: 64570
|