This surfaced yesterday, when compiling test/Sema/cocoa.m on Leopard. Since this has nothing to do with ObjC, it's kind of bizarre this hasn't shown up before. I imagine Cocoa.h on Leopard may have changed recently?
Thanks to Ted for localizing the bug and giving me a useful AST dump...
llvm-svn: 43114
when comparing "float" and "const float". This "fixes" the
issue, but may not be the right fix. Steve, please review.
Testcase here: test/Sema/usual-float.c
llvm-svn: 43113
unsigned char asso_values[] = { 34 };
int legal2() {
return asso_values[0];
}
The code that creates the new constant array type was operating on the original type.
As a result, the constant type being generated was "unsigned char [1][]" (which is wrong).
The fix is to operate on the element type - in this case, the correct type is "unsigned char [1]"
I added this case to array-init.c, which clearly didn't catch this bogosity...
llvm-svn: 43112
printf format strings. Added type checking to see if the matching
width/precision argument was of type 'int'.
Thanks to Anders Carlsson for reporting this missing feature.
llvm-svn: 42933
- Cache the typedef, not the type (avoids importing AST/Type.h).
- Emit an error if "id" cannot be found.
- Comment the routine and add a FIXME to reconsider how we emulate GCC's new fangled behavior. This isn't a priority for now, since almost no code depends on having "id" built-in.
- Add a test.
llvm-svn: 42845
- Cache the "id" type in Sema...initialize ObjcIdType and TUScope (oops).
- Fix ActOnInstanceMessage to allow for "id" type receivers...still work to do (next).
llvm-svn: 42842
This fixes a crasher in Sema::MatchTwoMethodDeclarations(), identified by selector-overload.m (just added).
Added Action::ActOnTranslationUnitScope() and renamed Action::PopScope to ActOnPopScope.
Added a Translation Unit Scope instance variable to Sema (will be very useful to ObjC-related actions, since ObjC declarations are always file-scoped).
llvm-svn: 42817
using "-parse-ast -verify".
Updated all test cases (using a sed script) that invoked -parse-ast-check to
now use -parse-ast -verify.
Fixed a bug where using "-verify" instead of "-parse-ast-check" would not
correctly create the DiagClient needed to accumulate diagnostics.
llvm-svn: 42365
1. Handles saving and checking on protocols used in an @interface declaration
2. Checks and saves class's super class.
3. Adds semantic check to category declarations.
llvm-svn: 42218
as types. That said, the AST nodes ObjcInterfaceDecl, ObjcInterfaceType, and ObjcClassDecl are *very*
preliminary.
The good news is we no longer need -parse-noop (aka MinimalActions) to parse cocoa.m.
llvm-svn: 41752
2. Fixes all allowable key-words used as selectors.
3. Template to do the messaging parse.
4. A test case for all allowable selector names.
llvm-svn: 41723
- Fixed many bugs, enhanced test case considerably, added a diagnostic, etc.
- Refactored CheckInitList() into CheckVariableInitList()/CheckConstantInitList().
- Added CheckInitExpr().
- Support for multi-dimensional arrays looking good.
llvm-svn: 41690
- Added Expr::isConstantExpr().
- Added type checking for InitListExpr elements.
- Added diagnostic for trying to initialize a variable sized object.
llvm-svn: 41674
Step 1: Start instantiating InitListExpr's.
Step 2: Call newly added function Sema::CheckInitializer() from Sema::ParseDeclarator().
Step 3: Give InitListExpr's a preliminary type.
Step 4: Start emitting diagnostics for simple assignments.
Note:
As a result of step 1, the CodeGen/mandel.c test asserts "Unimplemented agg expr!", which is expected.
As a result of step 4, the test below now fails. This isn't expected and needs to be investigated (it appears type checking for C++ references is flawed in some way).
******************** TEST 'Sema/cxx-references.cpp' FAILED! ********************
Command:
clang -fsyntax-only Sema/cxx-references.cpp
Output:
Sema/cxx-references.cpp:8:12: warning: incompatible pointer types assigning 'int &*' to 'int *'
int *p = &r;
^~
Sema/cxx-references.cpp:10:20: error: incompatible types assigning 'int (int)' to 'int (&)(int)'
int (&rg)(int) = g;
^
Sema/cxx-references.cpp:13:18: error: incompatible types assigning 'int [3]' to 'int (&)[3]'
int (&ra)[3] = a;
^
Sema/cxx-references.cpp:16:14: error: incompatible types assigning 'int *' to 'int *&'
int *& P = Q;
^
4 diagnostics generated.
******************** TEST 'Sema/cxx-references.cpp' FAILED! ********************
llvm-svn: 41671
warn about the last stmt in a stmtexpr, f.e. there should be no warning for:
int maxval_stmt_expr(int x, int y) {
return ({int _a = x, _b = y; _a > _b ? _a : _b; });
}
llvm-svn: 41655
routine was causing more trouble than it was worth. Anders/Chris noticed that it could return an error code
without emiting a diagnostic (which results in an silent invalid decl, which should *never* happen). In addition,
this routine didn't work well for typedefs and field decls. Lastly, it didn't consider that initializers aren't
in place yet.
Added Type::getAsConstantArrayType(), Type::getAsVariableArrayType(), Type::getAsVariablyModifiedType(),
and Type::isVariablyModifiedType();
Modified Sema::ParseDeclarator() and Sema::ParseField() to use the new predicates. Also added a FIXME for
the initializer omission. Also added a missing test for "static" @ file scope.
llvm-svn: 41647
Moved several array constraints checks from Sema::VerifyConstantArrayType() to
Sema::GetTypeForDeclarator(). VerifyConstantArrayType() is now very simple, and
could be removed eventually.
Now, we get the following (correct) messages for BlockVarDecls:-)
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang x.c -pedantic
x.c:4:20: error: size of array has non-integer type 'float'
int size_not_int[f];
^
x.c:5:21: error: array size is negative
int negative_size[1-2];
^~~
x.c:6:17: warning: zero size arrays are an extension
int zero_size[0];
^
3 diagnostics generated.
llvm-svn: 41624
to emit signed comparisons when needed for enum decl references. This implements
test/CodeGen/enum.c. I think enums should be good now.
llvm-svn: 41572
Converted ParmVarDecl, FileVarDecl, BlockVarDecl, and Sema::ParseIdentifierExpr() to use the idiom.
Updated array-constraint.c to make sure we no longer get "undeclared identifier" errors:-)
llvm-svn: 41552
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
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
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
This fixes the following bug...
t.c:1:31: error: expression is not assignable
short x; void foo(char c) { x += c; }
This case, among others are now captured in implicit-casts.c.
llvm-svn: 41402
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.
llvm-svn: 41127
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.
llvm-svn: 41076
"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."
llvm-svn: 41003
preprocessor state, causing bogus diagnostics when the file is parsed for real. This
implements Misc/diag-checker.c. Thanks to Ted for noticing this.
llvm-svn: 41000
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.
llvm-svn: 40831
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.
llvm-svn: 40795
This test case currently generates the following unexpected warnings (when compared with gcc).
[dylan:clang/test/Parser] admin% ../../../../Debug/bin/clang -parse-ast-check builtin_types_compatible.c
Warnings seen but not expected:
Line 28: expression result unused
Line 29: expression result unused
Line 30: expression result unused
Line 31: expression result unused
Line 32: expression result unused
Line 33: expression result unused
llvm-svn: 40789
- 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.
llvm-svn: 40676
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.
llvm-svn: 40482
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.
llvm-svn: 40475
it did not handle <xyz> headers coming from macro expansions.
This requires special treatment, as the include name is lexed
as multiple tokens, which require reassembly before processing.
llvm-svn: 40418
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.
llvm-svn: 40136
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.
llvm-svn: 40134
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.
llvm-svn: 40032
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.
llvm-svn: 39953
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.
llvm-svn: 39906
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
llvm-svn: 39888
implements test/Preprocessor/expr_usual_conversions.c, which produces this
output:
expr_usual_conversions.c:5:10: warning: left side of operator converted from negative value to unsigned: -42 to 18446744073709551574
#if (-42 + 0U) / -2
^
expr_usual_conversions.c:5:16: warning: right side of operator converted from negative value to unsigned: -2 to 18446744073709551614
#if (-42 + 0U) / -2
^
llvm-svn: 39406
switch statements. Make break/continue check that they are inside of an
appropriate control-flow construct. This implements Parser/bad-control.c.
llvm-svn: 39136
lexer. This makes more logical sense and also unbreaks the case when the
lexer hasn't been pushed onto the PP include stack. This is the case when
pasting identifiers. This patch implements macro_paste_bcpl_comment.c.
llvm-svn: 38736
Steve Naroff