| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
in the fragile and non-fragile Mac ObjC runtimes. No useful test
case. Fixes rdar://problem/11072576.
llvm-svn: 153778
|
| |
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
|
| |
|
|
| |
llvm-svn: 151631
|
| |
|
|
| |
llvm-svn: 151150
|
| |
|
|
|
|
|
| |
the 'invariant.load' metadata tag onto those loads.
// rdar://10840980
llvm-svn: 150994
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optional argument passed through the variadic ellipsis)
potentially affects how we need to lower it. Propagate
this information down to the various getFunctionInfo(...)
overloads on CodeGenTypes. Furthermore, rename those
overloads to clarify their distinct purposes, and make
sure we're calling the right one in the right place.
This has a nice side-effect of making it easier to construct
a function type, since the 'variadic' bit is no longer
separable.
This shouldn't really change anything for our existing
platforms, with one minor exception --- we should now call
variadic ObjC methods with the ... in the "right place"
(see the test case), which I guess matters for anyone
running GNUStep on MIPS. Mostly it's just a substantial
clean-up.
llvm-svn: 150788
|
| |
|
|
|
|
|
|
|
|
| |
The garbage collection metadata needs to be merged "intelligently", when two or
more modules are linked together, and not merely appended. (Appending creates a
section which is too large.) The module flags metadata method is the way to do
this.
<rdar://problem/8198537>
llvm-svn: 150648
|
| |
|
|
|
|
| |
as unscanned. // rdar://10832643
llvm-svn: 150639
|
| |
|
|
| |
llvm-svn: 150210
|
| |
|
|
|
|
|
| |
This looks like it had a small, but measurable performance improvement on -O0
compile time for our ObjC tests.
llvm-svn: 150208
|
| |
|
|
|
|
| |
consistency with NamedDecls.
llvm-svn: 149981
|
| |
|
|
| |
llvm-svn: 149976
|
| |
|
|
| |
llvm-svn: 149975
|
| |
|
|
| |
llvm-svn: 149974
|
| |
|
|
|
|
| |
CodeGenModule.
llvm-svn: 149943
|
| |
|
|
| |
llvm-svn: 149916
|
| |
|
|
| |
llvm-svn: 149801
|
| |
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 149470. This fixes test/CodeGen/PR3589-freestanding-libcalls.c.
Original log:
ConstantArray::get() (for strings) is going away, use
ConstantDataArray::getString instead.
Many instances of ConstantArray::get() could be moved to
use more efficient ConstantDataArray methods that avoid a ton
of intermediate Constant*'s for each element (e.g.
GetConstantArrayFromStringLiteral). I don't plan on doing this
in the short-term though.
llvm-svn: 149477
|
| |
|
|
|
|
| |
Patch by Niels Grewe!
llvm-svn: 149401
|
| |
|
|
| |
llvm-svn: 149377
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ConstantDataArray::getString instead.
Many instances of ConstantArray::get() could be moved to
use more efficient ConstantDataArray methods that avoid a ton
of intermediate Constant*'s for each element (e.g.
GetConstantArrayFromStringLiteral). I don't plan on doing this
in the short-term though.
llvm-svn: 149363
|
| |
|
|
|
|
|
| |
argument. twik to support the test case.
// rdar://10444476
llvm-svn: 149298
|
| |
|
|
|
|
|
|
|
| |
consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
In this patch, the null path releases consumed argument.
// rdar://10444474
llvm-svn: 149279
|
| |
|
|
| |
llvm-svn: 149205
|
| |
|
|
|
|
|
|
| |
consume one or more of their arguments. If not done, this will cause a leak
as method will not consume the argument when receiver is null.
// rdar://10444474
llvm-svn: 149184
|
| |
|
|
| |
llvm-svn: 148577
|
| |
|
|
| |
llvm-svn: 148358
|
| |
|
|
|
|
| |
generation for Objective-C; it may not be needed.
llvm-svn: 148317
|
| |
|
|
|
|
| |
This allows -Wswitch-enum to find switches that need updating when these enums are modified.
llvm-svn: 148281
|
| |
|
|
|
|
|
| |
properties of c++ object types with non-trivial
assignment copy. Not used yet. // rdar://6137845
llvm-svn: 147666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for Objective-C protocols, including:
- Using the first declaration as the canonical declaration
- Using the definition as the primary DeclContext
- Making sure that all declarations have a pointer to the definition
data, and that we know which declaration is the definition
- Serialization support for redeclaration chains and for adding
definitions to already-serialized declarations.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCProtocolDecls.
llvm-svn: 147410
|
| |
|
|
|
|
| |
<rdar://problem/10492556>
llvm-svn: 146926
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new metadata are method @encode strings with additional data.
1. Each Objective-C object is marked with its class name and protocol names.
The same is done for property @encode already.
2. Each block object is marked with its function prototype's @encoding. For
example, a method parameter that is a block object that itself returns void
and takes an int would look like:
@?<v@?i>
These new method @encode strings are stored in a single array pointed to by structs protocol_t and objc_protocol_ext.
Patch provided by Greg Parker!
llvm-svn: 145469
|
| |
|
|
|
|
|
|
| |
attribute. This prevents the stack slot allocator from coming along and using a
stack which it thinks is available but isn't.
<rdar://problem/10492556>
llvm-svn: 145332
|
| |
|
|
|
|
| |
loads to later be moved/combined in the optimizer. Fixes <rdar://problem/6027699>
llvm-svn: 144318
|
| |
|
|
|
|
| |
double, make sure to use the objc_msgSend_fp2ret function which ensures that the return value will be {0, 0} if the receiver is nil.
llvm-svn: 143350
|
| |
|
|
|
|
|
| |
value and ABI requires return slot to be passed as first
argument to message sent. // rdar://10331109
llvm-svn: 143053
|
| |
|
|
| |
llvm-svn: 142072
|
| |
|
|
|
|
|
|
|
|
|
| |
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
llvm-svn: 141561
|
| |
|
|
|
|
|
| |
the pointer, being sure to do so before running cleanups
associated with that full-expression. rdar://10042689
llvm-svn: 140945
|
| |
|
|
| |
llvm-svn: 140637
|
| |
|
|
| |
llvm-svn: 140407
|
| |
|
|
| |
llvm-svn: 140367
|
| |
|
|
|
|
|
|
|
|
| |
language options. Use that .def file to declare the LangOptions class
and initialize all of its members, eliminating a source of annoying
initialization bugs.
AST serialization changes are next up.
llvm-svn: 139605
|
| |
|
|
|
|
|
|
|
| |
than having CodeGen check whether a declaration comes from an AST file
(which it shouldn't know or care about), make sure that the AST writer and
reader pass along "interesting" declarations that CodeGen needs to
know about.
llvm-svn: 139441
|
| |
|
|
|
|
|
|
| |
declaration was deserialized from an AST file. Use this instead of
Decl::getPCHLevel() wherever possible. This is a simple step toward
killing off Decl::getPCHLevel().
llvm-svn: 139427
|
| |
|
|
|
|
|
|
| |
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
|
| |
|
|
| |
llvm-svn: 137472
|