For example, the following code was resulting in spurious warnings. This was the result of
Sema::GetTypeForDeclarator() synthesizing a type to hand back to the caller (in this case,
"int []", instead of "struct s[]", which is invalid).
struct s;
struct s* t (struct s z[]) { // expected-error {{array has incomplete element type}}
return z;
}
Strategy: Flag the error in Declarator/DeclaratorChunk. This info is later stored in
the ParmVarDecl. If the decl is referenced, Sema::ParseIdentifierExpr() will check if
the type is invalid. If so, it quietly returns "true", without instantiating a DeclRefExpr.
This seems to work nicely. If Chris is happy with the approach, I will generalize this to
all VarDecls.
llvm-svn: 41521
implicit casts from T to T& at the topmost part of the return-value expression.
This checking may be needed within EvalAddr later on. We'll wait until
test cases show this kind of logic is necessary (as more C++ features are
implemented in clang).
llvm-svn: 41493
Modified Type::typesAreCompatible() to use the above.
This fixes the following bug submitted by Keith Bauer (thanks!).
int equal(char *a, const char *b)
{
return a == b;
}
Also tweaked Sema::CheckCompareOperands() to ignore the qualifiers when
comparing two pointer types (though it doesn't relate directly to this bug).
llvm-svn: 41476
Changed Sema::UsualArithmeticConversions to correctly implement complex/float conversions,
using maxFloatingType() with getFloatingTypeOfSizeWithinDomain().
llvm-svn: 41474
Remove bogus type conversions in Sema::GetTypeForDeclarator(). This commit
only deals with the array types (DeclaratorCheck::Array), though the
rest of this routine should be reviewed. Given the complexity of C declarators,
I don't want to change the entire routine now (will discuss with Chris tomorrow).
llvm-svn: 41443
hold declarations. Instead, introduce a new "DeclScope" scope type that
holds them explicitly. For now, all scopes have this bit, but in the
future we can use them to fix some issues Neil noticed.
llvm-svn: 41431
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
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.
llvm-svn: 41180
"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.
llvm-svn: 41141
Chris Lattner