(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
This warns in two specific situations:
1) For potentially swapped function arguments, e.g.
void foo(bool, float);
foo(1.7, false);
2) Misplaced brackets around function call arguments, e.g.
bool InRange = fabs(a - b < delta);
Where the last argument in a function call is implicitly converted
from bool to float, and the function returns a float which gets
implicitly converted to bool.
Patch by Andreas Eckleder!
llvm-svn: 162763
function arguments and arguments for variadic functions are of a particular
type which is determined by some other argument to the same function call.
Usecases include:
* MPI library implementations, where these attributes enable checking that
buffer type matches the passed MPI_Datatype;
* for HDF5 library there is a similar usecase as MPI;
* checking types of variadic functions' arguments for functions like
fcntl() and ioctl().
llvm-svn: 162067
and remove ASTContext reference (which was frequently bound to a dereferenced
null pointer) from the recursive lump of printPretty functions. In so doing,
fix (at least) one case where we intended to use the 'dump' mode, but that
failed because a null ASTContext reference had been passed in.
llvm-svn: 162011
tablegen code, found by -fcatch-undefined-behavior. I would appreciate if
someone more familiar with the NEON code could point me in the direction of how
to write a test for this. We appear to have essentially no test coverage
whatsoever for these builtins.
llvm-svn: 161827
This is useful for example for %n in printf, which expects
a pointer to int with the same logic for checking as %d
would have in scanf.
llvm-svn: 161407
The one caller that's surrounded by nearby code manipulating the underlying
evaluation context list is left unmodified for readability.
Review by Sean Silva and Richard Smith.
llvm-svn: 161355
While '%n' can be used for evil in an attacker-controlled format string, there
isn't any acute danger in using it in a literal format string with an argument
of the appropriate type.
llvm-svn: 160984
While we still want to consider this a hard error (non-POD variadic args are
normally a DefaultError warning), delaying the diagnostic allows us to give
better error messages, which also match the usual non-POD errors more closely.
In addition, this change improves the diagnostic messages for format string
argument type mismatches by passing down the type of the callee, so we can
say "variadic method" or "variadic function" appropriately.
<rdar://problem/11825593>
llvm-svn: 160517
Previously, we would ask for the SourceLocation of an argument even if
it were NULL (i.e. if Sema resulted in an ExprError trying to build it).
<rdar://problem/11890818>
llvm-svn: 160515
resulted in it being reverted. A test for that bug was added in r158950.
Original comment:
If an object (such as a std::string) with an appropriate c_str() member function
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
llvm-svn: 159159
Revert "If an object (such as a std::string) with an appropriate c_str() member function"
This reverts commit 7d96f6106bfbd85b1af06f34fdbf2834aad0e47e.
llvm-svn: 158949
This now correctly covers, I believe, all the pointer types:
* 'any' pointers (both function and data normal pointers and ObjC object pointers)
* member pointers (both function and data)
* block pointers
llvm-svn: 158931
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
llvm-svn: 158887
Within the guts of CheckFormatHandler, the IsObjCLiteral flag was being used in
two ways: to see if null bytes were allowed, and to see if the '%@' specifier
is allowed.* The former usage has been changed to an explicit test and the
latter pushed down to CheckPrintfHandler and renamed ObjCContext, since it
applies to CFStrings as well.
* This also changes how wide chars are interpreted; in OS X Foundation, the
wide character type is 'unichar', a typedef for short, rather than wchar_t.
llvm-svn: 157968
about argument type mismatch.
This gives a nicer diagnostic in cases like
printf(fmt,
i);
where previously the snippet just pointed at 'fmt' (with a note at the
definition of fmt).
It's a wash for cases like
printf("%f",
i);
where previously we snippeted the offending portion of the format string,
but didn't indicate which argument was at fault.
llvm-svn: 156968
This fixes the included test case & was reported by Nico Weber.
It's a little bit nasty using the difference in the conversion context, but
seems to me like a not unreasonable solution. I did have to fix up the
conversion context for conditional operators (it seems correct to me to include
the context for which we're actually doing the comparison - across all the
nested conditionals, rather than the innermost conditional which might not
actually have the problematic implicit conversion at all) and template default
arguments (this is a bit of a hack, since we don't have the source location of
the '=' anymore, so I just used the start of the parameter - open to
suggestions there)
llvm-svn: 156861
Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.
Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.
llvm-svn: 156826
getTypeSourceInfo() without checking for NULL.
FieldDecls may have NULL TypeSourceInfo, and in
fact some FieldDecls generated by Clang -- and
all FieldDecls generated by LLDB -- have no
TypeSourceInfo.
This patch makes IsTailPaddedMemberArray check
for NULL.
llvm-svn: 156186
off PartialDiagnostic. PartialDiagnostic is rather heavyweight for
something that is in the critical path and is rarely used. So, switch
over to an abstract-class-based callback mechanism that delays most of
the work until a diagnostic is actually produced. Good for ~11k code
size reduction in the compiler and 1% speedup in -fsyntax-only on the
code in <rdar://problem/11004361>.
llvm-svn: 156176
Teach ASTContext about WIntType, and have it taken from TargetInfo like WCharType. Should fix test/Sema/format-strings.c for ARM, with the exception of one subtest which will fail if wint_t and wchar_t are the same size and wint_t is signed, wchar_t is unsigned.
There'll be a followup commit to fix that.
Reviewed by Chandler and Hans at http://llvm.org/reviews/r/8
llvm-svn: 156165
Some of the NSAssert macros in OS X 10.7 are implemented in a way that
adds extra arguments that trigger the -Wformat-extra-args warning.
Earlier versions of clang failed to detect those -Wformat issues, but now
that clang is reporting those problems, we need to quiet them since there's
nothing to be done to fix them. <rdar://problem/11317765>
I don't know how to write a testcase for this. Suggestions welcome.
Patch by Ted Kremenek!
llvm-svn: 156092
of a local variable, make sure we don't infinitely recurse when the
reference binds to itself.
e.g:
int* func() {
int& i = i; // assign non-exist variable to a reference which has same name.
return &i; // return pointer
}
rdar://11345441
llvm-svn: 155856
i32 __builtin_annotation(i32, string);
Applying it to i64 (e.g., long long) generates the following IR.
trunc i64 {{.*}} to i32
call i32 @llvm.annotation.i32
zext i32 {{.*}} to i64
The redundant truncation and extension make the result difficult to use.
This patch makes __builtin_annotation() generic.
type __builtin_annotation(type, string);
For the i64 example, it simplifies the generated IR to:
call i64 @llvm.annotation.i64
Patch by Xi Wang!
llvm-svn: 155764
Eli Friedman