Add extra sanity checking in FormatString::matchesType() that we are comparing integers to integers. This happens not to be an issue now, but the extra check helps future proof in case of future refactorings.
This is switches all the interfaces points (and most of the commenst
/ local variables I saw on my way through) regarding the
NestedMacroInstantiations bit.
The libclang enums corresponding to this state were renamed, but
a legacy enum was added with the old name, and the same value to keep
existing clients working. I've added a documentation blurb for it, but
let me know if there is a canonical way to document legacy elemenst of
the libclang interface.
Update all of the libclang code corresponding to the preprocessor
MacroInstantiation -> MacroExpansion rename. Internally, everything is
switched.
Introduce a new cursor kind enum with the new name, but retain the old
name as an alias so that we don't break backwards compatibility.
Also update the debug printing routine to use 'macro expansions' as its
explicitly not guaranteed to be stable, and mechanically switch the test
cases over to that.
Move the rest of the preprocessor terminology from 'instantiate' and
variants to 'expand'. This changed a couple of public APIs, including
one public type "MacroInstantiation" which is now "MacroExpansion". The
rest of the codebase was updated to reflect this, especially the
libclang code. Two of the C++ (and thus easily changed) libclang APIs
were updated as well because they pertained directly to the old
MacroInstantiation class.
Convert terminology in the Lexer from 'instantiate' and variants to
'expand'. Also update the public API it provides to the new term, and
propagate that update to the various clients.
Switch the TokenLexer's terminology from various forms of 'instantiate'
to 'expand' for macros. Only comments and uses local to the TokenLexer
are updated.
Douglas Gregor [Thu, 14 Jul 2011 04:54:23 +0000 (04:54 +0000)]
Add a hackaround to avoid the crash in PR10355. However, our recovery
is still terrible here because typo correction is not behaving well in
the presence of overloaded functions.
format string checking: long and int have the same widths on 32-bit, so we shouldn't warn about using
an "int" format specifier with a "long" type in 32-bit.
John McCall [Wed, 13 Jul 2011 20:12:57 +0000 (20:12 +0000)]
Enforce access control for the destructor in a new[] expression and mark
it as used. Otherwise, we can fail to instantiate or validate the destructor,
which can lead to crashes in IR gen like PR10351.
[arcmt] For properties rewrite 'assign' -> 'weak or unsafe_unretained', 'retain' -> 'strong', and add
'weak or unsafe_unretained' when 'assign' is missing. rdar://9496219&9602589.
With -Wselector, don't warn about unimplemented optional method
used in @selector expression because, well, their implementation
is optional. // rdar://9545564
John McCall [Wed, 13 Jul 2011 17:56:40 +0000 (17:56 +0000)]
In debugger mode, make ObjC message sends to unknown selectors return
__unknown_anytype, and rewrite such message sends correctly.
I had to bite the bullet and actually add a debugger support mode for this
one, which is a bit unfortunate, but there really isn't anything else
I could imagine doing; this is clearly just debugger-specific behavior.
objc++: Some level of covariance is allowed in ObjC properties.
Make it also available in ObjC++ propeties. Use common code for
objc and objc++ so they don't diverge. // rdar://9740328
Chris Lattner [Wed, 13 Jul 2011 05:31:19 +0000 (05:31 +0000)]
per john's advice, speculatively lower uses of forward-declared enums to
i32. They almost always end up this way in the end anyway, and if we get
lucky, this avoids generating some bitcasts.
Douglas Gregor [Wed, 13 Jul 2011 02:14:02 +0000 (02:14 +0000)]
Eliminate an incomplete/incorrect attempt to provide support for C++0x
unrestricted unions, which ended up attempting to initialize objects
in a union (which CodeGen isn't prepared for). Fixes PR9683.
Eli Friedman [Wed, 13 Jul 2011 02:05:57 +0000 (02:05 +0000)]
Silliness with commas, as reported at http://blog.regehr.org/archives/558 . As it turns out, this is my fault for not noticing this was an issue when I was looking at this a long time ago. :(
Douglas Gregor [Wed, 13 Jul 2011 00:54:47 +0000 (00:54 +0000)]
When compiling ::delete for a class with a virtual destructor, call
the complete destructor and then invoke the global delete
operator. Previously, we would invoke the deleting destructor, which
calls the wrong delete operator. Fixes PR10341.
Richard Smith [Tue, 12 Jul 2011 23:49:11 +0000 (23:49 +0000)]
Correctly set up the list of virtual base classes for a CXXRecordDecl. Previously we got the source range wrong for everything in the virtual bases list.
[arcmt] Before applying '__weak' check whether the objc class is annotated with objc_arc_weak_reference_unavailable
or is in a list of classes not supporting 'weak'.
Douglas Gregor [Tue, 12 Jul 2011 17:28:52 +0000 (17:28 +0000)]
In ARC mode, consider Objective-C lifetime types (object pointers and
block pointers) that don't have any qualification to be POD types. We
were previously considering them to be non-POD types, because this was
convenient in C++ for is_pod-like traits. However, we now end up
inferring lifetime in such cases (template arguments infer __strong),
so it is not necessary.
Moreover, we want rvalues of object type (which have their lifetime
stripped) to be PODs to allow, e.g., va_arg(arglist, id) to function
properly. Fixes <rdar://problem/9758798>.
Fix a bug where a local variable named 'self' is causing
implicit ivar accesses to go through the 'self' variable
rather than the real 'self' for the method. // rdar://9730771
Douglas Gregor [Tue, 12 Jul 2011 15:18:55 +0000 (15:18 +0000)]
Improve name mangling for instantiation-dependent types that are not
dependent. This covers an odd class of types such as
int (&)[sizeof(sizeof(T() + T()))];
which involve template parameters but, because of some trick typically
involving a form of expression that is never type-dependent, resolve
down to a non-dependent type. Such types need to be mangled
essentially as they were written in the source code (involving
template parameters), rather than via their canonical type.
In general, instantiation-dependent types should be mangled as
they were written in the source. However, since we can't do that now
without non-trivial refactoring of the AST (see the new FIXME), I've
gone for this partial solution: only use the as-written-in-the-source
mangling for these strange types that are instantiation-dependent but
not dependent. This provides better compatibility with previous
incarnations of Clang and with GCC. In the future, we'd like to get
this right.
Work around a problem with a static helper's formulation in release
builds introduced in r134972:
lib/CodeGen/CGExpr.cpp:1294:7: error: no matching function for call to 'EmitBitCastOfLValueToProperType'
lib/CodeGen/CGExpr.cpp:1278:1: note: candidate function not viable: no known conversion from 'CGBuilderTy' (aka 'IRBuilder<false>') to 'llvm::IRBuilder<> &' for 1st argument
This fixes the issue by passing CodeGenFunction on down, and using its
builder directly rather than passing just the builder down.
This may not be the best / cleanest fix, Chris please review. It at
least fixes builds.
Douglas Gregor [Tue, 12 Jul 2011 06:55:29 +0000 (06:55 +0000)]
Fix the desugaring of dependent decltype and typeof(expr) nodes. The
isSugared() and desugar() routines previously provided were never
actually called, since the corresponding types
(DependentTypeOfExprType, DependentDecltypeType) don't have
corresponding type classes. Outside of the current (incomplete) patch
I'm working on, I haven't found a way to trigger this problem.
Chris Lattner [Tue, 12 Jul 2011 06:52:18 +0000 (06:52 +0000)]
Fix a problem Eli ran into where we now reject incomplete arrays of
uncompleted struct types. We now do what llvm-gcc does and compile
them into [i8 x 0]. If the type is later completed, we make sure that
it is appropriately cast.
We compile the terrible example to something like this now:
%struct.A = type { i32, i32, i32 }
@g = external global [0 x i8]
define void @_Z1fv() nounwind {
entry:
call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*))
ret void
}
declare void @_Z3fooP1A(%struct.A*)
define %struct.A* @_Z2f2v() nounwind {
entry:
ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1)
}
[ARC] Complain about property without storage attribute when @synthesizing it, not at its declaration.
For this sample:
@interface Foo
@property id x;
@end
we get:
t.m:2:1: error: ARC forbids properties of Objective-C objects with unspecified storage attribute
@property id x;
^
1 error generated.
The error should be imposed on the implementor of the interface, not the user. If the user uses
a header of a non-ARC library whose source code he does not have, we are basically asking him to
go change the header of the library (bad in general), possible overriding how the property is
implemented if he gets confused and says "Oh I'll just add 'copy' then" (even worse).
Second issue is that we don't emit any error for 'readonly' properties, e.g:
@interface Foo
@property (readonly) id x; // no error here
@end
@implementation Foo
@synthesize x; // no error here too
@end
We should give an error when the implementor is @synthesizing a property which doesn't have
any storage specifier; this is when the explicit specifier is important, because we are
going to create an ivar and we want its ownership to be explicit.
Related improvements:
-OBJC_PR_unsafe_unretained turned out to not fit in ObjCPropertyDecl's bitfields, fix it.
-For properties of extension classes don't drop PropertyAttributesAsWritten values.
-Have PropertyAttributesAsWritten actually only reflect what the user wrote
Bill Wendling [Tue, 12 Jul 2011 01:16:47 +0000 (01:16 +0000)]
Revert r134888 (and related patches in other trees). It was causing
an assert on Darwin llvm-gcc builds.
Assertion failed: (castIsValid(op, S, Ty) && "Invalid cast!"), function Create, file /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.llvm-gcc-i386-darwin9-RA/llvm.src/lib/VMCore/Instructions.cpp, line 2067.
etc.
Fix one x86_64 abi issue and the test to actually look for the right thing,
which is: { <4 x float>, <4 x float> } should continue to go through memory.
Disable avx feature from corei7-avx, and use -mavx for now. Right now, if -mavx is
specified, 128 avx code is used and we're not sure yet if this the behavior
we want (and if it does, some improvements are needed before relying on it).
projects / clang / log