Age | Commit message (Collapse) | Author |
|
"assignments",
while includes init decls, assignment exprs, call exprs, and return statements.
Here are a few examples with the correct AST's...
[dylan:~/llvm/tools/clang] admin% cat impcomp.c
_Complex double X;
void test2(int c) {
X = 5;
}
void foo() {
int i;
double d = i;
double _Complex a = 5;
test2(a);
a = 5;
d = i;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang impcomp.c -parse-ast-dump
Read top-level variable decl: 'X'
void test2(int c)
(CompoundStmt 0x2605ce0
(BinaryOperator 0x2605cc0 '_Complex double' '='
(DeclRefExpr 0x2605c70 '_Complex double' Decl='X' 0x2605af0)
(ImplicitCastExpr 0x2605cb0 '_Complex double'
(IntegerLiteral 0x2605c90 'int' 5))))
void foo()
(CompoundStmt 0x2606030
(DeclStmt 0x2605bd0
0x2605d90 "int i")
(DeclStmt 0x2605e20
0x2605de0 "double d =
(ImplicitCastExpr 0x2605e10 'double'
(DeclRefExpr 0x2605dc0 'int' Decl='i' 0x2605d90))")
(DeclStmt 0x2605e90
0x2605e50 "_Complex double a =
(ImplicitCastExpr 0x2605e80 '_Complex double'
(IntegerLiteral 0x2605e30 'int' 5))")
(CallExpr 0x2605f20 'void'
(ImplicitCastExpr 0x2605f00 'void (*)(int)'
(DeclRefExpr 0x2605ea0 'void (int)' Decl='test2' 0x2605c00))
(ImplicitCastExpr 0x2605f10 'int'
(DeclRefExpr 0x2605ec0 '_Complex double' Decl='a' 0x2605e50)))
(BinaryOperator 0x2605fa0 '_Complex double' '='
(DeclRefExpr 0x2605f50 '_Complex double' Decl='a' 0x2605e50)
(ImplicitCastExpr 0x2605f90 '_Complex double'
(IntegerLiteral 0x2605f70 'int' 5)))
(BinaryOperator 0x2606010 'double' '='
(DeclRefExpr 0x2605fc0 'double' Decl='d' 0x2605de0)
(ImplicitCastExpr 0x2606000 'double'
(DeclRefExpr 0x2605fe0 'int' Decl='i' 0x2605d90))))
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41379 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41377 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41375 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
assignments,
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)))
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41364 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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;
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fixes an assertion on:
void f (int z) { switch (z) { case ~0ULL: case -1: return; } }
testcase from Neil.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41343 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This following now compiles without error...
_Complex unsigned X, Y;
_Complex double x, y;
void test2(int c) {
X = ~Y;
x = ~y;
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41341 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41340 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Now, the following test case succeeds...
_Complex double x, y;
void test2(int c) {
++x;
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41335 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
verifying case ranges.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41331 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
switch.c:16:8: warning: empty case range specified
case 100 ... 99: ; // expected-warning {{empty case range}}
^~~~~~~~~~
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41328 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41317 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41315 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warnings when converting case values to the expression type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41313 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41273 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41238 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41232 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to getBase and getIdx. getBase and getIdx now return a "normalized" view
of the expression (e.g., always "A[4]" instead of possibly "4[A]"). getLHS
and getRHS return the expressions with syntactic fidelity to the original
source code.
Also modified client code of ArraySubscriptExpr, including the AST dumper
and pretty printer, the return-stack value checker, and the LLVM code
generator.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41180 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"return of stack addresses." ParseReturnStmt now calls CheckReturnStackAddr
to determine if the expression in the return statement evaluates to an
address of a stack variable. If so, we issue a warning.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41141 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41140 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41136 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41127 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41079 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
by CheckPrintfArguments to determine if a given printf function
accepts a va_arg argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41008 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
KnownFunctionIDs. This allows us to test for a printf-like function
that accepts a va_arg argument using a range comparison.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41006 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"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."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@41003 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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))))
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40907 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
[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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40832 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40831 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40795 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40794 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
OCUVectorElementExpr respectively. This is for consistency with other expr nodes end with *Expr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40785 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Fix type printing code for recently added TypeOfExpr/TypeOfType.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40700 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Todo...still need to call the action from the parser...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40693 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40676 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40653 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
canonical types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40652 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
there is now an isXXXType and a getAsXXXType
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40646 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40640 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
existing one to getAsPointerType()
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40639 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Many small changes to lot's of files.
Still some FIXME's, however the basic support is in place.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40597 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40584 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
~ ^ ~~~~~~~
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40579 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40577 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Next step, AST support...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40568 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
#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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40526 91177308-0d34-0410-b5e6-96231b3b80d8
|