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
of: a + b ? x : y. In our testing of this flag we've yet to hit a single
case where the existing precedence was correct, so we should suggest
grouping the ?: first.
llvm-svn: 133526
pointers I found while working on the NULL arithmetic warning. We here
always assuming the LHS was the pointer, instead of using the selected
pointer expression.
llvm-svn: 133428
effectively that this abstraction simply doesn't exist. That is
highlighted by the fact that by using it we were papering over a more
serious error in this warning: the fact that we warned for *invalid*
constructs involving member pointers and block pointers.
I've fixed the obvious issues with the warning here, but this is
confirming an original suspicion that this warning's implementation is
flawed. I'm looking into how we can implement this more reasonably. WIP
on that front.
llvm-svn: 133425
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
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
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
C++, which means:
- binding the temporary as needed in Sema, so that we generate the
appropriate call to the destructor, and
- emitting the compound literal into the appropriate location for
the aggregate, rather than trying to emit it as a temporary and
memcpy() it.
Fixes PR10138 / <rdar://problem/9615901>.
llvm-svn: 133235
be more consistent in how parenthesized ranges which hit macros are
handled. Also makes the code significantly shorter, and the diagnostics
when macros are present a bit more useful.
Pair programmed w/ Matthew.
llvm-svn: 133122
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
Change the output for -Wshift-overflow and
-Wshift-sign-overflow to an unsigned hexadecimal. It makes
more sense for looking at bits than a signed decimal does.
Also, change the diagnostic's wording from "overrides"
to "sets".
This uses a new optional argument in APInt::toString()
that adds the '0x' prefix to hexademical numbers.
This fixes PR 9651.
Patch by nobled@dreamwidth.org!
llvm-svn: 133033
- Move a test from test/SemaTemplate/instantiate-expr-3.cpp, it did not belong there
- Incomplete and abstract types are considered hard errors
llvm-svn: 132979
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
This is a follow-up to r132565, and should address the rest of PR9969:
Warn about cases such as
int foo(A a, bool b) {
return a + b ? 1 : 2; // user probably meant a + (b ? 1 : 2);
}
also when + is an overloaded operator call.
llvm-svn: 132784
__builtin_astype(): Used to reinterpreted as another data type of the same size using for both scalar and vector data types.
Added test case.
llvm-svn: 132612
Warn in cases such as "x + someCondition ? 42 : 0;",
where the condition expression looks arithmetic, and has
a right-hand side that looks boolean.
This (partly) addresses http://llvm.org/bugs/show_bug.cgi?id=9969
llvm-svn: 132565
I tried to use an assert to prove that I could remove each of the
arguments I did, but ended up writing my assert with inverted logic.
Doh! Reported by Xi Wang on cfe-dev. I have manually verified the source
locations and ranges for these using -ast-dump. I tried writing a test
case that would catch these, but these expressions aren't exposed in the
c-index-test's token annotation utility.
llvm-svn: 132284
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:
template <typename T> struct S {
static const int arr[];
static const int x;
static int f();
};
template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }
int x = S<int>::f();
We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.
This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?
llvm-svn: 132172
provide re-usable forms of the rest of the custom validation done here.
Still no functionality changed here.
With this it should be possible to have an expression-centric code path
and a type-centric code path which don't duplicate logic.
llvm-svn: 132118
traits which uses the information embedded in the expression. Use this
to simplify several interfaces which repeated information embedded in
the expression through explicit arguments. I added an assertion that the
only extra piece of data to come in from the parser matches what is
stored in the expression. No functionality change intended here.
Also cleaned up the doxygen comments for some of these methods and some
formatting oddities.
llvm-svn: 132115
non-POD/non-trivial object throuugh a C-style varargs. The warning
itself was default-mapped to error, but can be downgraded, but we were
treating it in Sema like a hard error, silently dropping the call.
Instead, treat this problem like a warning, and do what the warning
says we do: abort at runtime. To do so, we fake up a __builtin_trap()
expression that gets evaluated as part of the argument.
llvm-svn: 131805
defaulted default constructors.
As it happens, making sure that we handle out-of-line defaulted
functions properly will involved making sure that we actually parse them
correctly, so that's coming after.
llvm-svn: 131224
Argyrios Kyrtzidis