char *C;
C != ((void*)0);
Should not warn about incompatible pointer types. Also, make sure to
insert an implicit conversion even if the operand is null.
llvm-svn: 41408
eliminates the possibility that the left hand expression is an ImplicitCastExpr.
As a result, I removed the check for ImplicitCastExpr in Expr::isLvalue().
This results in the following AST's...
[dylan:~/llvm/tools/clang] admin% cat fix.c
short x; void test4(char c) {
x += c;
x = x + c;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang fix.c -parse-ast-dump
Read top-level variable decl: 'x'
void test4(char c)
(CompoundStmt 0x2605d30
(CompoundAssignOperator 0x2605c40 'short' '+='
(DeclRefExpr 0x2605c00 'short' Decl='x' 0x2605a80)
(DeclRefExpr 0x2605c20 'char' Decl='c' 0x2605bc0))
(BinaryOperator 0x2605d10 'short' '='
(DeclRefExpr 0x2605c60 'short' Decl='x' 0x2605a80)
(ImplicitCastExpr 0x2605d00 'short'
(BinaryOperator 0x2605ce0 'int' '+'
(ImplicitCastExpr 0x2605cc0 'int'
(DeclRefExpr 0x2605c80 'short' Decl='x' 0x2605a80))
(ImplicitCastExpr 0x2605cd0 'int'
(DeclRefExpr 0x2605ca0 'char' Decl='c' 0x2605bc0))))))
llvm-svn: 41404
it is o.k. for the LHS and RHS to have different types. Converting the type can cause
errors like the one Chris noticed (below).
This change required a fair number of diffs (since there is a lot of shared code
between single and compound assignments). This makes the API's look a bit uglier,
however I couldn't think of a better way to do it (without duplicating code).
Fix the following (incorrect) error:
int A;
long long B;
void foo() {
A /= B;
}
$ clang ~/scalar.c -emit-llvm
/Users/sabre/scalar.c:6:5: error: expression is not assignable
A /= B;
~ ^
Now it works properly...
[dylan:~/llvm/tools/clang] admin% cat compound.c
int A;
long long B;
void foo() {
A /= B;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang compound.c -parse-ast-dump
Read top-level variable decl: 'A'
Read top-level variable decl: 'B'
void foo()
(CompoundStmt 0x2605c40
(BinaryOperator 0x2605c20 'int' '/=' ComputeTy='long long'
(DeclRefExpr 0x2605be0 'int' Decl='A' 0x2605a80)
(DeclRefExpr 0x2605c00 'long long' Decl='B' 0x2605ab0)))
llvm-svn: 41364
Now we emit the following when -pedantic-errors is enabled...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang complex.c -pedantic-errors
complex.c:4:3: error: ISO C does not support '++'/'--' on complex integer types
++x;
^ ~
complex.c:9:7: error: ISO C does not support '~' for complex conjugation
X = ~Y;
^
complex.c:10:7: error: ISO C does not support '~' for complex conjugation
x = ~y;
^
llvm-svn: 41362
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
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
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
Chris Lattner