[Clang] Preserve partially substituted pack indexing type/expressions (#116782)

Substituting into pack indexing types/expressions can still result in
unexpanded types/expressions, such as `PackInde

[Clang] Preserve partially substituted pack indexing type/expressions (#116782)

Substituting into pack indexing types/expressions can still result in
unexpanded types/expressions, such as `PackIndexingType` or
`PackIndexingExpr`. To handle these cases correctly, we should defer the
pack size checks to the next round of transformation, when the patterns
can be fully expanded.

To that end, the `FullySubstituted` flag is now necessary for computing
the dependencies of `PackIndexingExprs`. Conveniently, this flag can
also represent the prior `ExpandsToEmpty` status with an additional
emptiness check. Therefore, I converted all stored flags to use
`FullySubstituted`.

Fixes https://github.com/llvm/llvm-project/issues/116105

show more ...

[Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (#110762)

Consider #109148:
```c++
template <typename ...Ts>
void f() {
[] {
(^Ts);
};
}
```

When we

[Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (#110762)

Consider #109148:
```c++
template <typename ...Ts>
void f() {
[] {
(^Ts);
};
}
```

When we encounter `^Ts`, we try to parse a block and subsequently call
`DiagnoseUnexpandedParameterPack()` (in `ActOnBlockArguments()`), which
sees `Ts` and sets `ContainsUnexpandedParameterPack` to `true` in the
`LambdaScopeInfo` of the enclosing lambda. However, the entire block is
subsequently discarded entirely because it isn’t even syntactically
well-formed. As a result, `ContainsUnexpandedParameterPack` is `true`
despite the lambda’s body no longer containing any unexpanded packs,
which causes an assertion the next time
`DiagnoseUnexpandedParameterPack()` is called.

This pr moves handling of unexpanded parameter packs into
`CapturingScopeInfo` instead so that the same logic is used for both
blocks and lambdas. This fixes this issue since the
`ContainsUnexpandedParameterPack` flag is now part of the block (and
before that, its `CapturingScopeInfo`) and no longer affects the
surrounding lambda directly when the block is parsed. Moreover, this
change makes blocks actually usable with pack expansion.

This fixes #109148.

show more ...

[OpenACC] Implement 'tile' attribute AST (#110999)

The 'tile' clause shares quite a bit of the rules with 'collapse', so a
followup patch will add those tests/behaviors. This patch deals with
addi

[OpenACC] Implement 'tile' attribute AST (#110999)

The 'tile' clause shares quite a bit of the rules with 'collapse', so a
followup patch will add those tests/behaviors. This patch deals with
adding the AST node.

The 'tile' clause takes a series of integer constant expressions, or *.
The asterisk is now represented by a new OpenACCAsteriskSizeExpr node,
else this clause is very similar to others.

show more ...

[NFC] Comment fix: "does specify state that" -> "does specify that" (#106338)

[Clang] Fix dependency computation for pack indexing expression (#91933)

Given `foo...[idx]` if idx is value dependent, the expression is type
dependent.

Fixes #91885
Fixes #91884

[NFC] Generalize ArraySections to work for OpenACC in the future (#89639)

OpenACC is going to need an array sections implementation that is a
simpler version/more restrictive version of the OpenMP

[NFC] Generalize ArraySections to work for OpenACC in the future (#89639)

OpenACC is going to need an array sections implementation that is a
simpler version/more restrictive version of the OpenMP version.

This patch moves `OMPArraySectionExpr` to `Expr.h` and renames it `ArraySectionExpr`,
then adds an enum to choose between the two.

This also fixes a couple of 'drive-by' issues that I discovered on the way,
but leaves the OpenACC Sema parts reasonably unimplemented (no semantic
analysis implementation), as that will be a followup patch.

show more ...

[Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter (#84473)

This fixes some problems wrt dependence of captures in lambdas with
an explicit object parameter.

[tem

[Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter (#84473)

This fixes some problems wrt dependence of captures in lambdas with
an explicit object parameter.

[temp.dep.expr] states that
> An id-expression is type-dependent if [...] its terminal name is
> - associated by name lookup with an entity captured by copy
> ([expr.prim.lambda.capture]) in a lambda-expression that has
> an explicit object parameter whose type is dependent [dcl.fct].

There were several issues with our implementation of this:
1. we were treating by-reference captures as dependent rather than
by-value captures;
2. tree transform wasn't checking whether referring to such a
by-value capture should make a DRE dependent;
3. when checking whether a DRE refers to such a by-value capture, we
were only looking at the immediately enclosing lambda, and not
at any parent lambdas;
4. we also forgot to check for implicit by-value captures;
5. lastly, we were attempting to determine whether a lambda has an
explicit object parameter by checking the `LambdaScopeInfo`'s
`ExplicitObjectParameter`, but it seems that that simply wasn't
set (yet) by the time we got to the check.

All of these should be fixed now.

This fixes #70604, #79754, #84163, #84425, #86054, #86398, and #86399.

show more ...

[Clang][AST][NFC] Move template argument dependence computations for MemberExpr to computeDependence (#86682)

(This patch depends on #86678)

Pretty straightforward change, addresses the FIXME's i

[Clang][AST][NFC] Move template argument dependence computations for MemberExpr to computeDependence (#86682)

(This patch depends on #86678)

Pretty straightforward change, addresses the FIXME's in
`computeDependence(MemberExpr*)` and `MemberExpr::Create` by moving the
template argument dependence computations to `computeDependence`.

show more ...

[Clang][C++26] Implement Pack Indexing (P2662R3). (#72644)

Implements https://isocpp.org/files/papers/P2662R3.pdf

The feature is exposed as an extension in older language modes.
Mangling is not

[Clang][C++26] Implement Pack Indexing (P2662R3). (#72644)

Implements https://isocpp.org/files/papers/P2662R3.pdf

The feature is exposed as an extension in older language modes.
Mangling is not yet supported and that is something we will have to do before release.

show more ...

[clang] Accept recursive non-dependent calls to functions with deduced return type (#75456)

Treat such calls as dependent since it is much easier to implement.

Fixes https://github.com/llvm/llvm-

[clang] Accept recursive non-dependent calls to functions with deduced return type (#75456)

Treat such calls as dependent since it is much easier to implement.

Fixes https://github.com/llvm/llvm-project/issues/71015

show more ...

[C++] Implement "Deducing this" (P0847R7)

This patch implements P0847R7 (partially),
CWG2561 and CWG2653.

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm

[C++] Implement "Deducing this" (P0847R7)

This patch implements P0847R7 (partially),
CWG2561 and CWG2653.

Reviewed By: aaron.ballman, #clang-language-wg

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

show more ...

[clang][AST] Propagate the contains-errors bit to DeclRefExpr from VarDecl's initializer.

Similar to the https://reviews.llvm.org/D86048 (it only sets the bit for C++
code), we propagate the contain

[clang][AST] Propagate the contains-errors bit to DeclRefExpr from VarDecl's initializer.

Similar to the https://reviews.llvm.org/D86048 (it only sets the bit for C++
code), we propagate the contains-errors bit for C-code path.

Fixes https://github.com/llvm/llvm-project/issues/50236
Fixes https://github.com/llvm/llvm-project/issues/50243
Fixes https://github.com/llvm/llvm-project/issues/48636
Fixes https://github.com/llvm/llvm-project/issues/50320

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

show more ...

[clang] Correct calculation of MemberExpr's dependence

Due to incorrect calculation false positive diagnostics were emitted.

Fixes https://github.com/llvm/llvm-project/issues/48731

Reviewed By: sh

[clang] Correct calculation of MemberExpr's dependence

Due to incorrect calculation false positive diagnostics were emitted.

Fixes https://github.com/llvm/llvm-project/issues/48731

Reviewed By: shafik, cor3ntin

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

show more ...

[C] Support _Generic expressions with a type operand

_Generic accepts an expression operand whose type is matched against a
list of associations. The expression operand is unevaluated, but the
type

[C] Support _Generic expressions with a type operand

_Generic accepts an expression operand whose type is matched against a
list of associations. The expression operand is unevaluated, but the
type matched is the type after lvalue conversion. This conversion loses
type information, which makes it more difficult to match against
qualified or incomplete types.

This extension allows _Generic to accept a type operand instead of an
expression operand. The type operand form does not undergo any
conversions and is matched directly against the association list.

This extension is also supported in C++ as we already supported
_Generic selection expressions there.

The RFC for this extension can be found at:
https://discourse.llvm.org/t/rfc-generic-selection-expression-with-a-type-operand/70388

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

show more ...

[clang][AST] Propagate the value-dependent bit for VAArgExpr.

Fixes https://github.com/llvm/llvm-project/issues/62711

We never set the value-dependent bit for the VAArgExpr before this
patch, this

[clang][AST] Propagate the value-dependent bit for VAArgExpr.

Fixes https://github.com/llvm/llvm-project/issues/62711

We never set the value-dependent bit for the VAArgExpr before this
patch, this was fine becase the dependent-type TypoExpr was always
resolved before checking the operands (see https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaExpr.cpp#L21173-L21180)

Now we have enabled the dependence by default for C, the typo expr is
not early resolved before checking rather than delayed (share the same
codepath with C++).

The fix is to propagate the value-dependent bit for VAArgExpr where it contains
a TypoExpr, so that the AST node can be handled properly.

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

show more ...

[NFC][clang] Fix Coverity bugs with AUTO_CAUSES_COPY

Reported by Coverity:
AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.

1. Inside "ExtractAPIVisitor.h" file, in clang::extract

[NFC][clang] Fix Coverity bugs with AUTO_CAUSES_COPY

Reported by Coverity:
AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.

1. Inside "ExtractAPIVisitor.h" file, in clang::extractapi::impl::ExtractAPIVisitorBase<<unnamed>::BatchExtractAPIVisitor>::VisitFunctionDecl(clang::FunctionDecl const *): Using the auto keyword without an & causes the copy of an object of type DynTypedNode.

2. Inside "NeonEmitter.cpp" file, in <unnamed>::Intrinsic::Intrinsic(llvm::Record *, llvm::StringRef, llvm::StringRef, <unnamed>::TypeSpec, <unnamed>::TypeSpec, <unnamed>::ClassKind, llvm::ListInit *, <unnamed>::NeonEmitter &, llvm::StringRef, llvm::StringRef, bool, bool): Using the auto keyword without an & causes the copy of an object of type Type.

3. Inside "MicrosoftCXXABI.cpp" file, in <unnamed>::MSRTTIBuilder::getClassHierarchyDescriptor(): Using the auto keyword without an & causes the copy of an object of type MSRTTIClass.

4. Inside "CGGPUBuiltin.cpp" file, in clang::CodeGen::CodeGenFunction::EmitAMDGPUDevicePrintfCallExpr(clang::CallExpr const *): Using the auto keyword without an & causes the copy of an object of type CallArg.

5. Inside "SemaDeclAttr.cpp" file, in threadSafetyCheckIsSmartPointer(clang::Sema &, clang::RecordType const *): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.

6. Inside "ComputeDependence.cpp" file, in clang::computeDependence(clang::DesignatedInitExpr *): Using the auto keyword without an & causes the copy of an object of type Designator.

7. Inside "Format.cpp" file, In clang::format::affectsRange(llvm::ArrayRef<clang::tooling::Range>, unsigned int, unsigned int): Using the auto keyword without an & causes the copy of an object of type Range.

Reviewed By: tahonermann

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

show more ...

[NFC][clang] Fix static analyzer concerns

Reported by Coverity:

AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.

1. Inside "SemaDeclCXX.cpp" file, in <unnamed>::DiagnoseUninitial

[NFC][clang] Fix static analyzer concerns

Reported by Coverity:

AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.

1. Inside "SemaDeclCXX.cpp" file, in <unnamed>::DiagnoseUninitializedFields(clang::Sema &, clang::CXXConstructorDecl const *): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.

2. Inside "ClangAttrEmitter.cpp" file, in clang::EmitClangAttrParsedAttrImpl(llvm::RecordKeeper &, llvm::raw_ostream &): Using the auto keyword without an & causes the copy of an object of type pair.

3. Inside "Marshallers.h" file, in clang::ast_matchers::dynamic::internal::MapAnyOfBuilderDescriptor::buildMatcherCtor(clang::ast_matchers::dynamic::SourceRange, llvm::ArrayRef<clang::ast_matchers::dynamic::ParserValue>, clang::ast_matchers::dynamic::Diagnostics *): Using the auto keyword without an & causes the copy of an object of type ParserValue.

4. Inside "CGVTables.cpp" file, in clang::CodeGen::CodeGenModule::GetVCallVisibilityLevel(clang::CXXRecordDecl const *, llvm::DenseSet<clang::CXXRecordDecl const *, llvm::DenseMapInfo<clang::CXXRecordDecl const *, void>> &): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.

5. Inside "ASTContext.cpp" file, in hasTemplateSpecializationInEncodedString(clang::Type const *, bool): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.

6. Inside "ComputeDependence.cpp" file, in clang::computeDependence(clang::DependentScopeDeclRefExpr *): Using the auto keyword without an & causes the copy of an object of type TemplateArgumentLoc.

Reviewed By: tahonermann, erichkeane

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

show more ...

[NFC][clang] Fix Coverity static analyzer tool concerns about auto_causes_copy

Reported by Coverity:

AUTO_CAUSES_COPY
Unnecessary object copies can affect performance

Inside Fronte

[NFC][clang] Fix Coverity static analyzer tool concerns about auto_causes_copy

Reported by Coverity:

AUTO_CAUSES_COPY
Unnecessary object copies can affect performance

Inside FrontendActions.cpp file,
In clang::DumpModuleInfoAction::ExecuteAction(): Using the auto keyword without an & causes the copy of an object of type pair.

Inside ComputeDependence.cpp file,
In clang::computeDependence(clang::OverloadExpr *, bool, bool, bool): Using the auto keyword without an & causes the copy of an object of type TemplateArgumentLoc.

Reviewed By: erichkeane, aaron.ballman

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

show more ...

[clang] Reland parenthesized aggregate init patches

This commit relands the patches for implementing P0960R3 and P1975R0,
which describe initializing aggregates via a parenthesized list.

The reland

[clang] Reland parenthesized aggregate init patches

This commit relands the patches for implementing P0960R3 and P1975R0,
which describe initializing aggregates via a parenthesized list.

The relanded commits are:

* 40c52159d3ee - P0960R3 and P1975R0: Allow initializing aggregates from
a parenthesized list of values
* c77a91bb7ba7 - Remove overly restrictive aggregate paren init logic
* 32d7aae04fdb - Fix a clang crash on invalid code in C++20 mode

This patch also fixes a crash in the original implementation.
Previously, if the input tried to call an implicitly deleted copy or
move constructor of a union, we would then try to initialize the union
by initializing it's first element with a reference to a union. This
behavior is incorrect (we should fail to initialize) and if the type of
the first element has a constructor with a single template typename
parameter, then Clang will explode. This patch fixes that issue by
checking that constructor overload resolution did not result in a
deleted function before attempting parenthesized aggregate
initialization.

Additionally, this patch also includes D140159, which contains some
minor fixes made in response to code review comments in the original
implementation that were made after that patch was submitted.

Co-authored-by: Sheng <ox59616e@gmail.com>

Fixes #54040, Fixes #59675

Reviewed By: ilya-biryukov

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

show more ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - clang/ part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential

Move from llvm::makeArrayRef to ArrayRef deduction guides - clang/ part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

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

show more ...

[clang] Revert parentesized aggregate initalization patches

This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/5

[clang] Revert parentesized aggregate initalization patches

This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/59675

Revert "[clang] Fix a clang crash on invalid code in C++20 mode."

This reverts commit 32d7aae04fdb58e65a952f281ff2f2c3f396d98f.

Revert "[clang] Remove overly restrictive aggregate paren init logic"

This reverts commit c77a91bb7ba793ec3a6a5da3743ed55056291658.

Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values"

This reverts commit 40c52159d3ee337dbed14e4c73b5616ea354c337.

show more ...

[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

This patch implements P0960R3, which allows initialization of aggregates
via parentheses.

As an

[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

This patch implements P0960R3, which allows initialization of aggregates
via parentheses.

As an example:

```
struct S { int i, j; };
S s1(1, 1);

int arr1[2](1, 2);
```

This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:

```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;

int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```

This patch was originally authored by @0x59616e and completed by
@ayzhao.

Fixes #54040, Fixes #54041

Co-authored-by: Sheng <ox59616e@gmail.com>

Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744

Reviewed By: ilya-biryukov

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

show more ...

[clang] Improve error recovery for pack expansion of expressions

Closes #58673.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

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

Reapply "[Concepts] Recover properly from a RecoveryExpr in a concept"

This reverts commit 192d69f7e65a625e344421841e731e39f80595f5.

This fixes the condition to check whether this is a situation wh

Reapply "[Concepts] Recover properly from a RecoveryExpr in a concept"

This reverts commit 192d69f7e65a625e344421841e731e39f80595f5.

This fixes the condition to check whether this is a situation where we
are in a recovery-expr'ed concept a little better, so we don't access an
inactive member of a union, which should make the bots happy.

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

show more ...

Revert "[Concepts] Recover properly from a RecoveryExpr in a concept"

This reverts commit e3d14bee238b672a7a112311eefee55e142eaefc.

There are apparently a large number of crashes in libcxx and some

Revert "[Concepts] Recover properly from a RecoveryExpr in a concept"

This reverts commit e3d14bee238b672a7a112311eefee55e142eaefc.

There are apparently a large number of crashes in libcxx and some JSON
Parser thing, so clearly this has some sort of serious issue. Reverting
so I can take some time to figure out what is going on.

show more ...