typeof(type) and typeof(expr) correctly. Now provide a single point of
contact (Type::getDesugaredType) for doing the shallow stripping we need.
llvm-svn: 43432
This allowed me to fix the following hack from this weekend...
// FIXME: Devise a way to do this without using strcmp.
// Would like to say..."return getAsStructureType() == IdStructType;", but
// we don't have a pointer to ASTContext.
bool Type::isObjcIdType() const {
if (const RecordType *RT = getAsStructureType())
return !strcmp(RT->getDecl()->getName(), "objc_object");
return false;
}
...which is now...
bool isObjcIdType(QualType T) const {
return T->getAsStructureType() == IdStructType;
}
Side notes:
- I had to remove a convenience function from the TypesCompatibleExpr class.
int typesAreCompatible() const {return Type::typesAreCompatible(Type1,Type2);}
Which required a couple clients get a little more verbose...
- Result = TCE->typesAreCompatible();
+ Result = Ctx.typesAreCompatible(TCE->getArgType1(), TCE->getArgType2());
Overall, I think this change also makes sense for a couple reasons...
1) Since ASTContext vends types, it makes sense for the type compatibility API to be there.
2) This allows the type compatibility predeciates to refer to data not strictly present in the AST (which I have found problematic on several occasions).
llvm-svn: 43009
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
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
Refactored Array/VariableArray, moving SizeModifier/IndexTypeQuals back up to Array. These
attributes are not specific to VLA's. Most of them are specific to array parameter types.
llvm-svn: 41616
[dylan:~/llvm/tools/clang] admin% cat tentative_decls.c
// incorrectly generates redefinition error
extern int array[3];
int array[3];
// incorrectly generates a redefinition error
extern void nup(int a[3]);
void nup(int a[3]) {}
It turns out that this exposed a fairly major flaw in the type system,
array types were never getting uniqued! This is because all array types
contained an expression, which aren't unique.
To solve this, we now have 2 array types, ConstantArrayType and
VariableArrayType. ConstantArrayType's are unique, VAT's aren't.
This is a fairly extensive set of fundamental changes. Fortunately,
all the tests pass. Nevertheless, there may be some collateral damage:-)
If so, let me know!
llvm-svn: 41592
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
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
the AST in a structural, non-pretty, form useful for understanding
the AST. It isn't quite done yet, but is already somewhat useful.
For this example:
int test(short X, long long Y) {
return X < ((100));
}
we get (with -parse-ast-dump):
int test(short X, long long Y)
(CompoundStmt 0x2905ce0
(ReturnStmt 0x2905cd0
(BinaryOperator 0x2905cb0 '<'
(ImplicitCastExpr 0x2905ca0
(DeclRefExpr 0x2905c20 Decl='X' 0x2905bb0))
(ParenExpr 0x2905c80
(ParenExpr 0x2905c60
(IntegerLiteral 0x2905c40 100))))))
llvm-svn: 40954
[dylan:clang/test/Parser] admin% ../../../../Debug/bin/clang -parse-ast-check typeof.c
Warnings expected but not seen:
Line 21: incompatible types assigning 'typeof(*pi) const' to 'int *'
Warnings seen but not expected:
Line 21: incompatible types assigning 'typeof(*pi) const' to 'int *'
Also corrected a typo from my previous commit.
llvm-svn: 40832
- 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
- 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().
llvm-svn: 40508
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
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.
llvm-svn: 39932
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
llvm-svn: 39892
Submitted by:
Reviewed by:
Typechecking support for vectors...
- Added CheckVectorOperands(). Called from CheckAdditionOperands,
CheckMultiplyDivideOperands, CheckSubstractionOperands, and CheckBitwiseOperands.
- Added diagnostic for converting vector values of different size.
- Modified Type::isArithmeticType to include vectors.
Sould be ready for Chris to add code generation. I will continue testing/refining.
llvm-svn: 39717
Submitted by:
Reviewed by:
- Finished semantic analysis for vectors, added some diagnostics.
- Added AST for vectors (instantiation, installation into the decl).
- Fixed bug in ParseArraySubscriptExpr()...this crasher was introduced by me
when we added the range support.
- Turned pedantic off by default. Since vectors are gcc extensions, having
pedantic on by default was annoying. Turning it off by default is also
consistent with gcc (but this wasn't my primary motivation).
- Tweaked some comments and diagnostics.
Note: The type checking code is still under construction (for vectors). This
will be my next check-in.
llvm-svn: 39715
out of the llvm namespace. This makes the clang namespace be a sibling of
llvm instead of being a child.
The good thing about this is that it makes many things unambiguous. The
bad things is that many things in the llvm namespace (notably data structures
like smallvector) now require an llvm:: qualifier. IMO, libsystem and libsupport
should be split out of llvm into their own namespace in the future, which will fix
this issue.
llvm-svn: 39659
Chris Lattner