Fixes: https://github.com/llvm/llvm-project/issues/78290
See the bug for more context.
```cpp
Gen ACoroutine() {
if constexpr (0) // remove it make clang compile.
co_return;
co_await Gen{};
}
```
We miss symbol of ctor of promise_type if the first coroutine statement
happens to be inside the disabled branch of `if constexpr`.
This happens because the promise object is built when we see the first
coroutine statement which is present in
`ExpressionEvaluationContext::DiscardedStatement` context due to `if
constexpr (0)`. This makes clang believe that the promise constructor is
only odr-used and not really "used".
The expr evaluation context for the coroutine body should not be related
to the context in which the first coroutine statement appears. We
override the context to `PotentiallyEvaluated`.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
### Problem
```cpp
co_task<int> coro() {
int a = 1;
auto lamb = [a]() -> co_task<int> {
co_return a; // 'a' in the lambda object dies after the iniital_suspend in the lambda coroutine.
}();
co_return co_await lamb;
}
```
[use-after-free](https://godbolt.org/z/GWPEovWWc)
Lambda captures (even by value) are prone to use-after-free once the
lambda object dies. In the above example, the lambda object appears only
as a temporary in the call expression. It dies after the first
suspension (`initial_suspend`) in the lambda.
On resumption in `co_await lamb`, the lambda accesses `a` which is part
of the already-dead lambda object.
---
### Solution
This problem can be formulated by saying that the `this` parameter of
the lambda call operator is a lifetimebound parameter. The lambda object
argument should therefore live atleast as long as the return object.
That said, this requirement does not hold if the lambda does not have a
capture list. In principle, the coroutine frame still has a reference to
a dead lambda object, but it is easy to see that the object would not be
used in the lambda-coroutine body due to no capture list.
It is safe to use this pattern inside a`co_await` expression due to the
lifetime extension of temporaries. Example:
```cpp
co_task<int> coro() {
int a = 1;
int res = co_await [a]() -> co_task<int> { co_return a; }();
co_return res;
}
```
---
### Background
This came up in the discussion with seastar folks on
[RFC](https://discourse.llvm.org/t/rfc-lifetime-bound-check-for-parameters-of-coroutines/74253/19?u=usx95).
This is a fairly common pattern in continuation-style-passing (CSP)
async programming involving futures and continuations. Document ["Lambda
coroutine
fiasco"](https://github.com/scylladb/seastar/blob/master/doc/lambda-coroutine-fiasco.md)
by Seastar captures the problem.
This pattern makes the migration from CSP-style async programming to
coroutines very bugprone.
Fixes https://github.com/llvm/llvm-project/issues/76995
---------
Co-authored-by: Chuanqi Xu <yedeng.yd@linux.alibaba.com>
This PR is proposing a fix for
https://github.com/llvm/llvm-project/issues/65971.
Previously, given a coroutine like this
```
task foo(int a) {
co_return;
}
```
Parameter `a` is never used. However, because C++ coroutines move
constructs the variable to a heap allocated coroutine activation frame,
we considered all parameters referenced. When diagnosing unused
parameters, we cannot distinguish if the variable reference was due to
coroutine parameter moves.
Compiler Explorer shows that GCC warns against this case correctly, but
clang does not: https://godbolt.org/z/Wo7dfqeaf
This patch addresses this issue by preserving the original
`ParmVarDecl`'s `Referenced` state.
This patch moves ElaboratedTypeKeyword before `Type` definition so that the enum is complete where bit-field for it is declared. It also converts it to scoped enum and removes `ETK_` prefix.
The goal of this change is to clean up some of the code surrounding
HLSL using CXXThisExpr as a non-pointer l-value. This change cleans up
a bunch of assumptions and inconsistencies around how the type of
`this` is handled through the AST and code generation.
This change is be mostly NFC for HLSL, and completely NFC for other
language modes.
This change introduces a new member to query for the this object's type
and seeks to clarify the normal usages of the this type.
With the introudction of HLSL to clang, CXXThisExpr may now be an
l-value and behave like a reference type rather than C++'s normal
method of it being an r-value of pointer type.
With this change there are now three ways in which a caller might need
to query the type of `this`:
* The type of the `CXXThisExpr`
* The type of the object `this` referrs to
* The type of the implicit (or explicit) `this` argument
This change codifies those three ways you may need to query
respectively as:
* CXXMethodDecl::getThisType()
* CXXMethodDecl::getThisObjectType()
* CXXMethodDecl::getThisArgType()
This change then revisits all uses of `getThisType()`, and in cases
where the only use was to resolve the pointee type, it replaces the
call with `getThisObjectType()`. In other cases it evaluates whether
the desired returned type is the type of the `this` expr, or the type
of the `this` function argument. The `this` expr type is used for
creating additional expr AST nodes and for member lookup, while the
argument type is used mostly for code generation.
Additionally some cases that used `getThisType` in simple queries could
be substituted for `getThisObjectType`. Since `getThisType` is
implemented in terms of `getThisObjectType` calling the later should be
more efficient if the former isn't needed.
Reviewed By: aaron.ballman, bogner
Differential Revision: https://reviews.llvm.org/D159247
Close https://github.com/llvm/llvm-project/issues/65054
The direct issue is still the call to coroutine_handle<>::address()
after await_suspend(). Without optimizations, the current logic will put
the temporary result of await_suspend() to the coroutine frame since the
middle end feel the temporary is escaped from
coroutine_handle<>::address. To fix this fundamentally, we should wrap
the whole logic about await-suspend into a standalone function. See
https://github.com/llvm/llvm-project/issues/64945
And as a short-term workaround, we probably can mark
coroutine_handle<>::address() as always-inline so that the temporary
result may not be thought to be escaped then it won't be put on the
coroutine frame. Although it looks dirty, it is probably do-able since
the compiler are allowed to do special tricks to standard library
components.
The original patch is incorrect since it marks too many calls to be
noinline. It shows that it is bad to do analysis in the frontend again.
This patch tries to mark the await_suspend function as noinlne only.
---
Close https://github.com/llvm/llvm-project/issues/56301
Close https://github.com/llvm/llvm-project/issues/64151
Close https://github.com/llvm/llvm-project/issues/65018
See the summary and the discussion of
https://reviews.llvm.org/D157070
to get the full context.
As @rjmccall pointed out, the key point of the root cause is that
currently we didn't implement the semantics for '@llvm.coro.save'
well ("after the await-ready returns false, the coroutine is considered
to be suspended ") well.
Since the semantics implies that we (the compiler) shouldn't write
the spills into the coroutine frame in the await_suspend. But now it is
possible due to some combinations of the optimizations so the semantics are
broken. And the inlining is the root optimization of such optimizations.
So in this patch, we tried to add the `noinline` attribute to the
await_suspend function.
This looks slightly problematic since the users are able to call the
await_suspend function standalone. This is limited by the
implementation. On the one hand, we don't want the workaround solution
(See the proposed solution later) to be too complex. On the other hand,
it is rare to call await_suspend standalone. Also it is not semantically
incorrect to do so since the inlining is not part of the C++ standard.
Also as an optimization, we don't add the `noinline` attribute to
the await_suspend function if the awaiter is an empty class. This should be
correct since the programmers can't access the local variables in
await_suspend if the awaiter is empty. I think this is necessary for
the performance since it is pretty common.
The long term solution is:
call @llvm.coro.await_suspend(ptr %awaiter, ptr %handle,
ptr @awaitSuspendFn)
Then it is much easier to perform the safety analysis in the middle
end. If it is safe to inline the call to awaitSuspend, we can replace it
in the CoroEarly pass. Otherwise we could replace it in the CoroSplit
pass.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D157833
Coroutine co_yield/co_await/co_return are implemented by a serious of
synthesized CXXMemberExpr which have no lexical right-side parenthesis.
This fix uses the end loc of inner expr as the hypothetical RParenLoc of
CXXMemberExpr. For tools this might be an issue since the RParen token doesn't
exist (but has a valid location).
For future improvement, we might:
1. mark those inner (generated) exprs as implict (tools have chances to skip
these nodes) (by @aaron.ballman)
2. borrow the idea from InitListExpr, there are two forms, one is for semantic,
the other one is for syntactic, having these two split can make everything
easier (by @hokein)
Fixes https://github.com/llvm/llvm-project/issues/64483
Reviewed By: aaron.ballman, hokein
Differential Revision: https://reviews.llvm.org/D157296
In https://reviews.llvm.org/D146758, we handled the rare case that the
coroutine has a function-try-block. But it will be better to handle it
in the Sema part. This patch handles the preprocess.
Fix https://github.com/llvm/llvm-project/issues/56532
Effectively, this reverts behavior introduced in https://reviews.llvm.org/D117087,
which did two things:
1. Change delayed to early conversion of return object.
2. Introduced RVO possibilities because of early conversion.
This patches fixes (1) and removes (2). I already worked on a follow up for (2)
in a separated patch. I believe it's important to split these two because if the RVO
causes any problems we can explore reverting (2) while maintaining (1).
Notes on some testcase changes:
- `pr59221.cpp` changed to `-O1` so we can check that the front-end honors
the value checked for. Sounds like `-O3` without RVO is more likely
to work with LLVM optimizations...
- Comment out delete members `coroutine-no-move-ctor.cpp` since behavior
now requires copies again.
Differential Revision: https://reviews.llvm.org/D145639
This reverts commit 54225c457a336b1609c6d064b2b606a9238a28b9.
The lack of RVO causes compile errors in our code.
Reverting to unblock our integrate.
See D145639 for full discussion.
Fix https://github.com/llvm/llvm-project/issues/56532
Effectively, this reverts behavior introduced in https://reviews.llvm.org/D117087,
which did two things:
1. Change delayed to early conversion of return object.
2. Introduced RVO possibilities because of early conversion.
This patches fixes (1) and removes (2). I already worked on a follow up for (2)
in a separated patch. I believe it's important to split these two because if the RVO
causes any problems we can explore reverting (2) while maintaining (1).
Notes on some testcase changes:
- `pr59221.cpp` changed to `-O1` so we can check that the front-end honors
the value checked for. Sounds like `-O3` without RVO is more likely
to work with LLVM optimizations...
- Comment out delete members `coroutine-no-move-ctor.cpp` since behavior
now requires copies again.
Differential Revision: https://reviews.llvm.org/D145639
As we discussed before, we should stop supporting
std::experimental::coroutine_traits in clang17. Now the clang16 is
branched so we can clean them now.
All the removed tests have been duplicated before.
This reverts commit c4e6e771f255fb1da3d505534997b6a88195b012.
Since clang-tools-extra contains the use for
std::experimental::coroutine_traits, the previsou commit breaks the
build bot. Revert this one to make the bot green.
As we discussed before, we should stop supporting
std::experimental::coroutine_traits in clang17. Now the clang16 is
branched so we can clean them now.
All the removed tests have been duplicated before.
Close https://github.com/llvm/llvm-project/issues/60545.
Previously, we would only pass the size parameter to the deallocation
function if the type is completely the same. But it is good enough to
make them unqualified the smae.
Closing https://github.com/llvm/llvm-project/issues/56436
We can't support the GNU address of label extension in coroutines well
in current architecture. Since the coroutines are going to split into
pieces in the middle end so the address of labels are ambiguous that
time.
To avoid any further misunderstanding, we try to emit an error here.
Differential Revision: https://reviews.llvm.org/D131938
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
unevaluated context
Closes https://github.com/llvm/llvm-project/issues/58133
The direct cause for this issue is that the compilation process
continues after it found it is in a invalid state. [expr.await]p2 says
clearly that the co_await expressions are not allowed to appear in
unevaluated context. So we can exit early in this case. It also reduces
many redundant diagnostic messages (Such as 'expression with side
effects has no effect in an unevaluated context').
Now when the compiler can't find the sized deallocation function
correctly in promise_type if there are multiple deallocation function
overloads there.
According to [dcl.fct.def.coroutine]p12:
> If both a usual deallocation function with only a pointer parameter
> and a usual deallocation function with both a pointer parameter and a
> size parameter are found, then the selected deallocation function
> shall be the one with two parameters.
So when there are multiple deallocation functions, the compiler should
choose the sized one instead of the unsized one. The patch fixes this.
We should only use 'auto' in case we can know the type from the right
hand side of the expression. Also we need keep '*' around if the type is
a pointer actually. Few uses of 'auto' in SemaCoroutine.cpp and
CGCoroutine.cpp violates the rule. This commit tries to fix it.
Previously we may call Sema::FindAllocationFunctions directly to lookup
allocation functions directly instead of using our wrapped lambda
LookupAllocationFunction, which is slightly incosnsistent. It will be
helpful to refactor this for further changes.
Also previously, when we lookup 'operator new(std::size_t, std::nothrow_t)' in
case we found `get_return_object_on_allocation_failure` in the
promise_type, the compiler will try to look at the allocation function
in promise_type. However, this is not wanted actually. According to
[dcl.fct.def.coroutine]p10:
> if a global allocation function is selected, the
> ::operator new(size_t, nothrow_t) form is used.
So we should only lookup for `::operator (size_t, nothrow_t)` for the
global allocation function. For the allocation function in the
promise_type, the requirement is that it shouldn't throw, which has
already been checked.
Given users generally include headers from standard libs so it will
generally include the <new> header, so this change should be a trivial
one and shouldn't affect almost any user.
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
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
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
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
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.
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
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
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
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
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
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
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
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
