r183359 - [analyzer] Fix a crash that occurs when processing an rvalue array.

[Anna Zaks]

On Jun 5, 2013, at 8:09 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Wed, Jun 5, 2013 at 6:05 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> On Jun 5, 2013, at 17:51 , Richard Smith <richard at metafoo.co.uk> wrote:
> 
>> On Wed, Jun 5, 2013 at 5:19 PM, Anna Zaks <ganna at apple.com> wrote:
>> Author: zaks
>> Date: Wed Jun  5 19:19:36 2013
>> New Revision: 183359
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=183359&view=rev
>> Log:
>> [analyzer] Fix a crash that occurs when processing an rvalue array.
>> 
>> When processing ArrayToPointerDecay, we expect the array to be a location, not a LazyCompoundVal.
>> Special case the rvalue arrays by using a location to represent them. This case is handled similarly
>> elsewhere in the code.
>> 
>> Hmm, maybe we should be generating a MaterializeTemporaryExpr between the ImplicitCastExpr and the array temporary?
> 
> Is there an array temporary? Or is the whole struct materialized?
> 
> The whole struct. MaterializeTemporaryExpr materializes the complete object of which its operand is a subobject, per the rules of [class.temporary]p5. 
>  
> The analyzer's had to do this before (for compound literals), so I didn't think about the wider implications, but clearly at run time some sort of temporary allocation is needed.
> 
> IR generation deals with this essentially by ignoring the value categories in the AST and emitting the getChars() call as an lvalue because it's used as an lvalue (this actually matches the odr-use rules quite nicely, despite not matching the rest of the language's rules). Constant expression evaluation deals with this by implicitly materializing a temporary when an array-to-pointer decay is performed on an array rvalue.
> 
> There is precedent for using MaterializeTemporaryExpr to take the address of a temporary. The -Waddress-of-temporary extension synthesizes a MaterializeTemporaryExpr in cases like this:
> 
>   struct S {};
>   void f(S *p);
>   f(&S());

It would be great not to have to special case these in neither the analyzer nor the other places.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130606/ba086172/attachment.html>