[cfe-commits] [Patch] Fix for PR2709

[Douglas Gregor]

On Dec 1, 2011, at 7:54 AM, Erik Verbruggen wrote:

> On 15-11-11 18:46, Douglas Gregor wrote:
>> 
>> On Nov 15, 2011, at 8:45 AM, Erik Verbruggen wrote:
> 
>> @@ -145,7 +145,11 @@ Decl *Parser::ParseObjCAtInterfaceDeclaration(SourceLocation atLoc,
>>                                                ParsedAttributes&attrs) {
>>    assert(Tok.isObjCAtKeyword(tok::objc_interface)&&
>>           "ParseObjCAtInterfaceDeclaration(): Expected @interface");
>> -  ConsumeToken(); // the "interface" identifier
>> +  const IdentifierInfo *IFaceII = Tok.getIdentifierInfo();
>> +  const SourceLocation IFaceTok = ConsumeToken(); // the "interface" identifier
>> +  if (Actions.CurContext->isObjCContainer())
>> +      Diag(IFaceTok, diag::warn_objc_nested_container_decl)
>> +<<  IFaceII->getName();
>> 
>> Two comments: (1) the parser shouldn't be poking at Actions.CurContext. Most likely, this check should move into Sema. (2) it seems like the most common case of having an @interface/@implementation/@protocol nested inside another one is actually a missing @end; it's probably best to provide that as a Fix-It and pretend as if the @end were there.
> 
> Ok, I can move the check, but that means that I will also have to move the error from DiagnosticParserKinds to DiagnosticSemaKinds, and move the two existing checks to Sema. Is that ok?
> 
> Then to generate an @end, I will have to call ActOnAtEnd from Sema, right?

Right.

> Of course, I could also create a proxy method on Sema that checks if the current context is an ObjC container. I think that might actually be cleaner.


I'd prefer this solution, which just asks Sema whether we're already inside an ObjC container. Then the parser will handle recovery for what is essentially a parsing issue, calling Sema's ActOnAtEnd and producing the error/Fix-It.

	- Doug