[C++20] [Modules] Make the linkage consistent for class template and its
specialization

Previously in D120397, we've handled the linkage for function template
and its specialization. But we forgot t

[C++20] [Modules] Make the linkage consistent for class template and its
specialization

Previously in D120397, we've handled the linkage for function template
and its specialization. But we forgot to handle it for class templates
and their specialization. So we make it in the patch with the similar
approach.

show more ...

[NFC] Start saving InstantiatedFromDecl in non-template functions

In cases where a non-template function is defined inside a function
template, we don't have information about the original uninstant

[NFC] Start saving InstantiatedFromDecl in non-template functions

In cases where a non-template function is defined inside a function
template, we don't have information about the original uninstantiated
version. In the case of concepts instantiation, we will need the
ability to get back to the original template. This patch splits a piece
of the deferred concepts instantaition patch off to accomplish the
storage of this, with minor runtime overhead, and zero additional
storage.

show more ...

Revert "Re-apply "Deferred Concept Instantiation Implementation"""

This reverts commit befa8cf087dbb8159a4d9dc8fa4d6748d6d5049a.

Apparently this breaks some libc++ builds with an apparent assertion

Revert "Re-apply "Deferred Concept Instantiation Implementation"""

This reverts commit befa8cf087dbb8159a4d9dc8fa4d6748d6d5049a.

Apparently this breaks some libc++ builds with an apparent assertion,
so I'm looking into that .

show more ...

Re-apply "Deferred Concept Instantiation Implementation""

This reverts commit d4d47e574ecae562ab32f8ac7fa3f4d424bb6574.

This fixes the lldb crash that was observed by ensuring that our
friend-'temp

Re-apply "Deferred Concept Instantiation Implementation""

This reverts commit d4d47e574ecae562ab32f8ac7fa3f4d424bb6574.

This fixes the lldb crash that was observed by ensuring that our
friend-'template contains reference to' TreeTransform properly handles a
TemplateDecl.

show more ...

Revert "Deferred Concept Instantiation Implementation"

This reverts commit 2f207439521d62d9551b2884158368e8b34084e5 because it
triggers an assertion when building an LLDB test program:

Assertion

Revert "Deferred Concept Instantiation Implementation"

This reverts commit 2f207439521d62d9551b2884158368e8b34084e5 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.

show more ...

Deferred Concept Instantiation Implementation

This is a continuation of D119544. Based on @rsmith 's feed back
showing me https://eel.is/c++draft/temp#friend-9, We should properly
handle friend fun

Deferred Concept Instantiation Implementation

This is a continuation of D119544. Based on @rsmith 's feed back
showing me https://eel.is/c++draft/temp#friend-9, We should properly
handle friend functions now.

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

show more ...

[C++20] [Module] Support reachable definition initially/partially

This patch introduces a new kind of ModuleOwnershipKind as
ReachableWhenImported. This intended the status for reachable described
a

[C++20] [Module] Support reachable definition initially/partially

This patch introduces a new kind of ModuleOwnershipKind as
ReachableWhenImported. This intended the status for reachable described
at: https://eel.is/c++draft/module.reach#3.

Note that this patch is not intended to support all semantics about
reachable semantics. For example, this patch didn't implement discarded
declarations in GMF. (https://eel.is/c++draft/module.global.frag#3).

This fixes: https://bugs.llvm.org/show_bug.cgi?id=52281 and
https://godbolt.org/z/81f3ocjfW.

Reviewed By: rsmith, iains

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

show more ...

Revert "[C++20] [Modules] Implement Reachable initiallly"

This reverts commit a223ba0a697c1598b434cf2495c9cd9ec5640fc7.

The previous commit don't contain additional information, which is bad.

[C++20] [Modules] Implement Reachable initiallly

[Concepts] Implement overload resolution for destructors (P0848)

This patch implements a necessary part of P0848, the overload resolution for destructors.
It is now possible to overload destructors

[Concepts] Implement overload resolution for destructors (P0848)

This patch implements a necessary part of P0848, the overload resolution for destructors.
It is now possible to overload destructors based on constraints, and the eligible destructor
will be selected at the end of the class.

The approach this patch takes is to perform the overload resolution in Sema::ActOnFields
and to mark the selected destructor using a new property in FunctionDeclBitfields.

CXXRecordDecl::getDestructor is then modified to use this property to return the correct
destructor.

This closes https://github.com/llvm/llvm-project/issues/45614.

Reviewed By: #clang-language-wg, erichkeane

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

show more ...

[clang] Allow consteval functions in default arguments

We should not mark a function as "referenced" if we call it within a
ConstantExpr, because the expression will be folded to a value in LLVM
IR.

[clang] Allow consteval functions in default arguments

We should not mark a function as "referenced" if we call it within a
ConstantExpr, because the expression will be folded to a value in LLVM
IR. To prevent emitting consteval function declarations, we should not "jump
over" a ConstantExpr when it is a top-level ParmVarDecl's subexpression.

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

Reviewed By: erichkeane, aaron.ballman, ChuanqiXu

Differenitial Revision: https://reviews.llvm.org/D119646

show more ...

[AST] Cleanup on getting the underlying decl of using-shdow decl.

This should be a NFC cleanup. It removes a unnecessary loop to get the underlying
decl, and add an assertion.

The underlying decl o

[AST] Cleanup on getting the underlying decl of using-shdow decl.

This should be a NFC cleanup. It removes a unnecessary loop to get the underlying
decl, and add an assertion.

The underlying decl of a using-shadow decl is always the original declaration
has been brought into the scope, clang never builds a nested using-shadow
decl (see Sema::BuildUsingShadowDecl).

Reviewed By: sammccall

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

show more ...

Revert ""Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""""

This reverts commit a425cac31e2e4cee8e14b7b9a99c8ba17c1ebb52.

There is another libc++ test, that this time causes us

Revert ""Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""""

This reverts commit a425cac31e2e4cee8e14b7b9a99c8ba17c1ebb52.

There is another libc++ test, that this time causes us to hit an
assertion. Reverting, likely for a while this time.

show more ...

"Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""""

This includes a fix for the libc++ issue I ran across with friend
declarations not properly being identified as overloads.

Th

"Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""""

This includes a fix for the libc++ issue I ran across with friend
declarations not properly being identified as overloads.

This reverts commit 45c07db31cc76802a1a2e41bed1ce9c1b8198181.

show more ...

Revert "Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""

This reverts commit a97899108e495147985e5e9492e742d51d5cc97a.

The patch caused some problems with the libc++ `__range_a

Revert "Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""

This reverts commit a97899108e495147985e5e9492e742d51d5cc97a.

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.

show more ...

Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""

This reverts commit 0c31da48389754822dc3eecc4723160c295b9ab2.

I've solved the issue with the PointerUnion by making the
`Functio

Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""

This reverts commit 0c31da48389754822dc3eecc4723160c295b9ab2.

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.

show more ...

Revert "Deferred Concept Instantiation Implementation"

This reverts commit 4b6c2cd647e9e5a147954886338f97ffb6a1bcfb.

The patch caused numerous ARM 32 bit build failures, since we added a
5th item t

Revert "Deferred Concept Instantiation Implementation"

This reverts commit 4b6c2cd647e9e5a147954886338f97ffb6a1bcfb.

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.

show more ...

Deferred Concept Instantiation Implementation

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

Deferred Concept Instantiation Implementation

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

show more ...

[randstruct] Randomize all elements of a record

A record may have more than just FieldDecls in it. If so, then we're
likely to drop them if we only randomize the FieldDecls.

We need to be careful a

[randstruct] Randomize all elements of a record

A record may have more than just FieldDecls in it. If so, then we're
likely to drop them if we only randomize the FieldDecls.

We need to be careful about anonymous structs/unions. Their fields are
made available in the RecordDecl as IndirectFieldDecls, which are listed
after the anonymous struct/union. The ordering doesn't appear to be
super important, however we place them unrandomized at the end of the
RecordDecl just in case. There's also the possiblity of
StaticAssertDecls. We also want those at the end.

All other non-FieldDecls we place at the top, just in case we get
something like:

struct foo {
enum e { BORK };
enum e a;
};

Link: https://github.com/KSPP/linux/issues/185

Reviewed By: aaron.ballman

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

show more ...

Fix size of flexible array initializers, and re-enable assertions.

In D123649, I got the formula for getFlexibleArrayInitChars slightly
wrong: the flexible array elements can be contained in the tai

Fix size of flexible array initializers, and re-enable assertions.

In D123649, I got the formula for getFlexibleArrayInitChars slightly
wrong: the flexible array elements can be contained in the tail padding
of the struct. Fix the formula to account for that.

With the fixed formula, we run into another issue: in some cases, we
were emitting extra padding for flexible arrray initializers. Fix
CGExprConstant so it uses a packed struct when necessary, to avoid this
extra padding.

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

show more ...

Allow flexible array initialization in C++.

Flexible array initialization is a C/C++ extension implemented in many
compilers to allow initializing the flexible array tail of a struct type
that conta

Allow flexible array initialization in C++.

Flexible array initialization is a C/C++ extension implemented in many
compilers to allow initializing the flexible array tail of a struct type
that contains a flexible array. In clang, this is currently restricted
to C. But this construct is used in the Microsoft SDK headers, so I'd
like to extend it to C++.

For now, this doesn't handle dynamic initialization; probably not hard
to implement, but it's extra code, and I don't think it's necessary for
the expected uses. And we explicitly fail out of constant evaluation.

I've added some additional code to assert that initializers have the
correct size, with or without flexible array init. This might catch
issues unrelated to flexible array init.

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

show more ...

[randstruct] Add randomize structure layout support

The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly

[randstruct] Add randomize structure layout support

The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly, this is mostly useful for closed-source releases of code,
since the randomization seed would need to be available for public and
open source applications.

Why implement it? This patch set enhances Clang’s feature parity with
that of GCC which already has the Randstruct feature. It's used by the
Linux kernel in certain structures to help thwart attacks that depend on
structure layouts in memory.

This patch set is a from-scratch reimplementation of the Randstruct
feature that was originally ported to GCC. The patches for the GCC
implementation can be found here:

https://www.openwall.com/lists/kernel-hardening/2017/04/06/14

Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html
Co-authored-by: Cole Nixon <[email protected]>
Co-authored-by: Connor Kuehl <[email protected]>
Co-authored-by: James Foster <[email protected]>
Co-authored-by: Jeff Takahashi <[email protected]>
Co-authored-by: Jordan Cantrell <[email protected]>
Co-authored-by: Nikk Forbus <[email protected]>
Co-authored-by: Tim Pugh <[email protected]>
Co-authored-by: Bill Wendling <[email protected]>
Signed-off-by: Bill Wendling <[email protected]>

Reviewed By: aaron.ballman

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

show more ...

Revert D121556 "[randstruct] Add randomize structure layout support"

This reverts commit 3f0587d0c668202bb89d29a25432aa290e551a31.

Not all tests pass after a few rounds of fixes.

I spot one failur

Revert D121556 "[randstruct] Add randomize structure layout support"

This reverts commit 3f0587d0c668202bb89d29a25432aa290e551a31.

Not all tests pass after a few rounds of fixes.

I spot one failure that std::shuffle (potentially different results with
different STL implementations) was misused and replaced it with llvm::shuffle,
but there appears to be another failure in a Windows build.

The latest failure is reported on https://reviews.llvm.org/D121556#3440383

show more ...

[randstruct] Add randomize structure layout support

The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly

[randstruct] Add randomize structure layout support

The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly, this is mostly useful for closed-source releases of code,
since the randomization seed would need to be available for public and
open source applications.

Why implement it? This patch set enhances Clang’s feature parity with
that of GCC which already has the Randstruct feature. It's used by the
Linux kernel in certain structures to help thwart attacks that depend on
structure layouts in memory.

This patch set is a from-scratch reimplementation of the Randstruct
feature that was originally ported to GCC. The patches for the GCC
implementation can be found here:

https://www.openwall.com/lists/kernel-hardening/2017/04/06/14

Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html
Co-authored-by: Cole Nixon <[email protected]>
Co-authored-by: Connor Kuehl <[email protected]>
Co-authored-by: James Foster <[email protected]>
Co-authored-by: Jeff Takahashi <[email protected]>
Co-authored-by: Jordan Cantrell <[email protected]>
Co-authored-by: Nikk Forbus <[email protected]>
Co-authored-by: Tim Pugh <[email protected]>
Co-authored-by: Bill Wendling <[email protected]>
Signed-off-by: Bill Wendling <[email protected]>

Reviewed By: aaron.ballman

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

show more ...

[C++20][Modules] Limit ModuleInternalLinkage to modules-ts.

At present, we are generating wrong code for C++20 modules entities which
should have internal linkage. This is because we are assigning

[C++20][Modules] Limit ModuleInternalLinkage to modules-ts.

At present, we are generating wrong code for C++20 modules entities which
should have internal linkage. This is because we are assigning
'ModuleInternalLinkage' unconditionally to such entities. However this mode
is only applicable to the modules-ts.

This change makes the special linkage mode conditional on fmodules-ts and
adds a unit test to verify that we generate the correct linkage.

Currently, static variables and functions in module purview are emitted into
object files as external. On some platforms, lambdas are emitted as global
weak defintions (on Windows this causes a mangler crash).

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

show more ...