This is an archive of the discontinued LLVM Phabricator instance.

[C++20] [Coroutines] Conform the updates for CWG issue 2585
ClosedPublic

Authored by ChuanqiXu on May 23 2022, 1:38 AM.

Details

Summary

This is the following update for the update in CWG issue 2585: https://cplusplus.github.io/CWG/issues/2585.html

The new updates in CWG issue 2585 say that we shouldn't lookup ::operator new(std::size_t, p0, ..., p1) in global scope.

Diff Detail

Event Timeline

ChuanqiXu created this revision.May 23 2022, 1:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2022, 1:38 AM
ChuanqiXu requested review of this revision.May 23 2022, 1:38 AM
ChuanqiXu added a project: Restricted Project.May 23 2022, 1:38 AM
ChuanqiXu added a reviewer: Restricted Project.

Also needs some release notes.

clang/lib/Sema/SemaCoroutine.cpp
1293

Extra comment line.

1355

Can you explain how this works? I'm not seeing what part of the collection of placement args would prohibit the call you're talking about.

clang/test/SemaCXX/coroutine-allocs2.cpp
3

I'm not a fan at all of having a FIleCheck-type-test in Sema, and this DOES validate semantics. Is there any way to get this to emit an error instead? Perhaps declare the generated operator-new as 'deleted' and show that it chooses THAT one instead by an error?

ChuanqiXu updated this revision to Diff 431558.May 23 2022, 7:21 PM

Address comments.

ChuanqiXu added inline comments.May 23 2022, 7:29 PM
clang/lib/Sema/SemaCoroutine.cpp
1293

Oh, this is intended. I feel the format looks better with the blank line.

1355

The new version of CWG issue 2585 says: "We shouldn't generate an allocation call in global scope with (std::size_t, p0, ..., pn)". Also it says that we wouldn't lookup into global scope if we find operator new in promise_type. It implies that we should only generate an allocation call in promise_type scope with (std::size_t, p0, ..., pn). So we should only collect placement arguments if we saw operator new in promise_type scope.

In other words, if we don't add the check, it would collect placement arguments all the way so it would be possible to generate an allocation call in global scope with (std::size_t, p0, ..., pn), which violates the update of CWG issue 2585.

clang/test/SemaCXX/coroutine-allocs2.cpp
3

I tried to mark the allocation function as delete. But it doesn't work... And FileCheck is the only way I imaged. Another possible way might be to use FileCheck for dumped AST. But I feel it is worse since the ABI is more stable than the AST. (The format of AST is not guaranteed stable I thought.)

erichkeane accepted this revision.May 24 2022, 6:39 AM

I have a change to the release note that I'd like to see improved in SOME way, but I trust you to correct/reword as you wish. I'm still not particularly happy with the mechanism of the test, but I cannot come up with a way to cause the Semantic Analyzer to cause this.

I think I have a preference to move it to CodeGenCXX anyway however, since we're actually testing the code-generated output (this is not novel, we DO often use CodeGen tests to make sure proper overloads/etc get called).

clang/docs/ReleaseNotes.rst
152

I realize it isn't part of this patch, but this release note reads awkwardly... How about:

Clang will now find and emit a call to an allocation function in a promise_type body for coroutines. Additionally, to implement CWG2585, a coroutine will no longer generate a call to a global allocation function with the signature (std::size_t, p0, ..., pn).
This fixes Issue Issue 54881 <https://github.com/llvm/llvm-project/issues/54881>_.

clang/lib/Sema/SemaCoroutine.cpp
1293

Ah, the deletes made it not clear that this continued into the comment on 1294, so I thought this was a blank before code. Thanks for the clarification.

This revision is now accepted and ready to land.May 24 2022, 6:39 AM
ChuanqiXu updated this revision to Diff 431861.May 24 2022, 7:27 PM

Address comments.

I think I have a preference to move it to CodeGenCXX anyway however, since we're actually testing the code-generated output (this is not novel, we DO often use CodeGen tests to make sure proper overloads/etc get called).

It makes sense. Done.

Thanks for reviewing!

clang/docs/ReleaseNotes.rst
152

The suggested wording lacks a condition that we generate a call to allocation function in promise_type only if there is an allocation function name in the scope of promise_type. I try to add a condition based on your suggestions.

This revision was landed with ongoing or failed builds.May 24 2022, 7:32 PM
This revision was automatically updated to reflect the committed changes.