[cfe-dev] A disappearing CXXBindTemporaryExpr.

Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org
Tue Apr 3 11:21:15 PDT 2018


Thanks for the help!

I don't think i'll be able to help with the proposed refactoring on the 
AST side, but i'll be happy to update the analyzer when 
CXXBindTemporaryExpr is removed. This sounds like something we could 
totally work with, and it'd be much cleaner than what we currently have.

On 3/29/18 9:54 PM, John McCall via cfe-dev wrote:
>> On Mar 29, 2018, at 7:31 PM, Richard Smith <richard at metafoo.co.uk 
>> <mailto:richard at metafoo.co.uk>> wrote:
>>
>> On 29 March 2018 at 14:42, John McCall via cfe-dev 
>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>>     On Mar 29, 2018, at 5:32 PM, Richard Smith
>>>     <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
>>>
>>>     On 29 March 2018 at 14:19, John McCall via cfe-dev
>>>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>>
>>>>         On Mar 29, 2018, at 5:10 PM, Richard Smith via cfe-dev
>>>>         <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>>>
>>>>         Looks like a bug to me, probably template instantiation for
>>>>         the initializer is stripping this node out and we're
>>>>         failing to recreate it when redoing the initialization in
>>>>         the instantiation.
>>>>
>>>>         But I wonder whether we should just ditch the
>>>>         CXXBindTemporaryExpr node entirely. The purpose of marking
>>>>         where a temporary is created that needs a cleanup is
>>>>         handled much better by looking for
>>>>         CXXMaterializeTemporaryExprs (since they also track whether
>>>>         the temporary was lifetime-extended), and it doesn't seem
>>>>         like an imposition to ask clients to work out for
>>>>         themselves whether the type of the temporary needs destruction.
>>>>
>>>>         This would require us to start creating
>>>>         CXXMaterializeTemporaryExprs in C++98 for cases like
>>>>         "A().n", where we currently avoid doing so because the
>>>>         language rules say that expression is an rvalue, which in
>>>>         turn means (carefully) extending the C++11 xvalue rules to
>>>>         C++98 mode. But that seems feasible -- the hardest part is
>>>>         likely going to be avoiding using the term "xvalue" in
>>>>         C++98 diagnostics :)
>>>
>>>         If we're going to do this, I think it would make sense to
>>>         just store a "semantic value kind" that papers over as many
>>>         of these language differences as possible, with the
>>>         understanding that queries about the formal value kind have
>>>         to be parameterized by LangOpts.  So it would have options like:
>>>           - complete pr-value
>>>           - pr-value subobject
>>>           - l-value
>>>           - x-value
>>>           - function reference (because C considers these r-values)
>>>
>>>         Obviously, some differences (like compound literals) are
>>>         real semantic differences between languages, but most of the
>>>         rest of these are extremely artificial and clients ought  to
>>>         be able to ignore them.
>>>
>>>
>>>     Oh great, now we have a "naming things" problem too ;-)
>>
>>     Heh, yeah, I was writing that and questioning everything I put
>>     down. :)
>>
>>>     Yes, I agree, that makes a lot of sense.
>>>
>>>     If we're going to take on this work, I think we should also
>>>     consider what should become of ExprClassification.cpp versus the
>>>     value kind + object kind bits on Expr. It doesn't make much
>>>     sense to have two independent mechanisms computing largely the
>>>     same information.
>>
>>     I agree that we might be able to get rid of ExprClassification.
>>
>>>     Also, do we need the ObjC parameter / subscript ObjectKind given
>>>     that we have PseudoObject placeholder types to identify the
>>>     relevant expressions?
>>
>>     Yes, that's true, I think we no longer need a special object kind
>>     for these.
>>
>>>     (Conversely, compatibility with modern GCC suggests we should
>>>     have an "underaligned field" object kind, reference bindings to
>>>     which implicitly create temporaries just like for bit-fields.)
>>
>>     Hmm, I feel like this might be more a special-case semantic rule
>>     for reference-binding than an actual difference in the expression.
>>
>>
>> As far as I can tell, it propagates through expressions exactly like 
>> bit-field-ness, and generally acts like the expression is half-way to 
>> being a bit-field (https://godbolt.org/g/teWxN7), affecting reference 
>> binding but not preventing taking the address.
>
> That's fair.
>
> John.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180403/49f54eb9/attachment.html>


More information about the cfe-dev mailing list