Commit Graph

1066 Commits

Author SHA1 Message Date
Rageking8 94738a5ac3 Fix duplicate word typos; NFC
This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.
2022-11-08 07:21:23 -05:00
Yuanfang Chen 5d086cce8b [Clang] perform "maximum TLS alignment" check for template instantiation
follow up d30e2eefc3

Reviewed By: mizvekov

Differential Revision: https://reviews.llvm.org/D136744
2022-10-30 22:39:47 -07:00
Liming Liu ae48d1c76a [P0857R0 Part-B] Allows `require' clauses appearing in
template-template parameters. Although it effects whether a template can be
used as an argument for another template, the constraint seems not to
be checked, nor other major implementations (GCC, MSVC, et al.) check it.

Additionally, Part-A of the document seems to have been implemented.
So mark P0857R0 as completed.

Differential Revision: https://reviews.llvm.org/D134128
2022-10-27 06:41:43 -07:00
Matheus Izvekov 326feaafb0
[clang] Implement sugared substitution changes to infrastructure
Implements the changes required to perform substitution with
non-canonical template arguments, and to 'finalize' them
by not placing 'Subst' nodes.

A finalized substitution means we won't resugar them later,
because these templates themselves were eagerly substituted
with the intended arguments at the point of use. We may still
resugar other templates used within those, though.

This patch does not actually implement any uses of this
functionality, those will be added in subsequent patches,
so expect no changes to existing tests.

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

Differential Revision: https://reviews.llvm.org/D134604
2022-10-27 06:18:07 +02:00
Matheus Izvekov 13fd717b22
[clang] Changes to produce sugared converted template arguments
Makes CheckTemplateArgumentList and the template deduction functions
produce a sugared converted argument list in addition to the canonical one.

This is mostly NFC except that we hook this up to a few diagnostics in
SemaOverload.

The infrastructure here will be used in subsequent patches
where we perform a finalized sugared substitution for entities
which we do not unique per specializations on canonical arguments,
and later on will be used for template specialization resugaring.

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

Differential Revision: https://reviews.llvm.org/D133874
2022-10-27 05:50:00 +02:00
Matheus Izvekov b1f1ce782c
Revert "[clang] Changes to produce sugared converted template arguments"
This reverts commit 11ce78940b.
2022-10-26 10:14:40 +02:00
Matheus Izvekov 8383c2a435
Revert "[clang] Implement sugared substitution changes to infrastructure"
This reverts commit c4c2a3c656.
2022-10-26 10:14:31 +02:00
Matheus Izvekov c4c2a3c656
[clang] Implement sugared substitution changes to infrastructure
Implements the changes required to perform substitution with
non-canonical template arguments, and to 'finalize' them
by not placing 'Subst' nodes.

A finalized substitution means we won't resugar them later,
because these templates themselves were eagerly substituted
with the intended arguments at the point of use. We may still
resugar other templates used within those, though.

This patch does not actually implement any uses of this
functionality, those will be added in subsequent patches,
so expect no changes to existing tests.

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

Differential Revision: https://reviews.llvm.org/D134604
2022-10-26 03:21:15 +02:00
Matheus Izvekov 11ce78940b
[clang] Changes to produce sugared converted template arguments
Makes CheckTemplateArgumentList and the template deduction functions
produce a sugared converted argument list in addition to the canonical one.

This is mostly NFC except that we hook this up to a few diagnostics in
SemaOverload.

The infrastructure here will be used in subsequent patches
where we perform a finalized sugared substitution for entities
which we do not unique per specializations on canonical arguments,
and later on will be used for template specialization resugaring.

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

Differential Revision: https://reviews.llvm.org/D133874
2022-10-26 02:15:10 +02:00
Erich Keane 975740bf8d "Reapply "GH58368: Correct concept checking in a lambda defined in concept""
This reverts commit cecc9a92cf.

The problem ended up being how we were handling the lambda-context in
code generation: we were assuming any decl context here would be a
named-decl, but that isn't the case.  Instead, we just replace it with
the concept's owning context.

Differential Revision: https://reviews.llvm.org/D136451
2022-10-24 12:36:54 -07:00
Erich Keane cecc9a92cf Revert "Reapply "GH58368: Correct concept checking in a lambda defined in concept"""
This reverts commit b876f6e2f2.

Still getting build failures on PPC AIX that aren't obvious what is causing
them, so reverting while I try to figure this out.
2022-10-24 12:20:23 -07:00
Erich Keane b876f6e2f2 Reapply "GH58368: Correct concept checking in a lambda defined in concept""
This reverts commit 5293016287.

Now with updating the ASTBitcodes to show that this AST is incompatible
from the last.
2022-10-24 11:46:54 -07:00
Erich Keane 5293016287 Revert "GH58368: Correct concept checking in a lambda defined in concept"
This reverts commit b7c922607c.

This seems to cause some problems with some modules related things,
which makes me think I should have updated the version-major in
ast-bit-codes?  Going to revert to confirm this was a problem, then
change that and re-try a commit.
2022-10-24 10:21:22 -07:00
Erich Keane b7c922607c GH58368: Correct concept checking in a lambda defined in concept
As that bug reports, the problem here is that the lambda's
'context-decl' was not set to the concept, and the lambda picked up
template arguments from the concept.  SO, we failed to get the correct
template arguments in SemaTemplateInstantiate.

However, a Concept Specialization is NOT a decl, its an expression, so
we weren't able to put the concept in the decl tree like we needed.
This patch introduces a ConceptSpecializationDecl, which is the smallest
type possible to use for this purpose, containing only the template
arguments.

The net memory impliciation of this is turning a
trailing-objects into a pointer to a type with trailing-objects,  so it
should be minor.

As future work, we may consider giving this type more responsibility, or
figuring out how to better merge duplicates, but as this is just a
template-argument collection at the moment, there isn't much value to
it.

Differential Revision: https://reviews.llvm.org/D136451
2022-10-24 06:32:18 -07:00
Matheus Izvekov bcd9ba2b7e
[clang] Track the templated entity in type substitution.
This is a change to how we represent type subsitution in the AST.
Instead of only storing the replaced type, we track the templated
entity we are substituting, plus an index.
We modify MLTAL to track the templated entity at each level.

Otherwise, it's much more expensive to go from the template parameter back
to the templated entity, and not possible to do in some cases, as when
we instantiate outer templates, parameters might still reference the
original entity.

This also allows us to very cheaply lookup the templated entity we saw in
the naming context and find the corresponding argument it was replaced
from, such as for implementing template specialization resugaring.

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

Differential Revision: https://reviews.llvm.org/D131858
2022-10-15 22:08:36 +02:00
Sam McCall 2eaf6f973c [AST] Preserve more structure in UsingEnumDecl node.
- store NestedNameSpecifier & Loc for the qualifiers
  This information was entirely missing from the AST.
- expose the location information for qualifier/identifier/typedefs as typeloc
  This allows many traversals/astmatchers etc to handle these generically along
  with other references. The decl vs type split can help preserve typedef
  sugar when https://github.com/llvm/llvm-project/issues/57659 is resolved.
- fix the SourceRange of UsingEnumDecl to include 'using'.

Fixes https://github.com/clangd/clangd/issues/1283

Differential Revision: https://reviews.llvm.org/D134303
2022-10-12 19:54:51 +02:00
Troy Johnson b62f5fb64e [Clang][Sema] Narrow inline namespace filtration for unqualified friend declarations
rG04ba1856 introduced a call to FilterLookupForScope that is expensive
for very large translation units where it was observed to cause a 6%
compile time degradation. As the comment states, the only effect is to
"remove declarations found in inline namespaces for friend declarations
with unqualified names." This change limits the call to that scenario.
The test that was added by rG04ba1856 continues to pass, but the
observed degradation is cut in half.

Differential Revision: https://reviews.llvm.org/D135370
2022-10-10 08:34:14 -07:00
Tom Honermann 4409a83c29 [clang] Correct handling of lambdas in lambda default arguments in dependent contexts.
Previously, a lambda expression in a dependent context with a default argument
containing an immediately invoked lambda expression would produce a closure
class object that, if invoked such that the default argument was used, resulted
in a compiler crash or one of the following assertion failures during code
generation. The failures occurred regardless of whether the lambda expressions
were dependent.

  clang/lib/CodeGen/CGCall.cpp:
  Assertion `(isGenericMethod || Ty->isVariablyModifiedType() || Ty.getNonReferenceType()->isObjCRetainableType() || getContext() .getCanonicalType(Ty.getNonReferenceType()) .getTypePtr() == getContext().getCanonicalType((*Arg)->getType()).getTypePtr()) && "type mismatch in call argument!"' failed.

  clang/lib/AST/Decl.cpp:
  Assertion `!Init->isValueDependent()' failed.

Default arguments in declarations in local context are instantiated along with
their enclosing function or variable template (since such declarations can't
be explicitly specialized). Previously, such instantiations were performed at
the same time that their associated parameters were instantiated. However, that
approach fails in cases like the following in which the context for the inner
lambda is the outer lambda, but construction of the outer lambda is dependent
on the parameters of the inner lambda. This change resolves this dependency by
delyaing instantiation of default arguments in local contexts until after
construction of the enclosing context.
  template <typename T>
  auto f() {
    return [](T = []{ return T{}; }()) { return 0; };
  }

Refactoring included with this change results in the same code now being used
to instantiate default arguments that appear in local context and those that
are only instantiated when used at a call site; previously, such code was
duplicated and out of sync.

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

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D133500
2022-10-04 09:04:54 -07:00
Erich Keane babdef27c5 Re-apply "Deferred Concept Instantiation Implementation"
This reverts commit 95d94a6775.

This implements the deferred concepts instantiation, which should allow
the libstdc++ ranges to properly compile, and for the CRTP to work for
constrained functions.

Since the last attempt, this has fixed the issues from @wlei and
@mordante.

Differential Revision: https://reviews.llvm.org/D126907
2022-09-22 05:53:59 -07:00
Xiang Li 782ac2182c [HLSL] Support cbuffer/tbuffer for hlsl.
This is first part for support cbuffer/tbuffer.

The format for cbuffer/tbuffer is
BufferType [Name] [: register(b#)] { VariableDeclaration [: packoffset(c#.xyzw)]; ... };

More details at https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-constants

New keyword 'cbuffer' and 'tbuffer' are added.
New AST node HLSLBufferDecl is added.
Build AST for simple cbuffer/tbuffer without attribute support.

The special thing is variables declared inside cbuffer is exposed into global scope.
So isTransparentContext should return true for HLSLBuffer.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D129883
2022-09-21 10:07:43 -07:00
Kazu Hirata b7a7aeee90 [clang] Qualify auto in range-based for loops (NFC) 2022-09-03 23:27:27 -07:00
Roy Jacobson b1c960fc6d [Clang] Implement P0848 (Conditionally Trivial Special Member Functions)
This patch implements P0848 in Clang.

During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.

Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.

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

Differential Revision: https://reviews.llvm.org/D128619
2022-08-26 00:52:52 +03:00
Roy Jacobson 70770a16bc Revert "[Clang] Implement P0848 (Conditionally Trivial Special Member Functions)"
See bug report here: https://github.com/llvm/llvm-project/issues/57351
This reverts commit 7171615099.
2022-08-25 09:11:06 +03:00
Roy Jacobson 7171615099 [Clang] Implement P0848 (Conditionally Trivial Special Member Functions)
This patch implements P0848 in Clang.

During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.

Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.

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

Differential Revision: https://reviews.llvm.org/D128619
2022-08-23 21:48:42 +03:00
Mike Rice 129904d504 [OpenMP][NFC] Use OMPInteropInfo in the OMPDeclareVariantAttr attribute
In preparation for allowing the prefer_type list in the append_args clause,
use the OMPInteropInfo in the attribute for 'declare variant'.

This requires adding a new Argument kind to the attribute code. This change
adds a specific attribute to pass an array of OMPInteropInfo. It implements
new tablegen needed to handle the interop-type part of the structure. When
prefer_type is added, more work will be needed to dump, instantiate, and
serialize the PreferTypes field in OMPInteropInfo.

Differential Revision: https://reviews.llvm.org/D132270
2022-08-22 10:41:16 -07:00
Erich Keane 95d94a6775 Revert "Re-apply "Deferred Concept Instantiation Implementation"""
This reverts commit d483730d8c.

This allegedly breaks a significant part of facebooks internal build.
Reverting while we wait for them to provide a reproducer of this from
@wlei.
2022-08-19 12:47:34 -07:00
Erich Keane d483730d8c Re-apply "Deferred Concept Instantiation Implementation""
This reverts commit 258c3aee54.

This should fix the libc++ issue that caused the revert, by re-designing
slightly how we determined when we should evaluate the constraints.
Additionally, many of the other components to the original patch (the
NFC parts) were committed separately to shrink the size of this patch
for review.

Differential Revision: https://reviews.llvm.org/D126907
2022-08-17 06:24:40 -07:00
Chuanqi Xu 0bc993edf4 [AST] [Modules] Introduce Decl::getNonTransparentDeclContext to handle exported friends
Closing https://github.com/llvm/llvm-project/issues/56826.

The root cause for pr56826 is: when we collect the template args for the
friend, we need to judge if the friend lives in file context. However,
if the friend lives in ExportDecl lexically, the judgement here is
invalid.

The solution is easy. We should judge the non transparent context and
the ExportDecl is transparent context. So the solution should be good.

A main concern may be the patch doesn't handle all the places of the
same defect. I think it might not be bad since the patch itself should
be innocent.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D131651
2022-08-12 11:50:35 +08:00
Fangrui Song 3f18f7c007 [clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC
With C++17 there is no Clang pedantic warning or MSVC C5051.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D131346
2022-08-08 09:12:46 -07:00
Erich Keane 3ff86f9610 [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.
2022-07-22 12:37:14 -07:00
Kazu Hirata cb2c8f694d [clang] Use value instead of getValue (NFC) 2022-07-13 23:39:33 -07:00
serge-sans-paille da6a14b91a [clang] Enforce instantiation of constexpr template functions during non-constexpr evaluation
Otherwise these functions are not instantiated and we end up with an undefined
symbol.

Fix #55560

Differential Revision: https://reviews.llvm.org/D128119
2022-07-10 08:40:03 +02:00
Erich Keane 258c3aee54 Revert "Re-apply "Deferred Concept Instantiation Implementation"""
This reverts commit befa8cf087.

Apparently this breaks some libc++ builds with an apparent assertion,
 so I'm looking into that .
2022-07-01 11:20:16 -07:00
Erich Keane befa8cf087 Re-apply "Deferred Concept Instantiation Implementation""
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.
2022-07-01 06:51:38 -07:00
Jonas Devlieghere d4d47e574e
Revert "Deferred Concept Instantiation Implementation"
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.
2022-06-30 11:43:10 -07:00
Erich Keane 2f20743952 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
2022-06-30 06:47:11 -07:00
Kazu Hirata 3b7c3a654c Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3.
2022-06-25 11:56:50 -07:00
Kazu Hirata aa8feeefd3 Don't use Optional::hasValue (NFC) 2022-06-25 11:55:57 -07:00
Kazu Hirata 06decd0b41 [clang] Use value_or instead of getValueOr (NFC) 2022-06-18 23:21:34 -07:00
Roy Jacobson 21eb1af469 [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
2022-06-19 00:30:37 +03:00
Andrew Browne c7689fd552 [Clang] Fix memory leak due to TemplateArgumentListInfo used in AST node.
It looks like the leak is rooted at the allocation here:
1a155ee7de/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp (L3857)

The VarTemplateSpecializationDecl is allocated using placement new which uses the AST structure for ownership: 1a155ee7de/clang/lib/AST/DeclBase.cpp (L99)

The problem is the TemplateArgumentListInfo inside 1a155ee7de/clang/include/clang/AST/DeclTemplate.h (L2721)
This object contains a vector which does not use placement new: 1a155ee7de/clang/include/clang/AST/TemplateBase.h (L564)

Apparently ASTTemplateArgumentListInfo should be used instead 1a155ee7de/clang/include/clang/AST/TemplateBase.h (L575)

https://reviews.llvm.org/D125802#3551305

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D126944
2022-06-08 09:58:25 -07:00
Erich Keane 017abbb258 Revert ""Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""""
This reverts commit a425cac31e.

There is another libc++ test, that this time causes us to hit an
assertion. Reverting, likely for a while this time.
2022-05-09 09:12:05 -07:00
Erich Keane a425cac31e "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 45c07db31c.
2022-05-09 06:29:47 -07:00
Erich Keane 45c07db31c Revert "Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""
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.
2022-05-02 11:12:14 -07:00
Erich Keane a97899108e Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""
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.
2022-05-02 07:49:26 -07:00
Erich Keane 0c31da4838 Revert "Deferred Concept Instantiation Implementation"
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.
2022-05-02 06:25:38 -07:00
Erich Keane 4b6c2cd647 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
2022-05-02 05:49:15 -07:00
Richard Smith 72315d02c4 Treat `std::move`, `forward`, etc. as builtins.
This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

This is a re-commit of
  fc30901096,
  a571f82a50,
  64c045e25b, and
  de6ddaeef3,
and reverts aa643f455a.
This change also includes a workaround for users using libc++ 3.1 and
earlier (!!), as apparently happens on AIX, where std::move sometimes
returns by value.

Reviewed By: aaron.ballman

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

Revert "Fixup D123950 to address revert of D123345"

This reverts commit aa643f455a.
2022-04-20 17:58:31 -07:00
David Tenty 98d911e01f Revert "Treat `std::move`, `forward`, etc. as builtins."
This reverts commit b27430f9f4 as the
    parent https://reviews.llvm.org/D123345 breaks the AIX CI:

    https://lab.llvm.org/buildbot/#/builders/214/builds/819
2022-04-20 19:14:37 -04:00
David Tenty de6ddaeef3 Revert "Don't treat 'T &forward(T&&)' as builtin."
This reverts commit e43c93dd63 as the
parent https://reviews.llvm.org/D123345 breaks the AIX CI.
2022-04-20 19:14:36 -04:00