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
pretty. In particular this makes it much easier for me to read messages
such as:
x.cc:42: ?: has lower ...
Where I'm inclined to associate the third ':' with a missing column
number, but in fact column numbers have been turned off. Similar
punctuation collisions happened elsewhere as well.
llvm-svn: 133121
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
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
- (bounded copies) Be more conservative about how much is being copied.
- (str(n)cat) If we can't compute the exact final length of an append operation, we can still lower-bound it.
- (stpcpy) Fix the conjured return value at the end to actually be returned.
This requires these supporting changes:
- C string metadata symbols are still live even when buried in a SymExpr.
- "Hypothetical" C string lengths, to represent a value that /will/ be passed to setCStringLength() if all goes well. (The idea is to allow for temporary constrainable symbols that may end up becoming permanent.)
- The 'checkAdditionOverflow' helper makes sure that the two strings being appended in a strcat don't overflow size_t. This should never *actually* happen; the real effect is to keep the final string length from "wrapping around" in the constraint manager.
This doesn't actually test the "bounded" operations (strncpy and strncat) because they can leave strings unterminated. Next on the list!
llvm-svn: 133046
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
in a noexcept exception specification because it isn't part of the
canonical type. This ensures that we keep the exact expression written
in the noexcept exception specification, rather than accidentally
"adopting" a previously-written and canonically "equivalent" function
prototype. Fixes PR10087.
llvm-svn: 132998
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
- 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
This patch tries relatively hard to avoid creating an extra copy if it can be avoided (see test3 in the included testcase), but it is not possible to avoid in some cases (like test2 in the included testcase).
rdar://9483886
llvm-svn: 132957
- Move the diagnostic to the case statement instead of at the end of the switch
- Add a fix-it hint as to how to fix the compilation error
llvm-svn: 132903
struct {
typedef int A = 0;
};
According to the C++11 standard, this is not ill-formed, but does not have any ascribed meaning. We can't reasonably accept it, so treat it as ill-formed.
Also switch C++ from an incorrect 'fields can only be initialized in constructors' diagnostic for this case to C's 'illegal initializer (only variables can be initialized)'
llvm-svn: 132890
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
Also, have Environment stop looking through NoOp casts; it didn't match the behavior of LiveVariables. And once that's gone, the whole cast block of that switch is unnecessary.
llvm-svn: 132840
- Removed fix-it hints from template instaniations since changes to the
templates are rarely helpful.
- Changed the caret in template instaniations from the class/struct name to the
class/struct keyword, matching the other warnings.
- Do not offer fix-it hints when multiple declarations disagree. Warnings are
still given.
- Once a definition is found, offer a fix-it hint to all previous declarations
with wrong tag.
- Declarations that disagree with a previous definition will get a fix-it hint
to change the declaration.
llvm-svn: 132831
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
namespace set algorithm (re-)introduced. We may not have seen the 'std'
namespace, but we should still suggested associated namespaces. Easy
fix, but a bit annoying to test.
llvm-svn: 132744
specializations within an explicit instantiation to default to off
(enabled by -pedantic). Nobody else seem to implement C++
[temp.explicit]p3. Fixes PR10093.
llvm-svn: 132704
specializing a member of an unspecialized template, and recover from
such errors without crashing. Fixes PR10024 / <rdar://problem/9509761>.
llvm-svn: 132677
compared even when one is a reference binding and the other is not
(<rdar://problem/9173984>), but the definition of an identity sequence
does not involve lvalue-to-rvalue adjustments (PR9507). Fix both
inter-related issues.
llvm-svn: 132660
return <expression> ;
in blocks with a 'void' result type, so long as <expression> has type
'void'. This follows the rules for C++ functions.
llvm-svn: 132658
with a type-dependent expression, infer the placeholder type
'Context.DependentTy' to indicate that this is just a
placeholder. Fixes PR9982 / <rdar://problem/9486685>.
llvm-svn: 132657
__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
In code such as "char* volatile const j()", Clang warns that "volatile
const" will be ignored. Make it point to the first ignored qualifier,
and simplify the code a bit.
llvm-svn: 132563
Douglas Gregor