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
bottleneck for -E computation, because every token that starts a line needs
to determine *which* line it is on (so -E mode can insert the appropriate
vertical whitespace). This optimization improves this common case where
it is striding through the line # table.
This speeds up -E on xalancbmk by 3.2%
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40459 91177308-0d34-0410-b5e6-96231b3b80d8
redefinition of a macro could cause invalid memory to be deleted.
Found preprocessing 253.perlbmk.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@40380 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
I've added a tests/CodeGen directory, and a test for this case that
used to fail and now passes."
Patch by Keith Bauer
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39794 91177308-0d34-0410-b5e6-96231b3b80d8
Steve Naroff
Chris Lattner
Reid Spencer