cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:
id x;
(NSString**)&x; // Casting as (__strong NSString**).
llvm-svn: 134275
newly introduced Sema::BuildVectorLiteral.
-Make Sema::ActOnCastExpr handle a vector initializer both when the cast'ed expression
is a ParenListExpr and when it is a ParenExpr.
-Ultimately make Sema::ActOnParenOrParenListExpr independent of what the cast type was.
llvm-svn: 134274
cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:
id x;
static_cast<NSString**>(&x); // Casting as (__strong NSString**).
This currently only works for C++ named casts, C casts to follow.
llvm-svn: 134273
CompilerInvocation on the stack, because other objects (e.g., the
CompilerInstance) maintain an intrusive reference-counted pointer to
the CompilerInvocation. This doesn't matter in the normal case,
because we take back the CompilerInvocation. However, during crash
recovery, this leads to us trying to free an object on the stack, and
hilarity ensues. Fixes <rdar://problem/9652540>.
llvm-svn: 134245
type/expression/template argument/etc. is instantiation-dependent if
it somehow involves a template parameter, even if it doesn't meet the
requirements for the more common kinds of dependence (dependent type,
type-dependent expression, value-dependent expression).
When we see an instantiation-dependent type, we know we always need to
perform substitution into that instantiation-dependent type. This
keeps us from short-circuiting evaluation in places where we
shouldn't, and lets us properly implement C++0x [temp.type]p2.
In theory, this would also allow us to properly mangle
instantiation-dependent-but-not-dependent decltype types per the
Itanium C++ ABI, but we aren't quite there because we still mangle
based on the canonical type in cases like, e.g.,
template<unsigned> struct A { };
template<typename T>
void f(A<sizeof(sizeof(decltype(T() + T())))>) { }
template void f<int>(A<sizeof(sizeof(int))>);
and therefore get the wrong answer.
llvm-svn: 134225
for a template template parameter.
Uses to follow.
I've also made the uniquing of SubstTemplateTemplateParmPacks
use a ContextualFoldingSet as a minor space efficiency.
llvm-svn: 134137
Previously macro expanded tokens were added to Preprocessor's bump allocator and never released,
even after the TokenLexer that were lexing them was finished, thus they were wasting memory.
A very "useful" boost library was causing clang to eat 1 GB just for the expanded macro tokens.
Introduce a special cache that works like a stack; a TokenLexer can add the macro expanded tokens
in the cache, and when it finishes, the tokens are removed from the end of the cache.
Now consumed memory by expanded tokens for that library is ~ 1.5 MB.
Part of rdar://9327049.
llvm-svn: 134105
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
This is a one line fix here:
+ // Don't print recursive instantiation notes from an instantiation note.
+ Loc = SM.getSpellingLoc(Loc);
While here, fix the testcase to be more precise (it got filecheck'ized
brutally), and fix EmitCaretDiagnostic to be private and to not pass down
the unused 'Level' argument.
llvm-svn: 133993
down to 8 by restricting the maximum allowed regparm value to 6
(previously it was 7). I need the extra bit in Type to handle
instantiation-dependence.
llvm-svn: 133924
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
llvm-svn: 133906
declaration, determine whether the declaration will end up declaring a
function using semantic criteria (e.g., it will have function type)
rather than purely syntactic criteria (e.g., it has the form of a
function declarator). Fixes <rdar://problem/9670557>.
llvm-svn: 133854
to turn off warning on those properties which follow Cocoa naming
convention for retaining objects and yet they were not meant for
such purposes. Also, perform consistancy checking for declared
getters of such methods. // rdar://9636091
llvm-svn: 133849
Sorry, this was a bad idea. Within clang these builtins are in a separate
"ARM" namespace, but the actual builtin names should clearly distinguish tha
they are target specific.
llvm-svn: 133833
This is the only usage in clang's headers, and it's for a define
that only exists on CMake builds for the sake of the MSVC compiler,
so just use an ifdef instead.
Also add an include for config.h in a file that actually needs it,
and was picking it up by accident indirectly.
llvm-svn: 133710
and into a new file, SemaExprMember.cpp, bringing SemaExpr.cpp just
under 10,000 lines of code (ugh). No functionality change, although I
intend to do some refactoring of this code to address PR8368 at some
point in the "near" future.
llvm-svn: 133674
lifetime is well-known and restricted, cleaning them up manually is easy to miss and cause a leak.
Use it to plug the leaking of TemplateIdAnnotation objects. rdar://9634138.
llvm-svn: 133610
lookup. Previously, it was breaking self-host, but it's been a week and
a half and I can't reproduce, so I need to see if it's still failing.
llvm-svn: 133581
use an "IgnoreSysRoot" argument. HeaderSearchOptions had been using the
opposite form with "IsSysRootRelative", which made for much confusion when
looking at true/false values in calls in AddPath. No functional change.
llvm-svn: 133550
The -cxx-isystem path is not prefixed with the sysroot directory, so it's
not a good way for the driver to set the system default C++ search path.
Instead, add -stdlib as a cc1 option and teach the frontend how to find the
headers. The driver can then just pass -stdlib through to "cc1".
llvm-svn: 133547
- Changes bit-field access policy to try to use (aligned) register sized accesses.
The idea here is that by using larger accesses we expose more coalescing
potential to the backend when we have situations like adjacent bit-fields in the
same structure (which is common), and that the backend should be smart enough to
narrow the accesses down when no coalescing is done or when it is shown not to
be profitable.
--
$ clang -m32 -O3 -S -o - t.c
_f0: ## @f0
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
movb (%eax), %cl
andb $-128, %cl
orb $1, %cl
movb %cl, (%eax)
movb 1(%eax), %cl
andb $-128, %cl
orb $1, %cl
movb %cl, 1(%eax)
movb 2(%eax), %cl
andb $-128, %cl
orb $1, %cl
movb %cl, 2(%eax)
movb 3(%eax), %cl
andb $-128, %cl
orb $1, %cl
movb %cl, 3(%eax)
popl %ebp
ret
$ clang -m32 -O3 -S -o - t.c -Xclang -fuse-register-sized-bitfield-access
_f0: ## @f0
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
movl $-2139062144, %ecx ## imm = 0xFFFFFFFF80808080
andl (%eax), %ecx
orl $16843009, %ecx ## imm = 0x1010101
movl %ecx, (%eax)
popl %ebp
ret
--
llvm-svn: 133532
MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given
const int& r = 1.0;
The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value.
IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.
llvm-svn: 133521
an assembly file it worked correctly, while for a .c file it would given an
error about how --noexecstack is not a supported argument to -Wa.
llvm-svn: 133489
This makes 'isPointerLikeType' a little less confusing, and pulls the
decay check into a separate interface that is much more clear and
concrete. Also, just implement these as logical wrappers around other
predicates. Having a switch based implementation isn't likely to be
necessary. We can try to optimize them later if they show up on
a profile.
llvm-svn: 133405
false positives, including those in the GCC test suite, and don't warn
about them.
Let me know if this causes fallout, we can turn it back off if needed.
llvm-svn: 133384
Trieu, and fix them by checking for array and function types as well as
pointer types.
I've added a predicate method on Type to bundle together the logic we're
using here: isPointerLikeType(). I'd welcome better names for this
predicate, this is the best I came up with. It's implemented as a switch
to be a touch lighter weight than all the chained isa<...> casts that
would result otherwise.
llvm-svn: 133383
deducing template parameter types. Recently Clang began enforcing the
more strict checking that the argument type and the deduced function
parameter type (after substitution) match, but that only consideres
qualification conversions.
One problem with this patch is that we check noreturn conversions and
qualification conversions independently. If a valid conversion would
require *both*, perhaps interleaved with each other, it will be
rejected. If this actually occurs (I'm not yet sure it does) and is in
fact a problem (I'm not yet sure it is), there is a FIXME to implement
more intelligent conversion checking.
However, this step at least allows Clang to resume accepting valid code
we're seeing in the wild.
llvm-svn: 133327
they should still be officially __strong for the purposes of errors,
block capture, etc. Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables. Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.
llvm-svn: 133243
storage specifier is different from the storage specifier on the
template. If that storage specifier is the same, then we only warn.
Thanks to John for the prodding.
llvm-svn: 133236
Douglas Gregor