region with implicit default inside the member function.
This is to fix assert when field is referenced in OpenMP region with
default (first|private) clause inside member function.
The problem of assert is that the capture is not generated for the field.
This patch is to generate capture when the field is used with implicit
default, use it in the code, and save the capture off to make sure it is
considered from that point and add first/private clauses.
1> Add new field ImplicitDefaultFirstprivateFDs in SharingMapTy, used to
store generated capture fields info.
2> In function isOpenMPCaptureDecl: the caputer is generated and saved
in ImplicitDefaultFirstprivateFDs.
3> Add new help functions:
getImplicitFDCapExprDecl
isImplicitDefaultFirstprivateFD
addImplicitDefaultFirstprivateFD
4> Add addition argument in hasDSA to check default attribute for
default(first|private).
5> The isImplicitDefaultFirstprivateFD is used in VisitDeclRefExpr to
build the implicit clause.
6> Add new parameter "Context" for buildCaptureDecl, due to when capture
field, the parent context is needed to be used.
7> Change in isOpenMPPrivateDecl where stop propagate the capture from
the enclosing region for private variable.
8> In ActOnOpenMPFirstprivate/ActOnOpenMPPrivate, using captured info
to generate first|private clause.
9> Add new function isOpenMPRebuildMemberExpr: use to determine if field
needs to be rebuild during template instantiation.
Differential Revision: https://reviews.llvm.org/D127803
This patch gives basic parsing and semantic support for
"parallel masked taskloop simd" construct introduced in
OpenMP 5.1 (section 2.16.10)
Differential Revision: https://reviews.llvm.org/D128946
This reverts commit d4d47e574e.
This fixes the lldb crash that was observed by ensuring that our
friend-'template contains reference to' TreeTransform properly handles a
TemplateDecl.
This patch gives basic parsing and semantic support for
"parallel masked taskloop" construct introduced in
OpenMP 5.1 (section 2.16.9)
Differential Revision: https://reviews.llvm.org/D128834
This reverts commit 2f20743952 because it
triggers an assertion when building an LLDB test program:
Assertion failed: (InstantiatingSpecializations.empty() && "failed to
clean up an InstantiatingTemplate?"), function ~Sema, file
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Sema/Sema.cpp,
line 458.
More details in https://reviews.llvm.org/D126907.
This patch gives basic parsing and semantic support for
"masked taskloop simd" construct introduced in OpenMP 5.1 (section 2.16.8)
Differential Revision: https://reviews.llvm.org/D128693
This patch gives basic parsing and semantic support for "masked taskloop"
construct introduced in OpenMP 5.1 (section 2.16.7)
Differential Revision: https://reviews.llvm.org/D128478
This is a support for " #pragma omp atomic compare fail ". It has Parser & AST support for now.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D123235
Adds support for the reserved locator 'omp_all_memory' for use
in depend clauses with 'out' or 'inout' dependence-types.
Differential Revision: https://reviews.llvm.org/D125828
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
This includes a fix for the libc++ issue I ran across with friend
declarations not properly being identified as overloads.
This reverts commit 45c07db31c.
This reverts commit a97899108e.
The patch caused some problems with the libc++ `__range_adaptor_closure`
that I haven't been able to figure out the cause of, so I am reverting
while I figure out whether this is a solvable problem/issue with the
CFE, or libc++ depending on an older 'incorrect' behavior.
This reverts commit 0c31da4838.
I've solved the issue with the PointerUnion by making the
`FunctionTemplateDecl` pointer be a NamedDecl, that could be a
`FunctionDecl` or `FunctionTemplateDecl` depending. This is enforced
with an assert.
This reverts commit 4b6c2cd647.
The patch caused numerous ARM 32 bit build failures, since we added a
5th item to the PointerUnion, and went over the 2-bits available in the
32 bit pointers.
As reported here: https://github.com/llvm/llvm-project/issues/44178
Concepts are not supposed to be instantiated until they are checked, so
this patch implements that and goes through significant amounts of work
to make sure we properly re-instantiate the concepts correctly.
Differential Revision: https://reviews.llvm.org/D119544
This reverts commit 69dd89fdcb.
This reverts commit 04000c2f92.
The current states breaks libstdc++ usage (https://reviews.llvm.org/D119136#3455423).
The fixup has been reverted as it caused other valid code to be disallowed.
I think we should start from the clean state by reverting all relevant commits.
D119136 changed how captures are handled in a lambda call operator
declaration, but did not properly handled dependant context,
which led to crash when refering to init-captures in
a trailing return type.
We fix that bug by making transformations more symetric with parsing,
ie. we first create the call operator, then transform the capture,
then compute the type of the lambda call operaror.
This ensures captures exist and have the right type when
we parse a trailing requires-clause / return type.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124012
Implement P2036R3.
Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.
Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.
The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.
The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.
We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.
The order of operations is as follow:
* Parse the init capture in the lambda's parent scope
* Introduce a lambda scope
* Create the lambda class and call operator
* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).
* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.
* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).
* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.
* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.
At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).
Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119136
Implement P2036R3.
Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.
Up until now, the entire lambda declaration up to the start
of the body would be parsed in the parent scope, such that
captures would not be available to look up.
The scoping is changed to have an outer lambda scope,
followed by the lambda prototype and body.
The lambda scope is necessary because there may be a template scope
between the start of the lambda (to which we want to attach
the captured variable) and the prototype scope.
We also need to introduce a declaration context to attach the captured
variable to (and several parts of clang assume captures are handled from
the call operator context), before we know the type of the call operator.
The order of operations is as follow:
* Parse the init capture in the lambda's parent scope
* Introduce a lambda scope
* Create the lambda class and call operator
* Add the init captures to the call operator context and the lambda scope.
But the variables are not capured yet (because we don't know their type).
Instead, explicit captures are stored in a temporary map that
conserves the order of capture (for the purpose of having a stable order in the ast dumps).
* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.
* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context,
we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).
* The lambda qualifiers are parsed, at this point,
we can switch (for the second time) inside the lambda context,
unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.
* We can parse the rest of the lambda type, transform the lambda and call operator's types and also
transform the call operator to a template function decl where necessary.
At this point, both captures and parameters can be injected in the body's scope.
When trying to capture an implicit variable, if we are before the qualifiers of a lambda,
we need to remember that the variables are still in the parent's context (rather than in the call operator's).
This is a recommit of adff142dc2 after a fix in d8d793f29b
Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119136
This reverts commit adff142dc2.
This broke clang bootstrap: it made existing C++ code in LLVM invalid:
llvm/include/llvm/CodeGen/LiveInterval.h:630:53: error: captured variable 'Idx' cannot appear here
[=](std::remove_reference_t<decltype(*Idx)> V,
^
Implement P2036R3.
Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.
Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.
The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.
The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.
We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.
The order of operations is as follow:
* Parse the init capture in the lambda's parent scope
* Introduce a lambda scope
* Create the lambda class and call operator
* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).
* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.
* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).
* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.
* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.
At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).
Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119136
This builtin returns the address of a global instance of the
`std::source_location::__impl` type, which must be defined (with an
appropriate shape) before calling the builtin.
It will be used to implement std::source_location in libc++ in a
future change. The builtin is compatible with GCC's implementation,
and libstdc++'s usage. An intentional divergence is that GCC declares
the builtin's return type to be `const void*` (for
ease-of-implementation reasons), while Clang uses the actual type,
`const std::source_location::__impl*`.
In order to support this new functionality, I've also added a new
'UnnamedGlobalConstantDecl'. This artificial Decl is modeled after
MSGuidDecl, and is used to represent a generic concept of an lvalue
constant with global scope, deduplicated by its value. It's possible
that MSGuidDecl itself, or some of the other similar sorts of things
in Clang might be able to be refactored onto this more-generic
concept, but there's enough special-case weirdness in MSGuidDecl that
I gave up attempting to share code there, at least for now.
Finally, for compatibility with libstdc++'s <source_location> header,
I've added a second exception to the "cannot cast from void* to T* in
constant evaluation" rule. This seems a bit distasteful, but feels
like the best available option.
Reviewers: aaron.ballman, erichkeane
Differential Revision: https://reviews.llvm.org/D120159
Previously, we would instantiate the UDL by marking the function as
referenced and potentially binding to a temporary; this skipped
transforming the call when the UDL was dependent on a template
parameter.
Now, we defer all the work to instantiating the call expression for the
UDL. This ensures that constant evaluation occurs at compile time
rather than deferring until runtime.
Fixes Issue 54578.
There seems to be more than one way to get to that state. I included to
example cases in the test, both were noticed recently.
There is room for improvement, for example by creating RecoveryExpr in
place of the bad initializer, but for now let's stop the crashes.
Differential Revision: https://reviews.llvm.org/D121824
Adds basic parsing/sema/serialization support for the
#pragma omp target parallel loop directive.
Differential Revision: https://reviews.llvm.org/D122359
Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note. But this is not enough for btf_type_tag
as the attribute might have the same ModifiedType and EquivType, but
still have different string associated with attribute.
For example, for a data structure like below,
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b;
};
The current ASTContext.getAttributedType() will produce
an AST similar to below:
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *b;
};
and this is incorrect.
It is very difficult to use the current AttributedType as it is hard to
get the tag information. To fix the problem, this patch introduced
BTFTagAttributedType which is similar to AttributedType
in many ways but with an additional BTFTypeTagAttr. The tag itself can
be retrieved with BTFTypeTagAttr.
With the new BTFTagAttributed type, the debuginfo code can be greatly
simplified compared to previous TypeLoc based approach.
Differential Revision: https://reviews.llvm.org/D120296
Otherwise we will fail to generate the definition of a defaulted destructor,
if the only reference was in a templated temporary.
rdar://89366678
Differential Revision: https://reviews.llvm.org/D120426
Otherwise callers of these functions have to check both the return value
for and the contents of the returned llvm::Optional.
Fixes#53742
Differential Revision: https://reviews.llvm.org/D119525
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
Implement P2128R6 in C++23 mode.
Unlike GCC's implementation, this doesn't try to recover when a user
meant to use a comma expression.
Because the syntax changes meaning in C++23, the patch is *NOT*
implemented as an extension. Instead, declaring an array with not
exactly 1 parameter is an error in older languages modes. There is an
off-by-default extension warning in C++23 mode.
Unlike the standard, we supports default arguments;
Ie, we assume, based on conversations in WG21, that the proposed
resolution to CWG2507 will be accepted.
We allow arrays OpenMP sections and C++23 multidimensional array to
coexist:
[a , b] multi dimensional array
[a : b] open mp section
[a, b: c] // error
The rest of the patch is relatively straight forward: we take care to
support an arbitrary number of arguments everywhere.
Bug #52905 was originally papered over in a different way, but
I believe this is the actually proper fix, or at least closer to
it. We need to detect placeholder types as close to the front-end
as possible, and cause them to fail constraints, rather than letting
them persist into later stages.
Fixes#52905.
Fixes#52909.
Fixes#53075.
Differential Revision: https://reviews.llvm.org/D118552
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
The patch was reverted because it caused a crash during PCH build -- we
missed to update the RParenLoc in TreeTransform<Derived>::TransformAutoType.
This relands 55d96ac and 37ec65e with a test and fix.
This allows the body to be parsed.
An special-case that would replace a missing if condition with OpaqueValueExpr
was removed as it's now redundant (unless recovery-expr is disabled).
For loops are not handled at this point, as the parsing is more complicated.
Differential Revision: https://reviews.llvm.org/D113752
Jennifer Yu