- 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
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
#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
- 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().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40508 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40482 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40475 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40136 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40134 91177308-0d34-0410-b5e6-96231b3b80d8
Since that point is now long gone, we should rename LexerToken to
Token, as it is the only kind of token we have.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40105 91177308-0d34-0410-b5e6-96231b3b80d8
We still need to do sematic analysis (and implement initializers), however this
should complete the parsing & ast building for compound literals.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40067 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40032 91177308-0d34-0410-b5e6-96231b3b80d8
return a null type. If there is an error parsing the type, pick a new type
for error recovery purposes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40029 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40007 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39953 91177308-0d34-0410-b5e6-96231b3b80d8
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...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39947 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39934 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39930 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39892 91177308-0d34-0410-b5e6-96231b3b80d8
ParseArraySubscriptExpr. Notably, the new code doesn't have to think about
canonical types at all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39891 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39866 91177308-0d34-0410-b5e6-96231b3b80d8