[cfe-dev] InitListExpr with void type

[Douglas Gregor]

On Jan 27, 2009, at 3:26 PM, Ted Kremenek wrote:

>
> On Jan 27, 2009, at 3:14 PM, Douglas Gregor wrote:
>
>> On Jan 27, 2009, at 2:44 PM, Ted Kremenek wrote:
>>> Today I was running the latest build of the static analyzer over the
>>> Wine sources and noticed a crash in its handling of  
>>> InitListExprs.  I
>>> won't go into the gory details; essentially there are cases where an
>>> InitListExpr can have type 'void' and this is a case the analyzer  
>>> does
>>> not (yet) handle.
>>
>> Blech.
>>
>>> My question is whether or not it is valid for InitListExprs to  
>>> have a
>>> 'void' type, and if so, how should they be interpreted?
>>
>> IMO, it isn't valid. After semantic analysis of the initializer  
>> list, all InitListExprs should have the type of the object they  
>> initialize. If the InitListExpr still has void type, then either  
>> (1) it's an invalid AST node and we shouldn't be looking at it, or  
>> (2) there's a bug in semantic analysis of initializer lists.
>
> That's what I thought.  If it an invalid AST node, should we just  
> reject the file?

Yes. We should error and then not link the invalid AST node into the  
AST produced.

>  If we don't build the InitListExpr correctly because of [insert  
> some feature not implemented yet] it seems that we should just abort  
> with a fail-stop error in Sema rather than having unpredictable  
> behavior in clients that assume the ASTs are kosher.


In this case, our misinterpretation of the initializer resulted in a  
warning, not a hard error, so it thought the AST was valid.

The real issue is that we need an assert that says: after we've  
processed the initializer list, we either had an error or our  
InitListExpr type is not void. No path should sneak through the  
semantic analysis without setting the type or reporting an error.

	- Doug