Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unex

Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:

// expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters

It will also match these other error messages:

candidate function
function has different number of parameters
number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619

show more ...

Improve diagnostics like "initializing <type> from an expression of
type..." with "initializing <type> with an expression of type...",
which reads better. Thanks to John for the improved wording.

ll

Improve diagnostics like "initializing <type> from an expression of
type..." with "initializing <type> with an expression of type...",
which reads better. Thanks to John for the improved wording.

llvm-svn: 100873

show more ...

Improve diagnostics when we fail to convert from a source type to a
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing

Improve diagnostics when we fail to convert from a source type to a
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as

t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~

We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:

t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~

Fixes <rdar://problem/7447179>.

llvm-svn: 100832

show more ...

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead o

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).

llvm-svn: 91446

show more ...

Change tests to use clang -cc1...

llvm-svn: 91297

Implement the ObjC pseudo built-in types as clang "BuiltinType's". I say pseudo built-in types, since Sema still injects a typedef for recognition (i.e. they aren't truly built-ins from a parser pers

Implement the ObjC pseudo built-in types as clang "BuiltinType's". I say pseudo built-in types, since Sema still injects a typedef for recognition (i.e. they aren't truly built-ins from a parser perspective).

This removes the static data/methods on ObjCObjectPointerType while preserving the nice API (no need to fiddle with ASTContext:-).

This patch also adds Type::isObjCBuiltinType().

This should be the last fairly large patch related to recrafting the ObjC type system. The follow-on patches should be fairly small.

llvm-svn: 75808

show more ...

This patch includes a conceptually simple, but very intrusive/pervasive change.

The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObje

This patch includes a conceptually simple, but very intrusive/pervasive change.

The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches.

This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic.

By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time.

Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks.

llvm-svn: 75314

show more ...

Rename clang to clang-cc.

Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602

Fix a minor typo in the handling of the conditional operator for Objective-C interface pointers

llvm-svn: 60096

Downgrade incompatibilities with objc qualified types (e.g. id <P>) to warnings.
Note: One day, we should consider moving the actual diags to ObjCQualifiedIdTypesAreCompatible(), since it has more in

Downgrade incompatibilities with objc qualified types (e.g. id <P>) to warnings.
Note: One day, we should consider moving the actual diags to ObjCQualifiedIdTypesAreCompatible(), since it has more information on the actual problem. GCC currently emits slightly more instructive errors for some cases involving protocols. I added a FIXME to the code.

llvm-svn: 57529

show more ...

Improve type-checking of ?: for Objective-C types.
- Allow any Objective-C object types to devolve to type id in a ?:
expression. This matches gcc behavior more closely.

llvm-svn: 55705