[NFC] [Coroutines] Add test for ambiguous allocation functions in
promise_type

Address the post-commit comment in
https://reviews.llvm.org/D125517#inline-1217244

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

According to the updates in CWG issue 2585
https://cplusplus.github.io/CWG/issues/2585.html, we shouldn't find an
allocation function with

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

According to the updates in CWG issue 2585
https://cplusplus.github.io/CWG/issues/2585.html, we shouldn't find an
allocation function with (size, p0, …, pn) in global scope.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D126187

show more ...

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

This reverts commit 1b89a25a9b960886e486eb20b755634613c088f8.

The test would fail in windows versions.

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

According to the updates in CWG issue 2585
https://cplusplus.github.io/CWG/issues/2585.html, we shouldn't find an
allocation function with

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

According to the updates in CWG issue 2585
https://cplusplus.github.io/CWG/issues/2585.html, we shouldn't find an
allocation function with (size, p0, …, pn) in global scope.

show more ...

[clang] Expose CoawaitExpr's operand in the AST

Previously the Expr returned by getOperand() was actually the
subexpression common to the "ready", "suspend", and "resume"
expressions, which often is

[clang] Expose CoawaitExpr's operand in the AST

Previously the Expr returned by getOperand() was actually the
subexpression common to the "ready", "suspend", and "resume"
expressions, which often isn't just the operand but e.g.
await_transform() called on the operand.

It's important for the AST to expose the operand as written
in the source for traversals and tools like clangd to work
correctly.

Fixes https://github.com/clangd/clangd/issues/939

Differential Revision: https://reviews.llvm.org/D115187

show more ...

[Frontend] [Coroutines] Emit error when we found incompatible allocation
function in promise_type

According to https://cplusplus.github.io/CWG/issues/2585.html, this
fixes https://github.com/llvm/ll

[Frontend] [Coroutines] Emit error when we found incompatible allocation
function in promise_type

According to https://cplusplus.github.io/CWG/issues/2585.html, this
fixes https://github.com/llvm/llvm-project/issues/54881

Simply, the clang tried to found (do lookup and overload resolution. Is
there any better word to use than found?) allocation function in
promise_type and global scope. However, this is not consistent with the
standard. The standard behavior would be that the compiler shouldn't
lookup in global scope in case we lookup the allocation function name in
promise_type. In other words, the program is ill-formed if there is
incompatible allocation function in promise type.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D125517

show more ...

Add some helpers to better check Scope's kind. NFC

Signed-off-by: Jun Zhang <[email protected]>

Use llvm::append_range instead of push_back loops where applicable. NFCI.

[C++20] [Coroutines] Implement return value optimization for get_return_object

This patch tries to implement RVO for coroutine's return object got from
get_return_object.
From [dcl.fct.def.coroutine

[C++20] [Coroutines] Implement return value optimization for get_return_object

This patch tries to implement RVO for coroutine's return object got from
get_return_object.
From [dcl.fct.def.coroutine]/p7 we could know that the return value of
get_return_object is either a reference or a prvalue. So it makes sense
to do copy elision for the return value. The return object should be
constructed directly into the storage where they would otherwise be
copied/moved to.

Test Plan: folly, check-all

Reviewed By: junparser

Differential revision: https://reviews.llvm.org/D117087

show more ...

[clang][sema] checkNoThrow - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

The pointer is referenced immediately, so assert the cast is correct instead of returning nullptr

[C++20] [Coroutines] Warning for always_inline coroutine

See the discussion in https://reviews.llvm.org/D100282. The coroutine
marked always inline might not be inlined properly in current compiler

[C++20] [Coroutines] Warning for always_inline coroutine

See the discussion in https://reviews.llvm.org/D100282. The coroutine
marked always inline might not be inlined properly in current compiler
support. Since the coroutine would be splitted into pieces. And the call
to resume() and destroy() functions might be indirect call. Also the
ramp function wouldn't get inlined under O0 due to pipeline ordering
problems. It might be different to what users expects to. Emit a warning
to tell it.

This is what GCC does too: https://godbolt.org/z/7eajb1Gf8

Reviewed By: Quuxplusone

Differential Revision: https://reviews.llvm.org/D115867

show more ...

[clang][NFC] Change some ->getType()->isPlaceholderType() to just ->hasPlaceholderType()

Differential Revision: https://reviews.llvm.org/D118518

[NFC] [Coroutines] Refactor implementation in checkFinalSuspendNoThrow

Now when we are checking if the expression `co_await
promise.final_suspend()` is not throw, we would check unconditionally
for

[NFC] [Coroutines] Refactor implementation in checkFinalSuspendNoThrow

Now when we are checking if the expression `co_await
promise.final_suspend()` is not throw, we would check unconditionally
for its child expressions recursively. It takes unnecessary time. And
the compiler would complains if the implementation in final_suspend()
may throw even if the higher level function signature marked noexcept
already.

This fixes bug48453 too.

show more ...

[NFC] Remove invisible character in comments

[clang] Allow using std::coroutine_traits in std::experimental

This is that diff I was aiming for. When transitioning code from
coroutines-ts to c++20, it can be useful to add a using declaration

[clang] Allow using std::coroutine_traits in std::experimental

This is that diff I was aiming for. When transitioning code from
coroutines-ts to c++20, it can be useful to add a using declaration to
std::experimental pointing to std::coroutine_traits. This permits
that use by checking whether lookup in std::experimentl finds a
different decl to lookup in std. You still get a warning about
std::experimental::coroutine_traits being a thing, just not an error.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D115943

show more ...

[clang] More informative mixed namespace diagnostics

First, let's check we get a TemplateDecl, before complaining about
where it might have been found.

Second, if it came from an unexpected place,

[clang] More informative mixed namespace diagnostics

First, let's check we get a TemplateDecl, before complaining about
where it might have been found.

Second, if it came from an unexpected place, show where that location is.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D116164

show more ...

[C++20] [Coroutines] Allow promise_type to not define return_void or return_value

According to [dcl.fct.def.coroutine]p6, the promise_type is allowed to
not define return_void nor return_value:

> I

[C++20] [Coroutines] Allow promise_type to not define return_void or return_value

According to [dcl.fct.def.coroutine]p6, the promise_type is allowed to
not define return_void nor return_value:

> If searches for the names return_­void and return_­value in the scope
> of the promise type each find any declarations, the program is
> ill-formed.
> [Note 1: If return_­void is found, flowing off the end of a coroutine is
> equivalent to a co_­return with no operand. Otherwise, flowing off the
> end of a coroutine results in
> undefined behavior ([stmt.return.coroutine]). — end note]

So the program isn't ill-formed if the promise_type doesn't define
return_void nor return_value. It is just a potential UB. So the program
should be allowed to compile.

Reviewed By: urnathan

Differential Revision: https://reviews.llvm.org/D116204

show more ...

[C++20] Conform coroutine's comments in clang (NFC-ish)

The comments for coroutine in clang wrote for coroutine-TS. Now
coroutine is merged into standard. Try to conform the comments.

[clang][NFC] Refactor coroutine_traits lookup

To allow transition from the TS-specified
std::experimental::coroutine_traits to the C++20-specified
std::coroutine_traits, we lookup in both places and

[clang][NFC] Refactor coroutine_traits lookup

To allow transition from the TS-specified
std::experimental::coroutine_traits to the C++20-specified
std::coroutine_traits, we lookup in both places and provide helpful
diagnostics. This refactors the code to avoid separate paths to
std::experimental lookups.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D116029

show more ...

[clang] Adjust coroutine namespace diagnostics

The diagnostics concerning mixing std::experimental and std are
somewhat wordy and have some typographical errors. Diagnostics do not
start with a cap

[clang] Adjust coroutine namespace diagnostics

The diagnostics concerning mixing std::experimental and std are
somewhat wordy and have some typographical errors. Diagnostics do not
start with a capital letter nor end with a fullstop. Usually we try
and link clauses with a semicolon, rather than start a new sentence.
So that's what this patch does. Along with avoiding repetition about
std::experimental going away.

Differential Revision: https://reviews.llvm.org/D116026

show more ...

[Coroutine] Warn deprecated 'std::experimental::coro' uses

Since we've decided the to not support std::experimental::coroutine*, we
should tell the user they need to update.

Reviewed By: Quuxpluson

[Coroutine] Warn deprecated 'std::experimental::coro' uses

Since we've decided the to not support std::experimental::coroutine*, we
should tell the user they need to update.

Reviewed By: Quuxplusone, ldionne, Mordante

Differential Revision: https://reviews.llvm.org/D113977

show more ...

[Coroutines] [Frontend] Lookup in std namespace first

Now in libcxx and clang, all the coroutine components are defined in
std::experimental namespace.
And now the coroutine TS is merged into C++20.

[Coroutines] [Frontend] Lookup in std namespace first

Now in libcxx and clang, all the coroutine components are defined in
std::experimental namespace.
And now the coroutine TS is merged into C++20. So in the working draft
like N4892, we could find the coroutine components is defined in std
namespace instead of std::experimental namespace.
And the coroutine support in clang seems to be relatively stable. So I
think it may be suitable to move the coroutine component into the
experiment namespace now.

This patch would make clang lookup coroutine_traits in std namespace
first. For the compatibility consideration, clang would lookup in
std::experimental namespace if it can't find definitions in std
namespace. So the existing codes wouldn't be break after update
compiler.

And in case the compiler found std::coroutine_traits and
std::experimental::coroutine_traits at the same time, it would emit an
error for it.

The support for looking up std::experimental::coroutine_traits would be
removed in Clang16.

Reviewed By: lxfind, Quuxplusone

Differential Revision: https://reviews.llvm.org/D108696

show more ...

[clang] don't mark as Elidable CXXConstruct expressions used in NRVO

See PR51862.

The consumers of the Elidable flag in CXXConstructExpr assume that
an elidable construction just goes through a sin

[clang] don't mark as Elidable CXXConstruct expressions used in NRVO

See PR51862.

The consumers of the Elidable flag in CXXConstructExpr assume that
an elidable construction just goes through a single copy/move construction,
so that the source object is immediately passed as an argument and is the same
type as the parameter itself.

With the implementation of P2266 and after some adjustments to the
implementation of P1825, we started (correctly, as per standard)
allowing more cases where the copy initialization goes through
user defined conversions.

With this patch we stop using this flag in NRVO contexts, to preserve code
that relies on that assumption.
This causes no known functional changes, we just stop firing some asserts
in a cople of included test cases.

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D109800

show more ...

Revert "[Coroutines] [Clang] Look up coroutine component in std namespace first"

This reverts commit 2fbd254aa46b, which broke the libc++ CI. I'm reverting
to get things stable again until we've fig

Revert "[Coroutines] [Clang] Look up coroutine component in std namespace first"

This reverts commit 2fbd254aa46b, which broke the libc++ CI. I'm reverting
to get things stable again until we've figured out a way forward.

Differential Revision: https://reviews.llvm.org/D108696

show more ...

[Coroutines] [Clang] Look up coroutine component in std namespace first

Summary: Now in libcxx and clang, all the coroutine components are
defined in std::experimental namespace.
And now the corouti

[Coroutines] [Clang] Look up coroutine component in std namespace first

Summary: Now in libcxx and clang, all the coroutine components are
defined in std::experimental namespace.
And now the coroutine TS is merged into C++20. So in the working draft
like N4892, we could find the coroutine components is defined in std
namespace instead of std::experimental namespace.
And the coroutine support in clang seems to be relatively stable. So I
think it may be suitable to move the coroutine component into the
experiment namespace now.

But move the coroutine component into the std namespace may be an break
change. So I planned to split this change into two patch. One in clang
and other in libcxx.

This patch would make clang lookup coroutine_traits in std namespace
first. For the compatibility consideration, clang would lookup in
std::experimental namespace if it can't find definitions in std
namespace and emit a warning in this case. So the existing codes
wouldn't be break after update compiler.

Test Plan: check-clang, check-libcxx

Reviewed By: lxfind

Differential Revision: https://reviews.llvm.org/D108696

show more ...