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
isPointerType and isVectorType to only look through a single level of typedef
when one is present. For this invalid code:
typedef float float4 __attribute__((vector_size(16)));
typedef int int4 __attribute__((vector_size(16)));
typedef int4* int4p;
void test(float4 a, int4p result, int i) {
result[i] = a;
}
we now get:
t.c:5:15: error: incompatible types assigning 'float4' to 'int4'
result[i] = a;
~~~~~~~~~ ^ ~
instead of:
t.c:5:15: error: incompatible types assigning 'float4' to 'int __attribute__((vector_size(16)))'
result[i] = a;
~~~~~~~~~ ^ ~
The rest of the type predicates should be upgraded to do the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39932 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
accurate diagnostics. For test/Lexer/comments.c we now emit:
int x = 000000080; /* expected-error {{invalid digit}} */
^
constants.c:7:4: error: invalid digit '8' in octal constant
00080; /* expected-error {{invalid digit}} */
^
The last line is due to an escaped newline. The full line looks like:
int y = 0000\
00080; /* expected-error {{invalid digit}} */
Previously, we emitted:
constants.c:4:9: error: invalid digit '8' in octal constant
int x = 000000080; /* expected-error {{invalid digit}} */
^
constants.c:6:9: error: invalid digit '8' in octal constant
int y = 0000\
^
which isn't too bad, but the new way is better for the user,
regardless of whether there is an escaped newline or not.
All the other lexer-related diagnostics should switch over
to using AdvanceToTokenCharacter where appropriate. Help
wanted :).
This implements test/Lexer/constants.c.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39906 91177308-0d34-0410-b5e6-96231b3b80d8
specifying the start of a token and a logical (phase 3) character number,
returns a sloc representing the input character corresponding to it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39905 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
the result type of the expr node.
Implement isIntegerConstantExpr for ImplicitCastExpr nodes the same
was as for CastExpr nodes.
Implement proper sign/zero extension as well as truncation and noop
conversion in the i-c-e evaluator. This allows us to correctly
handle i-c-e's like these:
char array[1024/(sizeof (long))];
int x['\xBb' == (char) 187 ? 1: -1];
this implements test/Sema/i-c-e2.c
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39888 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
This doesn't significantly improve carbon.h, but it does speed up
INPUTS/macro_pounder_obj.c by 48%
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39864 91177308-0d34-0410-b5e6-96231b3b80d8
Chris Lattner
Gabor Greif
Bill Wendling
Steve Naroff