thoughtfully with incompatible pointers. This includes:
- Emit a diagnostic when two pointers aren't compatible!
- Promote one of the pointers/integers so we maintain the invariant expected by the
code generator (i.e. that the left/right types match).
- Upgrade the pointer/integer comparison diagnostic to include the types.
llvm-svn: 41127
family of functions. Previous functionality only included checking to
see if the format string was a string literal. Now we check parse the
format string (if it is a literal) and perform the following checks:
(1) Warn if: number conversions (e.g. "%d") != number data arguments.
(2) Warn about missing format strings (e.g., "printf()").
(3) Warn if the format string is not a string literal.
(4) Warn about the use se of '%n' conversion. This conversion is
discouraged for security reasons.
(5) Warn about malformed conversions. For example '%;', '%v'; these
are not valid.
(6) Warn about empty format strings; e.g. printf(""). Although these
can be optimized away by the compiler, they can be indicative of
broken programmer logic. We may need to add additional support to
see when such cases occur within macro expansion to avoid false
positives.
(7) Warn if the string literal is wide; e.g. L"%d".
(8) Warn if we detect a '\0' character WITHIN the format string.
Test cases are included.
llvm-svn: 41076
"I've coded up some support in clang to flag warnings for non-constant format strings used in calls to printf-like functions (all the functions listed in "man fprintf"). Non-constant format strings are a source of many security exploits in C/C++ programs, and I believe are currently detected by gcc using the flag -Wformat-nonliteral."
llvm-svn: 41003
to Sema::ParseParamDeclarator(). After discussing this with Chris, we decided this
approach has more immediate benefit (though we loose some information in the AST).
The comment below should describe more (if interested).
llvm-svn: 40907
[dylan:clang/test/Parser] admin% ../../../../Debug/bin/clang -parse-ast-check typeof.c
Warnings expected but not seen:
Line 21: incompatible types assigning 'typeof(*pi) const' to 'int *'
Warnings seen but not expected:
Line 21: incompatible types assigning 'typeof(*pi) const' to 'int *'
Also corrected a typo from my previous commit.
llvm-svn: 40832
This resulted in the following error...
[dylan:clang/test/Parser] admin% cat parmvardecl_conversion.c
// RUN: clang -parse-ast-check %s
void f (int p[]) { p++; }
[dylan:clang/test/Parser] admin% clang -parse-ast-check parmvardecl_conversion.c
Errors seen but not expected:
Line 3: cannot modify value of type 'int []'
With this fix, the test case above succeeds.
llvm-svn: 40831
Chris suggested this, since it simplifies the code generator.
If this features is needed (and we don't think it is), we can revisit.
The following test case now produces an error.
[dylan:~/llvm/tools/clang] admin% cat t.c
typedef __attribute__(( ocu_vector_type(4) )) float float4;
static void test() {
float4 vec4;
vec4.rg.g;
vec4.rg[1];
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang t.c
t.c:8:12: error: vector component access limited to variables
vec4.rg.g;
^~
t.c:9:12: error: vector component access limited to variables
vec4.rg[1];
^~~
2 diagnostics generated.
llvm-svn: 40795
- Changed the name of ASTContext::getTypeOfType(Expr*)->getTypeOfExpr().
- Remove FIXME for TypeOfExpr::getAsStringInternal(). This will work fine for printing the AST. It isn't ideal
for error diagnostics (since it's more natural to display the expressions type).
One "random" (or at least delayed:-) change...
- Changed all "ext_typecheck_*" diagnostics from EXTENSION->WARNING. Reason: Since -pedantic is now
off (by default), these diagnostics were never being emitted (which is bad). With this change, clang will
emit the warning all the time. The only downside (wrt GCC compatibility) is -pedantic-errors will not turn
this diagnostics into errors (a "feature" of making tagging them with EXTENSION). When/if this becomes
an issue, we can revisit.
llvm-svn: 40676
For example, before this commit, the following diagnostics would be emitted...
ocu.c:49:12: error: incompatible types assigning 'float __attribute__((ocu_vector_type(3)))' to 'float4'
vec4_2 = vec4.rgb; // shorten
~~~~~~ ^ ~~~~~~~~
ocu.c:51:7: error: incompatible types assigning 'float __attribute__((ocu_vector_type(2)))' to 'float'
f = vec2.xx; // shorten
~ ^ ~~~~~~~
Now, the diagnostics look as you would expect...
ocu.c:49:12: error: incompatible types assigning 'float3' to 'float4'
vec4_2 = vec4.rgb; // shorten
~~~~~~ ^ ~~~~~~~~
ocu.c:51:7: error: incompatible types assigning 'float2' to 'float'
f = vec2.xx; // shorten
~ ^ ~~~~~~~
llvm-svn: 40579
#include <stdio.h>
int
main(void) {
int test = 0;
printf("Type is %s\n", (test >= 1 ? "short" : "char"));
return (0);
}
It comes up with a diagnostic that's misleading upon first read.
t.c:7:36: error: incompatible operand types ('char *' and 'char *')
printf("Type is %s\n", (test >= 1 ? "short" : "char"));
^ ~~~~~~~ ~~~~~~
1 diagnostic generated.
llvm-svn: 40526
- Added source range support to Diag's.
- Used the new type predicate API to remove dealing with the canonical
type explicitly.
- Added Type::isRecordType().
- Removed some casts.
- Removed a const qualifier from RecordType::getDecl().
llvm-svn: 40508
1. Fix a todo in Parser::ParseTag, to recover better. On code like
that in test/Sema/decl-invalid.c it causes us to return a single
error instead of multiple.
2. Fix an error in Sema::ParseDeclarator, where it would crash if the
declarator didn't have an identifier. Instead, diagnose the problem.
3. Start adding infrastructure to track the range of locations covered
by a declspec or declarator. This is mostly implemented for declspec,
but could be improved, it is missing for declarator.
Thanks to Neil for pointing out this crash.
llvm-svn: 40482
This resulted in the following errors when compiling promote_types_in_proto.c test...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang test/Parser/promote_types_in_proto.c
test/Parser/promote_types_in_proto.c:7:24: error: incompatible types passing 'char *[]' to function expecting 'char *const []'
arrayPromotion(argv);
~~~~~~~~~~~~~~ ^~~~
test/Parser/promote_types_in_proto.c:8:27: error: incompatible types passing 'void (char *const [])' to function expecting 'void (char *const [])'
functionPromotion(arrayPromotion);
~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~
2 diagnostics generated.
When fixing this, noticed that both ParseCallExpr() and ParseReturnStmt() were prematurely comparing types for
equivalence. This is incorrect (since the expr. promotions haven't been done yet). To fix this, I moved the
check "down" to Sema::CheckAssignmentConstraints().
I also converted Type::isArrayType() to the modern API (since I needed it). Still more Type predicates to
convert.
llvm-svn: 40475
a bit nicer for people who pass lots of extra arguments to calls by
selecting them all instead of just the first one:
arg-duplicate.c:13:13: error: too many arguments to function
f3 (1, 1, 2, 3, 4); // expected-error {{too many arguments to function}}
^~~~~~~
This implements test/Sema/arg-duplicate.c, thanks to Neil for pointing
out this crash.
llvm-svn: 40136
1) fix a crash on test/Sema/default.c by making
sure that the switch scope is non-null.
2) if there is an error sema'ing a default or case stmt,
make sure to return the substmt up, so that the error
recovery code has more acurate info to continue with.
llvm-svn: 40134
We still need to do sematic analysis (and implement initializers), however this
should complete the parsing & ast building for compound literals.
llvm-svn: 40067
Before this commit, we crashed in ParseBinOp...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang -parse-ast-check compound_literal.c
SemaExpr.cpp:1298: failed assertion `(rhs != 0) && "ParseBinOp(): missing right expression"'
With this commit, we still crash in the newly added action ParseCompoundLiteral (which is progress:-)
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang -parse-ast-check compound_literal.c
SemaExpr.cpp:478: failed assertion `(Op != 0) && "ParseCompoundLiteral(): missing expression"'
The crash go away once the actions return AST nodes. I will do this in a separate commit.
llvm-svn: 40032
- added ocu_vector_type attribute, Sema::HandleOCUVectorTypeAttribute().
- added new AST node, OCUVectorType, a subclass of VectorType.
- added ASTContext::getOCUVectorType.
- changed ASTContext::convertToVectorType() to ASTContext::getVectorType(). This is
unrelated to extended vectors, however I was in the vicinity and it was on my todo list.
Added a FIXME to Sema::HandleVectorTypeAttribute to deal with converting complex types.
llvm-svn: 40007
According to the spec (C++ 5p6[expr]), we need to adjust "T&" to
"T" before further analysis. We do this via the "implicit cast"
thingy.
llvm-svn: 39953
there is no compelling need to return the converted type. If both expression type's are arithmetic, then
both types will always be the same. If they aren't (for pointer/int types, say), then the
types will be different. The client is responsible for distinguishing...
llvm-svn: 39947
to quickly fix a regression. Avoiding them entirely is a much cleaner solution. Clients of
UsualArithmeticConversions should simply call getType() on the expression to get the
converted type. In practice, only a small number of routines care about this.
llvm-svn: 39934
needs to query the expression for the type. Since both these functions guarantee the expression
contains a valid type, removed old/vacuous asserts (from code calling both of these routines).
llvm-svn: 39930
information in the common case. On this invalid code:
typedef float float4 __attribute__((vector_size(16)));
typedef int int4 __attribute__((vector_size(16)));
void test(float4 a, int4 *result, int i) {
result[i] = a;
}
we now generate:
t.c:5:15: error: incompatible types assigning 'float4' to 'int4'
instead of:
t.c:5:15: error: incompatible types assigning 'float4' to 'int __attribute__((vector_size(16)))'
This implements test/Sema/typedef-retain.c
llvm-svn: 39892
previous two checkins, which involved lot's of tedious refactoring, this checkin is nice and clean:-)
- Hacked UsualUnaryConversions, UsualArithmeticConversions, and DefaultFunctionArrayConversion
to create the AST node (using a helper function promoteExprToType).
- Added a setType method to Expr.
- Changed Expr::isIntegerConstantExpr to allow for the new node.
llvm-svn: 39866
- Fixed a recent regression discovered by Keith Bauer (thanks!).
The fix involved adding (back) two arguments to UsualArithmeticConversions.
Without the reference arguments, no unary conversions were being passed back
to the caller. This had the effect of turning off the UsualUnaryConversions.
- Refactored CheckAssignmentConstraints into 3 functions. CheckAssignmentConstraints,
CheckSingleAssignmentConstraints, and CheckCompoundAssignmentConstraints.
- Changed the argument type of DefaultFunctionArrayConversion from QualType->Expr*&.
- Removed a bunch of casts in routines I was working on (cleanup).
- Fixed the visitor for ImplicitCastExpr (oops).
llvm-svn: 39840
code generator. Source translation tools can simply ignore this node.
- Added a new Expr node, ImplicitCastExpr.
- Changed UsualUnaryConversions/UsualArithmeticConversions to take references
to Expr *'s. This will allow these routines to instantiate the new AST node
and pass it back.
- Changed all clients of UsualUnary/UsualArithmetic (lot's of diff's).
- Changed some names in CheckConditionalOperands. Several variables where
only distinguished by their case (e.g. Cond, cond). Yuck (what was I thinking).
- Removed an old/crufty constructor in CastExpr (cleanup).
This check-in does not actually create the new AST node. I wanted to separate
the mechanical changes from the semantic changes. In addition, I need to
coordinate with Chris, since the semantic change will break the code generator.
llvm-svn: 39814
Submitted by:
Reviewed by:
Two vector fixes:
- Sema::CheckAssignmentConstraints() needs to compare the canonical type.
- Expr::isLvalue() needs to disallow subscripting into a vector returned by a function. This
follows the rules for struct returns (in C, at least...C++ is another story:-)
Here is an example...
float4 float4_return()
{
float4 xx;
return xx;
}
void add_float4_void_return(float4 *a, float4 *b, float4 *result)
{
float f;
float4_return()[1] = f; // now illegal
}
llvm-svn: 39728
Submitted by:
Reviewed by:
Support the following...
1. Type checking and codegen support for V[i] on vectors. Hacked
Sema::ParseArraySubscriptExpr().
2. Unary bitwise complement ("~") on vectors. Hacked Sema::ParseUnaryOp().
llvm-svn: 39723
Submitted by:
Reviewed by:
Typechecking support for vectors...
- Added CheckVectorOperands(). Called from CheckAdditionOperands,
CheckMultiplyDivideOperands, CheckSubstractionOperands, and CheckBitwiseOperands.
- Added diagnostic for converting vector values of different size.
- Modified Type::isArithmeticType to include vectors.
Sould be ready for Chris to add code generation. I will continue testing/refining.
llvm-svn: 39717
Submitted by:
Reviewed by:
Fix a bozo bug in HandleDeclAttribute...only install a new type when appropriate.
Also changed setType/setUnderlyingType to return void.
llvm-svn: 39716
Submitted by:
Reviewed by:
- Finished semantic analysis for vectors, added some diagnostics.
- Added AST for vectors (instantiation, installation into the decl).
- Fixed bug in ParseArraySubscriptExpr()...this crasher was introduced by me
when we added the range support.
- Turned pedantic off by default. Since vectors are gcc extensions, having
pedantic on by default was annoying. Turning it off by default is also
consistent with gcc (but this wasn't my primary motivation).
- Tweaked some comments and diagnostics.
Note: The type checking code is still under construction (for vectors). This
will be my next check-in.
llvm-svn: 39715
Reviewed by: Chris Lattner
- Fix for C++ casting operators failing during parsing. Deriving the C++ cast
expressions from CastExpr was the wrong way to go. Its constructor creates
null QualTypes in one of its constructors. This doesn't work well with how
the C++ casting expression class wanted to do things. Derive just from Expr
instead.
llvm-svn: 39714
For example, for:
int test(short S, long L) {
return S /= L;
}
record that the division is done as a long, even though the result type is
short.
llvm-svn: 39700
out of the llvm namespace. This makes the clang namespace be a sibling of
llvm instead of being a child.
The good thing about this is that it makes many things unambiguous. The
bad things is that many things in the llvm namespace (notably data structures
like smallvector) now require an llvm:: qualifier. IMO, libsystem and libsupport
should be split out of llvm into their own namespace in the future, which will fix
this issue.
llvm-svn: 39659
Submitted by:
Reviewed by:
Fix CheckRelationalOperands/CheckEqualityOperands to deal with null pointer
constants. The new logic also deals (more) correctly for non-pointer/integer
operands.
llvm-svn: 39654
Submitted by:
Reviewed by:
Fixed typechecking bugs wrt UsualUnaryConversions. Includes two distinct fixes:
#1: Call UsualUnaryConversions in CheckRelationalOperands/CheckEqualityOperands.
#2: UsualArithmeticConversions arguments are now output parameters. This insures
the implicit conversion is seen by clients (and fixes bugs in CheckAdditionOperands
and CheckSubtractionOperands when doing pointer arithmetic).
~
llvm-svn: 39649
Submitted by:
Reviewed by:
Lot's of attribute scaffolding.
Modernized ParseArraySubscriptExpr...call DefaultFunctionArrayConversion (which
simplified the logic considerably) and upgrade Diags to use the range support.
llvm-svn: 39628
like: int X, Y, Z;
This is required for the code gen to get to all of the declarations in a
DeclStmt, and should simplify some other code.
llvm-svn: 39623
Submitted by:
Reviewed by:
The following code illustrates a bug in the semantic analysis for assignments:
int func() {
int *P;
char *x;
P = x; // type of this assignment expression should be "int *", NOT "char *".
}
While the type checking/diagnostics are correct, the type of the assignment
expression is incorrect (which shows up during code gen). With the fix,
the llvm code looks correct...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang cast.c -emit-llvm
cast.c:4:5: warning: incompatible pointer types assigning 'char *' to 'int *'
P = x; // type of assignment expression is "int *", NOT "char *".
~ ^ ~
; ModuleID = 'foo'
define i32 @func() {
entry:
%P = alloca i32* ; <i32**> [#uses=1]
%x = alloca i8* ; <i8**> [#uses=1]
%allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0]
%tmp = load i8** %x ; <i8*> [#uses=1]
%conv = bitcast i8* %tmp to i32* ; <i32*> [#uses=1]
store i32* %conv, i32** %P
ret i32 undef
}
Even though the fix was simple, I decided to rename/refactor the surrounding code
to make a clearer distinction between constraint checking and conversion.
- Renamed AssignmentConversionResult -> AssignmentCheckResult.
- Renamed UsualAssignmentConversions -> CheckAssignmentConstraints.
- Changed the return type of CheckAssignmentConstraints and CheckPointerTypesForAssignment
from QualType -> AssignmentCheckResult. These routines no longer take a reference to the result (obviously).
- Changed CheckAssignmentOperands to return the correct type (with spec annotations).
llvm-svn: 39601
Steve Naroff