| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 41238
|
|
|
|
| |
llvm-svn: 41140
|
|
|
|
| |
llvm-svn: 41136
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deal more
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operators.
This fixes the following...
eypedef short S;
int test(S X, long long Y) {
return X < Y;
}
Before...
(CompoundStmt 0x2905d00
(ReturnStmt 0x2905cf0
(BinaryOperator 0x2905cd0 'int' '<'
(ImplicitCastExpr 0x2905cc0 'int'
(DeclRefExpr 0x2905c80 'S':'short' Decl='X' 0x2905c20))
(DeclRefExpr 0x2905ca0 'long long' Decl='Y' 0x2905c50))))
After...
(CompoundStmt 0x2b05c30
(ReturnStmt 0x2b05c20
(BinaryOperator 0x2b05c00 'int' '<'
(ImplicitCastExpr 0x2b05bf0 'long long'
(DeclRefExpr 0x2b05bb0 'S':'short' Decl='X' 0x2b05b50))
(DeclRefExpr 0x2b05bd0 'long long' Decl='Y' 0x2b05b80))))
llvm-svn: 40999
|
|
|
|
|
|
|
|
|
|
| |
Sema::ParseIdentifierExpr()
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters.
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
|
|
|
|
| |
llvm-svn: 40794
|
|
|
|
|
|
| |
OCUVectorElementExpr respectively. This is for consistency with other expr nodes end with *Expr.
llvm-svn: 40785
|
|
|
|
| |
llvm-svn: 40764
|
|
|
|
|
|
| |
- Fix type printing code for recently added TypeOfExpr/TypeOfType.
llvm-svn: 40700
|
|
|
|
|
|
| |
Todo...still need to call the action from the parser...
llvm-svn: 40693
|
|
|
|
|
|
| |
canonical types.
llvm-svn: 40652
|
|
|
|
|
|
| |
there is now an isXXXType and a getAsXXXType
llvm-svn: 40646
|
|
|
|
| |
llvm-svn: 40640
|
|
|
|
|
|
| |
existing one to getAsPointerType()
llvm-svn: 40639
|
|
|
|
|
|
|
| |
Many small changes to lot's of files.
Still some FIXME's, however the basic support is in place.
llvm-svn: 40631
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
void func() {
typedef int foo;
foo *Y;
**Y; // error
}
we now get:
indirection requires pointer operand ('foo' invalid)
instead of:
indirection requires pointer operand ('int' invalid)
llvm-svn: 40597
|
|
|
|
| |
llvm-svn: 40584
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
component access).
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
|
|
|
|
| |
llvm-svn: 40577
|
|
|
|
|
|
| |
Next step, AST support...
llvm-svn: 40568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#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
|
|
|
|
|
|
| |
- Add comment and minor cleanup to yesterday's fix to ParseCallExpr().
llvm-svn: 40492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
promotions on it's argument types.
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
|
|
|
|
|
|
| |
This implements test/Sema/stmt_exprs.c
llvm-svn: 40465
|
|
|
|
| |
llvm-svn: 40162
|
|
|
|
| |
llvm-svn: 40139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 40135
|
|
|
|
|
|
|
| |
Since that point is now long gone, we should rename LexerToken to
Token, as it is the only kind of token we have.
llvm-svn: 40105
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 40003
|
|
|
|
| |
llvm-svn: 39960
|
|
|
|
|
|
| |
the canonical type. Also fix so that we're not expecting a return value from a void function
llvm-svn: 39954
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
ImplicitCastExpr's,
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
|
|
|
|
| |
llvm-svn: 39943
|
|
|
|
|
|
|
|
|
|
| |
week, I added these
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
|
|
|
|
|
|
|
|
|
| |
void. The caller
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
|
|
|
|
|
|
|
|
| |
SemaExpr.cpp:561: warning: dereferencing type-punned pointer will break strict-aliasing rules
Patch by Benoit Boissinot!
llvm-svn: 39928
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
ParseArraySubscriptExpr. Notably, the new code doesn't have to think about
canonical types at all.
llvm-svn: 39891
|
|
|
|
|
|
| |
sometimes.
llvm-svn: 39889
|