[cfe-dev] [Lifetime, Temporary] Generate ExprWithCleanups for trivially destructible tempoararies

[Tim Shen via cfe-dev]

Hi, I'm working on bug 27451 (https://llvm.org/bugs/show_bug.cgi?id=27451).

If the lifetime-extended temporary object is not trivially destructible,
there will be a ExprWithCleanups generated for the VarDecl, so calling
CodeGenFunction::pushCleanupAfterFullExpr to push a llvm.lifetime.end()
call as a cleanup (as clang currently does in non-temporary cases) just
works.

However, I learned that ExprWithCleanups will not be generated by Sema
::MaybeBindToTemporary, if the destructor is trivial, according to <
https://github.com/llvm-mirror/clang/blob/4a65931dcba82b23856d654eb77d133d0a3c59f2/lib/Sema/SemaExprCXX.cpp#L5593>;
and pushCleanupAfterFullExpr seems not working well without a
ExprWithCleanups, due to the absence of RunCleanupsScope <
https://github.com/llvm-mirror/clang/blob/717e5e20622b0f4ac3c16bb643ed6a36eef29603/lib/CodeGen/CGExpr.cpp#L1002
>.

If there is a ExprWithCleanups generated even for a trivially destructible
temporary, generating llvm.lifetime.end() is easy by calling
CodeGenFunction::pushCleanupAfterFullExpr.

This requires moving L5593 to L5550 in SemaExprCXX.cpp. The two-lines
change breaks 36 tests, most of which are checking for warnings, so I
suppose I also need to fix some warning detections.

Is this - by adding more ExprWithCleanups and fix tests - the correct way to
fix the temporary lifetime bug? I feel weird about the existence of
ExprWithCleanups in the first place, but that's off the topic.

Just for illustration, the attached patch fixes the bug, but doesn't fix
the tests though.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160427/8fb4e7b5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.diff
Type: application/octet-stream
Size: 5263 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160427/8fb4e7b5/attachment.obj>