History log of /external/clang/test/SemaObjCXX/message.mm
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
260611a32535c851237926bfcf78869b13c07d5b 20-Jun-2012 John McCall <rjmccall@apple.com> Restructure how the driver communicates information about the
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall

As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.

I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158793 91177308-0d34-0410-b5e6-96231b3b80d8
b2f6820773aabff3c5c9e0dbb1cbbbda0d80c41f 06-Apr-2012 Patrick Beard <pcbeard@mac.com> Added a new attribute, objc_root_class, which informs the compiler when a root class is intentionally declared.
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154187 91177308-0d34-0410-b5e6-96231b3b80d8
d1e40d5389a4382cbebc97d54792f41ee0414af4 02-Oct-2011 John McCall <rjmccall@apple.com> Make -fobjc-nonfragile-abi the -cc1 default, since it's the
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.

This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.

Most, though, it involved a perl script to translate a ton
of test cases.

Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140957 91177308-0d34-0410-b5e6-96231b3b80d8
483dd2f55ee53bc765123ead3428aa4ad2682cf3 11-Jan-2011 Douglas Gregor <dgregor@apple.com> Ensure that the result type of an Objective-C class message send is
complete. However, if it returns a reference type, don't require the
type it refers to to be complete. Fixes <rdar://problem/8807070>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123214 91177308-0d34-0410-b5e6-96231b3b80d8
857736454fabeb828e399dce094bbb3aad64fba2 28-Sep-2010 Douglas Gregor <dgregor@apple.com> When we have two identifiers in a row in Objective-C, make sure to
verify that we aren't in a message-send expression before digging into
the identifier or looking ahead more tokens. Fixes a regression
(<rdar://problem/8483253>) I introduced with bracket insertion.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114968 91177308-0d34-0410-b5e6-96231b3b80d8
58f9e13e87e57236fee4b914eea9be6f92a1c345 05-Sep-2010 Chris Lattner <sabre@nondot.org> make clang print types as "const int *" instead of "int const*",
which is should have done from the beginning. As usual, the most
fun with this sort of change is updating all the testcases.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113090 91177308-0d34-0410-b5e6-96231b3b80d8
d52787433142ee5957fc84fe7c3d3d1218a80556 28-Aug-2010 Gabor Greif <ggreif@gmail.com> suppress annoying textual repetition as 'aka'

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112365 91177308-0d34-0410-b5e6-96231b3b80d8
1a15dae8be2b28e02b6639aa92b832465c5be420 17-Jun-2010 Douglas Gregor <dgregor@apple.com> Fix the recently-added warning about 'typename' and 'template'
disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106161 91177308-0d34-0410-b5e6-96231b3b80d8
732281de5d518fca96c449ae185ee56bde422c4f 15-Jun-2010 Douglas Gregor <dgregor@apple.com> Warn when a 'typename' or a 'template' keyword refers to a
non-dependent type or template name, respectively, in C++98/03. Fixes
PR7111 and <rdar://problem/8002682>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105968 91177308-0d34-0410-b5e6-96231b3b80d8
a41a8c5972c2632247ae7913cf6ce65d45f7e702 22-Apr-2010 Douglas Gregor <dgregor@apple.com> Whenever we complain about a failed initialization of a function or
method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:

t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
type 'int *' [-pedantic]
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102038 91177308-0d34-0410-b5e6-96231b3b80d8
688fc9b9b4323a294f5bf4f8a83f7c365edec573 22-Apr-2010 Douglas Gregor <dgregor@apple.com> Switch the initialization of Objective-C message parameters (as occurs
during message sends) over to the new initialization code and away
from the C-only CheckSingleAssignmentConstraints. The enables the use
of C++ types in method parameters and message arguments, as well as
unifying more initialiation code overall.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102035 91177308-0d34-0410-b5e6-96231b3b80d8
6aa14d832704ae176c92d4e0f22dfb3f3d83a70a 22-Apr-2010 Douglas Gregor <dgregor@apple.com> Implement parsing for message sends in Objective-C++. Message sends in
Objective-C++ have a more complex grammar than in Objective-C
(surprise!), because

(1) The receiver of an instance message can be a qualified name such
as ::I or identity<I>::type.
(2) Expressions in C++ can start with a type.

The receiver grammar isn't actually ambiguous; it just takes a bit of
work to parse past the type before deciding whether we have a type or
expression. We do this in two places within the grammar: once for
message sends and once when we're determining whether a []'d clause in
an initializer list is a message send or a C99 designated initializer.

This implementation of Objective-C++ message sends contains one known
extension beyond GCC's implementation, which is to permit a
typename-specifier as the receiver type for a class message, e.g.,

[typename compute_receiver_type<T>::type method];

Note that the same effect can be achieved in GCC by way of a typedef,

typedef typename computed_receiver_type<T>::type Computed;
[Computed method];

so this is merely a convenience.

Note also that message sends still cannot involve dependent types or

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102031 91177308-0d34-0410-b5e6-96231b3b80d8
2725ca8eb3354975ca77ed4b88ede7b60b216b9a 21-Apr-2010 Douglas Gregor <dgregor@apple.com> Rework the Parser-Sema interaction for Objective-C message
sends. Major changes include:

- Expanded the interface from two actions (ActOnInstanceMessage,
ActOnClassMessage), where ActOnClassMessage also handled sends to
"super" by checking whether the identifier was "super", to three
actions (ActOnInstanceMessage, ActOnClassMessage,
ActOnSuperMessage). Code completion has the same changes.
- The parser now resolves the type to which we are sending a class
message, so ActOnClassMessage now accepts a TypeTy* (rather than
an IdentifierInfo *). This opens the door to more interesting
types (for Objective-C++ support).
- Split ActOnInstanceMessage and ActOnClassMessage into parser
action functions (with their original names) and semantic
functions (BuildInstanceMessage and BuildClassMessage,
respectively). At present, this split is onyl used by
ActOnSuperMessage, which decides which kind of super message it
has and forwards to the appropriate Build*Message. In the future,
Build*Message will be used by template instantiation.
- Use getObjCMessageKind() within the disambiguation of Objective-C
message sends vs. array designators.

Two notes about substandard bits in this patch:
- There is some redundancy in the code in ParseObjCMessageExpr and
ParseInitializerWithPotentialDesignator; this will be addressed
shortly by centralizing the mapping from identifiers to type names
for the message receiver.
- There is some #if 0'd code that won't likely ever be used---it
handles the use of 'super' in methods whose class does not have a
superclass---but could be used to model GCC's behavior more
closely. This code will die in my next check-in, but I want it in

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102021 91177308-0d34-0410-b5e6-96231b3b80d8
36262b81559cfce4f67256d052e4fed343a02861 19-Feb-2010 Douglas Gregor <dgregor@apple.com> Implement C++ name lookup for instance variables of Objective-C classes
from an instance method. Previously, we were following the Objective-C
name lookup rules for ivars, which are of course completely different
from and incompatible with the Objective-C++ rules.

For the record, the Objective-C++ rules are the sane ones.

This is another part of <rdar://problem/7660386>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96677 91177308-0d34-0410-b5e6-96231b3b80d8
c5e77d5a97b495c41cb65c25b6f0ba2b62a14345 19-Feb-2010 Douglas Gregor <dgregor@apple.com> Make Sema::ActOnClassMessage robust when name lookup for the receiver
name finds something other than a TypedefDecl or an
ObjCInterfaceDecl. This is a small part of <rdar://problem/7660386>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96676 91177308-0d34-0410-b5e6-96231b3b80d8