| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 133501
|
| |
|
|
|
|
|
| |
message sent to an objc method (or property access)
// rdar://9474349
llvm-svn: 133469
|
| |
|
|
|
|
| |
Patch by Henry Mason with tweaks by me.
llvm-svn: 133453
|
| |
|
|
|
|
|
|
|
| |
(or follow up) extern declaration with weak_import as
an actual definition. make clang follows this behavior.
// rdar://9538608
llvm-gcc treats an extern declaration with weak_import
llvm-svn: 133450
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 133418
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
silently dropped ownership qualifiers that were being applied to
ownership-qualified, substituted type that was *not* a substituted
template type parameter. We now provide a diagnostic in such cases,
and recover by dropping the added qualifiers.
Document this behavior in the ARC specification.
llvm-svn: 133309
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ownership-unqualified retainable object type as __strong. This allows
us to write, e.g.,
std::vector<id>
and we'll infer that the vector's element types have __strong
ownership semantics, which is far nicer than requiring:
std::vector<__strong id>
Note that we allow one to override the ownership qualifier of a
substituted template type parameter, e.g., given
template<typename T>
struct X {
typedef __weak T type;
};
X<id> is treated the same as X<__strong id>. At instantiation type,
the __weak in "__weak T" overrides the (inferred or specified)
__strong on the template argument type, so that we can still provide
metaprogramming transformations.
This is part of <rdar://problem/9595486>.
llvm-svn: 133303
|
| |
|
|
|
|
|
|
| |
-O0 compile-time regressions from r133196.
rdar://9629775 .
llvm-svn: 133290
|
| |
|
|
| |
llvm-svn: 133264
|
| |
|
|
| |
llvm-svn: 133257
|
| |
|
|
| |
llvm-svn: 133246
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
[temp.deduct.call]p4 to the deduction performed for 'auto', finishing
the fix for PR9233.
llvm-svn: 133239
|
| |
|
|
|
|
|
| |
argument type for C++ [temp.deduct.call]p4 out of
Sema::FinishTemplateArgumentDeduction(). No functionality change.
llvm-svn: 133237
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
specifier on an explicit specialization to a warning, since neither
EDG nor GCC diagnose this code as ill-formed.
llvm-svn: 133232
|
| |
|
|
|
|
|
| |
operators, don't make an initializer or sub-operation for zero-width
bitfields.
llvm-svn: 133221
|
| |
|
|
|
|
| |
through an ellipsis. Fixes <rdar://problem/9623945>.
llvm-svn: 133219
|
| |
|
|
| |
llvm-svn: 133215
|
| |
|
|
|
|
|
| |
(even though it is incomplete type) because gcc
says so. // rdar://9622422
llvm-svn: 133208
|
| |
|
|
|
|
|
|
| |
The warning will fire on cases such as:
int x = 1 + NULL;
llvm-svn: 133196
|
| |
|
|
|
|
| |
constants. Fixes PR10145.
llvm-svn: 133179
|
| |
|
|
|
|
|
|
|
| |
__builtin_ versions of these functions as well as the normal function
versions, so that it works on platforms where memset/memcpy/memmove
are macros that map down to the builtins (e.g., Darwin). Fixes
<rdar://problem/9372688>.
llvm-svn: 133173
|
| |
|
|
|
|
| |
null at any time. // rdar://9612030
llvm-svn: 133168
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checks that the deduced argument type for a function call matches the
actual argument type provided. The only place we've found where the
consistency checking should actually cause template argument deduction
failure is due to qualifier differences that don't fall into the realm
of qualification conversions (which are *not* checked when we
initially perform deduction). However, we're performing the full
checking as specified in the standard to ensure that no other cases
exist.
Fixes PR9233 / <rdar://problem/9039590>.
llvm-svn: 133163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and the programmer intended to write 'sizeof(*p)'. There are several
elements to the new version:
1) The actual expressions are compared in order to more accurately flag
the case where the pattern that works for an array has been used, or
a '*' has been omitted.
2) Only do a loose type-based check for record types. This prevents us
from warning when we happen to be copying around chunks of data the
size of a pointer and the pointer types for the sizeof and
source/dest match.
3) Move all the diagnostics behind the runtime diagnostic filter. Not
sure this is really important for this particular diagnostic, but
almost everything else in SemaChecking.cpp does so.
4) Make the wording of the diagnostic more precise and informative. At
least to my eyes.
5) Provide highlighting for the two expressions which had the unexpected
similarity.
6) Place this diagnostic under a flag: -Wsizeof-pointer-memaccess
This uses the Stmt::Profile system for computing #1. Because of the
potential cost, this is guarded by the warning flag. I'd be interested
in feedback on how bad this is in practice; I would expect it to be
quite cheap in practice. Ideas for a cheaper / better way to do this are
also welcome.
The diagnostic wording could likely use some further wordsmithing.
Suggestions welcome here. The goals I had were to: clarify that its the
interaction of 'memset' and 'sizeof' and give more reasonable
suggestions for a resolution.
An open question is whether these diagnostics should have the note
attached for silencing by casting the dest/source pointer to void*.
llvm-svn: 133155
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
argument types for mem{set,cpy,move}. Character pointers, much like void
pointers, often point to generic "memory", so trying to check whether
they match the type of the argument to 'sizeof' (or other checks) is
unproductive and often results in false positives.
Nico, please review; does this miss any of the bugs you were trying to
find with this warning? The array test case you had should be caught by
the array-specific sizeof warning I think.
llvm-svn: 133136
|
| |
|
|
|
|
| |
complaining about mismatches in the global method pool.
llvm-svn: 133123
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 133120
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
were just punting on template argument deduction for a number of type
nodes. Most of them, obviously, didn't matter.
As a consequence of this, make extended vector types (via the
ext_vector_type attribute) actually work properly for several
important cases:
- If the attribute appears in a type-id (i.e, not attached to a
typedef), actually build a proper vector type
- Build ExtVectorType whenever the size is constant; previously, we
were building DependentSizedExtVectorType when the size was constant
but the type was dependent, which makes no sense at all.
- Teach template argument deduction to handle
ExtVectorType/DependentSizedExtVectorType.
llvm-svn: 133060
|
| |
|
|
| |
llvm-svn: 133056
|
| |
|
|
|
|
|
|
|
|
| |
before the template parameters have acquired a proper context (e.g.,
because the enclosing context has yet to be built), provide empty
parameter lists for all outer template parameter scopes to inhibit any
substitution for those template parameters. Fixes PR9643 /
<rdar://problem/9251019>.
llvm-svn: 133055
|
| |
|
|
|
|
|
| |
either imlicitly (for builtins) or explicitly (due to multiple
specification of the same attributes). Fixes <rdar://problem/9612060>.
llvm-svn: 133045
|
| |
|
|
|
|
|
| |
protected in the case where a variable is being initialized by a
trivial default constructor but has a non-trivial destructor.
llvm-svn: 133037
|
| |
|
|
| |
llvm-svn: 133036
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
inference, to be used (only) by the Objective-C rewriter.
llvm-svn: 133025
|
| |
|
|
| |
llvm-svn: 132996
|
| |
|
|
|
|
|
|
|
|
| |
folded to a constant
as constant size arrays. This has slightly different semantics in some insane cases, but allows
us to accept some constructs that GCC does. Continue to be pedantic in -std=c99 and other
modes. This addressed rdar://8733881 - error "variable-sized object may not be initialized"; g++ accepts same code
llvm-svn: 132983
|
| |
|
|
|
|
| |
as an extension.
llvm-svn: 132980
|
| |
|
|
|
|
|
| |
- 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
|
| |
|
|
| |
llvm-svn: 132975
|