[NFC] give getParentFunctionOrMethod a 'Lexical' parameter

Split up from the deferred concepts implementation, this function is
useful for determining the containing function of a different function

[NFC] give getParentFunctionOrMethod a 'Lexical' parameter

Split up from the deferred concepts implementation, this function is
useful for determining the containing function of a different function.
However, in some cases it is valuable to instead get the lexical parent.
This adds a parameter to the existing function to allow a 'Lexical'
parameter to instead select the lexical parent.

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 ...

Also remove the empty StoredDeclsList entry from the lookup table

In case where we have removed all declarations for a given declaration name
entry we should remove the whole StoredDeclsMap entry.

Also remove the empty StoredDeclsList entry from the lookup table

In case where we have removed all declarations for a given declaration name
entry we should remove the whole StoredDeclsMap entry.

This patch improves consistency in the lookup tables and helps cling/clang-repl
error recovery.

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

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 ...

[Clang] Implement __builtin_source_location.

This builtin returns the address of a global instance of the
`std::source_location::__impl` type, which must be defined (with an
appropriate shape) befor

[Clang] Implement __builtin_source_location.

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

show more ...

[Clang] Fix Unevaluated Lambdas

Unlike other types, when lambdas are instanciated,
they are recreated from scratch.
When an unevaluated lambdas appear in the type of a function,
parameter it is inst

[Clang] Fix Unevaluated Lambdas

Unlike other types, when lambdas are instanciated,
they are recreated from scratch.
When an unevaluated lambdas appear in the type of a function,
parameter it is instanciated in the wrong declaration context,
as parameters are transformed before the function.

To support lambda in function parameters, we try to
compute whether they are dependant without looking at the
declaration context.

This is a short term stopgap solution to avoid clang
iceing. A better fix might be to inject some kind of
transparent declaration with correctly computed dependency
for function parameters, variable templates, etc.

Fixes https://github.com/llvm/llvm-project/issues/50376
Fixes https://github.com/llvm/llvm-project/issues/51414
Fixes https://github.com/llvm/llvm-project/issues/51416
Fixes https://github.com/llvm/llvm-project/issues/51641
Fixes https://github.com/llvm/llvm-project/issues/54296

Reviewed By: aaron.ballman

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

show more ...

[C++20] [Module] fix bug 47716 and implement [module.interface]/p6

This fixes bug 47716.

According to [module.interface]p2, it is meaningless to export an entity
which is not in namespace scope.
Th

[C++20] [Module] fix bug 47716 and implement [module.interface]/p6

This fixes bug 47716.

According to [module.interface]p2, it is meaningless to export an entity
which is not in namespace scope.
The reason why the compiler crashes is that the compiler missed
ExportDecl when the compiler traverse the subclass of DeclContext. So
here is the crash.

Also, the patch implements [module.interface]p6 in
Sema::CheckRedeclaration* functions.

Reviewed By: aaron.ballman, urnathan

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

show more ...

[AST] lookup in parent DeclContext for transparent DeclContext

The compiler would crash if we lookup for name in transparent decl
context. See the tests attached for example.

I think this should ma

[AST] lookup in parent DeclContext for transparent DeclContext

The compiler would crash if we lookup for name in transparent decl
context. See the tests attached for example.

I think this should make sense since the member declared in transparent
DeclContext are semantically defined in the enclosing (non-transparent)
DeclContext, this is the definition for transparent DeclContext.

Reviewed By: erichkeane

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

show more ...

[AST] Don't consider 'ExportDecl' when calculating DeclContext 'Encloses'

This mimics the style of 90010c2e1 (Don't consider 'LinkageSpec' when
calculating DeclContext 'Encloses'). Since ExportDecl

[AST] Don't consider 'ExportDecl' when calculating DeclContext 'Encloses'

This mimics the style of 90010c2e1 (Don't consider 'LinkageSpec' when
calculating DeclContext 'Encloses'). Since ExportDecl and LinkageSpec
are transparent DeclContext, they share some similarity.

Reviewed By: erichkeane

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

show more ...

Don't consider 'LinkageSpec' when calculating DeclContext 'Encloses'

We don't properly handle lookup through using directives when there is
a linkage spec in the common chain. This is because `CppL

Don't consider 'LinkageSpec' when calculating DeclContext 'Encloses'

We don't properly handle lookup through using directives when there is
a linkage spec in the common chain. This is because `CppLookupName` and
`CppNamespaceLookup` end up skipping `LinkageSpec`'s (correctly, as they
are not lookup scopes), but the `UnqualUsingDirectiveSet` does not.

I discovered that when we are calculating the `CommonAncestor` for a
using-directive, we were coming up with the `LinkageSpec`, instead of
the `LinkageSpec`'s parent. Then, when we use
`UnqualUsingDirectiveSet::getNamespacesFor` a scope, we don't end up
finding any that were in the `LinkageSpec` (again, since `CppLookupName`
skips linkage specs), so those don't end up participating in the lookup.

The function `UnqualUsingDirectiveSet::addUsingDirective` calculates
this common ancestor via a loop through the the `DeclSpec::Encloses`
function.

Changing this Encloses function to believe that a `LinkageSpec`
`Encloses` nothing ends up fixing the problem without breaking any other tests,
so I opted to do that. A less aggressive patch could perhaps change only
the `addUsingDirective`, but my examination of all uses of `Encloses`
showed that it seems to be used exclusively in lookup, which makes me think
this is correct everywhere.

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

show more ...

[clang][NFC] Inclusive terms: rename AccessDeclContextSanity to AccessDeclContextCheck

Rename function to more inclusive name.

Reviewed By: quinnp

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

[clang][NFC] Inclusive terms: rename AccessDeclContextSanity to AccessDeclContextCheck

Rename function to more inclusive name.

Reviewed By: quinnp

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

show more ...

[clang] Support -clear-ast-before-backend without -disable-free

Previously without -disable-free, -clear-ast-before-backend would crash in ~ASTContext() due to various reasons.
This works around tha

[clang] Support -clear-ast-before-backend without -disable-free

Previously without -disable-free, -clear-ast-before-backend would crash in ~ASTContext() due to various reasons.
This works around that by doing a lot of the cleanup ahead of the destructor so that the destructor doesn't actually do any manual cleanup if we've already cleaned up beforehand.

This actually does save a measurable amount of memory with -clear-ast-before-backend, although at an almost unnoticeable runtime cost:
https://llvm-compile-time-tracker.com/compare.php?from=5d755b32f2775b9219f6d6e2feda5e1417dc993b&to=58ef1c7ad7e2ad45f9c97597905a8cf05a26258c&stat=max-rss

Previously we weren't doing any cleanup with -disable-free, so I tried measuring the impact of always doing the cleanup and didn't measure anything noticeable on llvm-compile-time-tracker.

Reviewed By: dblaikie

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

show more ...

Replace an unnecessary null check with an assert; NFC

Fix assertion when generating diagnostic for inline namespaces

When calculating the name to display for inline namespaces, we have
custom logic to try to hide redundant inline namespaces from the
di

Fix assertion when generating diagnostic for inline namespaces

When calculating the name to display for inline namespaces, we have
custom logic to try to hide redundant inline namespaces from the
diagnostic. Calculating these redundancies requires performing a lookup
in the parent declaration context, but that lookup should not try to
look through transparent declaration contexts, like linkage
specifications. Instead, loop up the declaration context chain until we
find a non-transparent context and use that instead.

This fixes PR49954.

show more ...

Reland "[clang-repl] Implement partial translation units and error recovery."

Original commit message:

[clang-repl] Implement partial translation units and error recovery.

https://reviews.llvm.org

Reland "[clang-repl] Implement partial translation units and error recovery."

Original commit message:

[clang-repl] Implement partial translation units and error recovery.

https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:

Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.

The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.

The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.

Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.

It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.

We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.

We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.

This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:

```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```

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

show more ...

Revert "[clang-repl] Implement partial translation units and error recovery."

This reverts commit 6775fc6ffa3ca1c36b20c25fa4e7f48f81213cf2.

It also reverts "[lldb] Fix compilation by adjusting to t

Revert "[clang-repl] Implement partial translation units and error recovery."

This reverts commit 6775fc6ffa3ca1c36b20c25fa4e7f48f81213cf2.

It also reverts "[lldb] Fix compilation by adjusting to the new ASTContext signature."

This reverts commit 03a3f86071c10a1f6cbbf7375aa6fe9d94168972.

We see some failures on the lldb infrastructure, these changes might play a role
in it. Let's revert it now and see if the bots will become green.

Ref: https://reviews.llvm.org/D104918

show more ...

[clang-repl] Implement partial translation units and error recovery.

https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the

[clang-repl] Implement partial translation units and error recovery.

https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:

Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.

The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.

The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.

Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.

It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.

We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.

We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.

This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:

```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```

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

show more ...