llvm-project/clang/lib/AST/ExprConcepts.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

196 lines
8.2 KiB
C++
Raw Normal View History

//===- ExprCXX.cpp - (C++) Expression AST Node Implementation -------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
//
// This file implements the subclesses of Expr class declared in ExprCXX.h
//
//===----------------------------------------------------------------------===//
#include "clang/AST/ExprConcepts.h"
#include "clang/AST/ASTConcept.h"
#include "clang/AST/ASTContext.h"
#include "clang/AST/ComputeDependence.h"
#include "clang/AST/Decl.h"
#include "clang/AST/DeclTemplate.h"
#include "clang/AST/DeclarationName.h"
#include "clang/AST/DependenceFlags.h"
#include "clang/AST/Expr.h"
#include "clang/AST/NestedNameSpecifier.h"
#include "clang/AST/TemplateBase.h"
#include "clang/AST/Type.h"
#include "clang/Basic/SourceLocation.h"
#include "llvm/Support/TrailingObjects.h"
#include <algorithm>
#include <string>
#include <utility>
using namespace clang;
ConceptSpecializationExpr::ConceptSpecializationExpr(
Add a concept AST node. This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places. There are three objects that might have constraints via concepts: `TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`. The first two inherit from `ConceptReference` while the latter has the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases. Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks. So we think that it makes sense to create a new AST node for such concepts. In details we propose the following: - Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate) and make it the new AST node. - `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`. - `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`. This patch implements a first version of this idea which compiles and where the existing tests pass. To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s. Differential Revision: https://reviews.llvm.org/D155858
2023-08-02 14:00:16 +02:00
const ASTContext &C, ConceptReference *Loc,
ImplicitConceptSpecializationDecl *SpecDecl,
const ConstraintSatisfaction *Satisfaction)
: Expr(ConceptSpecializationExprClass, C.BoolTy, VK_PRValue, OK_Ordinary),
Add a concept AST node. This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places. There are three objects that might have constraints via concepts: `TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`. The first two inherit from `ConceptReference` while the latter has the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases. Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks. So we think that it makes sense to create a new AST node for such concepts. In details we propose the following: - Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate) and make it the new AST node. - `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`. - `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`. This patch implements a first version of this idea which compiles and where the existing tests pass. To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s. Differential Revision: https://reviews.llvm.org/D155858
2023-08-02 14:00:16 +02:00
ConceptRef(Loc), SpecDecl(SpecDecl),
Satisfaction(Satisfaction
? ASTConstraintSatisfaction::Create(C, *Satisfaction)
: nullptr) {
setDependence(computeDependence(this, /*ValueDependent=*/!Satisfaction));
// Currently guaranteed by the fact concepts can only be at namespace-scope.
Add a concept AST node. This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places. There are three objects that might have constraints via concepts: `TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`. The first two inherit from `ConceptReference` while the latter has the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases. Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks. So we think that it makes sense to create a new AST node for such concepts. In details we propose the following: - Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate) and make it the new AST node. - `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`. - `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`. This patch implements a first version of this idea which compiles and where the existing tests pass. To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s. Differential Revision: https://reviews.llvm.org/D155858
2023-08-02 14:00:16 +02:00
assert(!Loc->getNestedNameSpecifierLoc() ||
(!Loc->getNestedNameSpecifierLoc()
.getNestedNameSpecifier()
->isInstantiationDependent() &&
!Loc->getNestedNameSpecifierLoc()
.getNestedNameSpecifier()
->containsUnexpandedParameterPack()));
assert((!isValueDependent() || isInstantiationDependent()) &&
"should not be value-dependent");
}
ConceptSpecializationExpr::ConceptSpecializationExpr(EmptyShell Empty)
: Expr(ConceptSpecializationExprClass, Empty) {}
Add a concept AST node. This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places. There are three objects that might have constraints via concepts: `TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`. The first two inherit from `ConceptReference` while the latter has the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases. Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks. So we think that it makes sense to create a new AST node for such concepts. In details we propose the following: - Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate) and make it the new AST node. - `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`. - `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`. This patch implements a first version of this idea which compiles and where the existing tests pass. To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s. Differential Revision: https://reviews.llvm.org/D155858
2023-08-02 14:00:16 +02:00
ConceptSpecializationExpr *
ConceptSpecializationExpr::Create(const ASTContext &C, ConceptReference *Loc,
ImplicitConceptSpecializationDecl *SpecDecl,
const ConstraintSatisfaction *Satisfaction) {
return new (C) ConceptSpecializationExpr(C, Loc, SpecDecl, Satisfaction);
}
ConceptSpecializationExpr::ConceptSpecializationExpr(
Add a concept AST node. This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places. There are three objects that might have constraints via concepts: `TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`. The first two inherit from `ConceptReference` while the latter has the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases. Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks. So we think that it makes sense to create a new AST node for such concepts. In details we propose the following: - Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate) and make it the new AST node. - `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`. - `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`. This patch implements a first version of this idea which compiles and where the existing tests pass. To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s. Differential Revision: https://reviews.llvm.org/D155858
2023-08-02 14:00:16 +02:00
const ASTContext &C, ConceptReference *Loc,
ImplicitConceptSpecializationDecl *SpecDecl,
const ConstraintSatisfaction *Satisfaction, bool Dependent,
bool ContainsUnexpandedParameterPack)
: Expr(ConceptSpecializationExprClass, C.BoolTy, VK_PRValue, OK_Ordinary),
Add a concept AST node. This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places. There are three objects that might have constraints via concepts: `TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`. The first two inherit from `ConceptReference` while the latter has the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases. Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks. So we think that it makes sense to create a new AST node for such concepts. In details we propose the following: - Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate) and make it the new AST node. - `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`. - `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`. This patch implements a first version of this idea which compiles and where the existing tests pass. To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s. Differential Revision: https://reviews.llvm.org/D155858
2023-08-02 14:00:16 +02:00
ConceptRef(Loc), SpecDecl(SpecDecl),
Satisfaction(Satisfaction
? ASTConstraintSatisfaction::Create(C, *Satisfaction)
: nullptr) {
ExprDependence D = ExprDependence::None;
if (!Satisfaction)
D |= ExprDependence::Value;
if (Dependent)
D |= ExprDependence::Instantiation;
if (ContainsUnexpandedParameterPack)
D |= ExprDependence::UnexpandedPack;
setDependence(D);
}
Add a concept AST node. This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places. There are three objects that might have constraints via concepts: `TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`. The first two inherit from `ConceptReference` while the latter has the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases. Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks. So we think that it makes sense to create a new AST node for such concepts. In details we propose the following: - Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate) and make it the new AST node. - `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`. - `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`. This patch implements a first version of this idea which compiles and where the existing tests pass. To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s. Differential Revision: https://reviews.llvm.org/D155858
2023-08-02 14:00:16 +02:00
ConceptSpecializationExpr *
ConceptSpecializationExpr::Create(const ASTContext &C, ConceptReference *Loc,
ImplicitConceptSpecializationDecl *SpecDecl,
const ConstraintSatisfaction *Satisfaction,
bool Dependent,
bool ContainsUnexpandedParameterPack) {
return new (C)
ConceptSpecializationExpr(C, Loc, SpecDecl, Satisfaction, Dependent,
ContainsUnexpandedParameterPack);
}
const TypeConstraint *
concepts::ExprRequirement::ReturnTypeRequirement::getTypeConstraint() const {
assert(isTypeConstraint());
auto TPL =
TypeConstraintInfo.getPointer().get<TemplateParameterList *>();
return cast<TemplateTypeParmDecl>(TPL->getParam(0))
->getTypeConstraint();
}
// Search through the requirements, and see if any have a RecoveryExpr in it,
// which means this RequiresExpr ALSO needs to be invalid.
static bool RequirementContainsError(concepts::Requirement *R) {
if (auto *ExprReq = dyn_cast<concepts::ExprRequirement>(R))
return ExprReq->getExpr() && ExprReq->getExpr()->containsErrors();
if (auto *NestedReq = dyn_cast<concepts::NestedRequirement>(R))
return !NestedReq->hasInvalidConstraint() &&
NestedReq->getConstraintExpr() &&
NestedReq->getConstraintExpr()->containsErrors();
return false;
}
RequiresExpr::RequiresExpr(ASTContext &C, SourceLocation RequiresKWLoc,
Implement mangling rules for C++20 concepts and requires-expressions. This implements proposals from: - https://github.com/itanium-cxx-abi/cxx-abi/issues/24: mangling for constraints, requires-clauses, requires-expressions. - https://github.com/itanium-cxx-abi/cxx-abi/issues/31: requires-clauses and template parameters in a lambda expression are mangled into the <lambda-sig>. - https://github.com/itanium-cxx-abi/cxx-abi/issues/47 (STEP 3): mangling for template argument is prefixed by mangling of template parameter declaration if it's not "obvious", for example because the template parameter is constrained (we already implemented STEP 1 and STEP 2). This changes the manglings for a few cases: - Functions and function templates with constraints. - Function templates with template parameters with deduced types: `typename<auto N> void f();` - Function templates with template template parameters where the argument has a different template-head: `template<template<typename...T>> void f(); f<std::vector>();` In each case where a mangling changed, the change fixes a mangling collision. Note that only function templates are affected, not class templates or variable templates, and only new constructs (template parameters with deduced types, constrained templates) and esoteric constructs (templates with template template parameters with non-matching template template arguments, most of which Clang still does not accept by default due to `-frelaxed-template-template-args` not being enabled by default), so the risk to ABI stability from this change is relatively low. Nonetheless, `-fclang-abi-compat=17` can be used to restore the old manglings for cases which we could successfully but incorrectly mangle before. Fixes #48216, #49884, #61273 Reviewed By: erichkeane, #libc_abi Differential Revision: https://reviews.llvm.org/D147655
2023-09-12 18:53:54 -07:00
RequiresExprBodyDecl *Body, SourceLocation LParenLoc,
ArrayRef<ParmVarDecl *> LocalParameters,
Implement mangling rules for C++20 concepts and requires-expressions. This implements proposals from: - https://github.com/itanium-cxx-abi/cxx-abi/issues/24: mangling for constraints, requires-clauses, requires-expressions. - https://github.com/itanium-cxx-abi/cxx-abi/issues/31: requires-clauses and template parameters in a lambda expression are mangled into the <lambda-sig>. - https://github.com/itanium-cxx-abi/cxx-abi/issues/47 (STEP 3): mangling for template argument is prefixed by mangling of template parameter declaration if it's not "obvious", for example because the template parameter is constrained (we already implemented STEP 1 and STEP 2). This changes the manglings for a few cases: - Functions and function templates with constraints. - Function templates with template parameters with deduced types: `typename<auto N> void f();` - Function templates with template template parameters where the argument has a different template-head: `template<template<typename...T>> void f(); f<std::vector>();` In each case where a mangling changed, the change fixes a mangling collision. Note that only function templates are affected, not class templates or variable templates, and only new constructs (template parameters with deduced types, constrained templates) and esoteric constructs (templates with template template parameters with non-matching template template arguments, most of which Clang still does not accept by default due to `-frelaxed-template-template-args` not being enabled by default), so the risk to ABI stability from this change is relatively low. Nonetheless, `-fclang-abi-compat=17` can be used to restore the old manglings for cases which we could successfully but incorrectly mangle before. Fixes #48216, #49884, #61273 Reviewed By: erichkeane, #libc_abi Differential Revision: https://reviews.llvm.org/D147655
2023-09-12 18:53:54 -07:00
SourceLocation RParenLoc,
ArrayRef<concepts::Requirement *> Requirements,
SourceLocation RBraceLoc)
: Expr(RequiresExprClass, C.BoolTy, VK_PRValue, OK_Ordinary),
NumLocalParameters(LocalParameters.size()),
Implement mangling rules for C++20 concepts and requires-expressions. This implements proposals from: - https://github.com/itanium-cxx-abi/cxx-abi/issues/24: mangling for constraints, requires-clauses, requires-expressions. - https://github.com/itanium-cxx-abi/cxx-abi/issues/31: requires-clauses and template parameters in a lambda expression are mangled into the <lambda-sig>. - https://github.com/itanium-cxx-abi/cxx-abi/issues/47 (STEP 3): mangling for template argument is prefixed by mangling of template parameter declaration if it's not "obvious", for example because the template parameter is constrained (we already implemented STEP 1 and STEP 2). This changes the manglings for a few cases: - Functions and function templates with constraints. - Function templates with template parameters with deduced types: `typename<auto N> void f();` - Function templates with template template parameters where the argument has a different template-head: `template<template<typename...T>> void f(); f<std::vector>();` In each case where a mangling changed, the change fixes a mangling collision. Note that only function templates are affected, not class templates or variable templates, and only new constructs (template parameters with deduced types, constrained templates) and esoteric constructs (templates with template template parameters with non-matching template template arguments, most of which Clang still does not accept by default due to `-frelaxed-template-template-args` not being enabled by default), so the risk to ABI stability from this change is relatively low. Nonetheless, `-fclang-abi-compat=17` can be used to restore the old manglings for cases which we could successfully but incorrectly mangle before. Fixes #48216, #49884, #61273 Reviewed By: erichkeane, #libc_abi Differential Revision: https://reviews.llvm.org/D147655
2023-09-12 18:53:54 -07:00
NumRequirements(Requirements.size()), Body(Body), LParenLoc(LParenLoc),
RParenLoc(RParenLoc), RBraceLoc(RBraceLoc) {
RequiresExprBits.IsSatisfied = false;
RequiresExprBits.RequiresKWLoc = RequiresKWLoc;
bool Dependent = false;
bool ContainsUnexpandedParameterPack = false;
for (ParmVarDecl *P : LocalParameters) {
Dependent |= P->getType()->isInstantiationDependentType();
ContainsUnexpandedParameterPack |=
P->getType()->containsUnexpandedParameterPack();
}
RequiresExprBits.IsSatisfied = true;
for (concepts::Requirement *R : Requirements) {
Dependent |= R->isDependent();
ContainsUnexpandedParameterPack |= R->containsUnexpandedParameterPack();
if (!Dependent) {
RequiresExprBits.IsSatisfied = R->isSatisfied();
if (!RequiresExprBits.IsSatisfied)
break;
}
if (RequirementContainsError(R))
setDependence(getDependence() | ExprDependence::Error);
}
std::copy(LocalParameters.begin(), LocalParameters.end(),
getTrailingObjects<ParmVarDecl *>());
std::copy(Requirements.begin(), Requirements.end(),
getTrailingObjects<concepts::Requirement *>());
RequiresExprBits.IsSatisfied |= Dependent;
// FIXME: move the computing dependency logic to ComputeDependence.h
if (ContainsUnexpandedParameterPack)
setDependence(getDependence() | ExprDependence::UnexpandedPack);
// FIXME: this is incorrect for cases where we have a non-dependent
// requirement, but its parameters are instantiation-dependent. RequiresExpr
// should be instantiation-dependent if it has instantiation-dependent
// parameters.
if (Dependent)
setDependence(getDependence() | ExprDependence::ValueInstantiation);
}
RequiresExpr::RequiresExpr(ASTContext &C, EmptyShell Empty,
unsigned NumLocalParameters,
unsigned NumRequirements)
: Expr(RequiresExprClass, Empty), NumLocalParameters(NumLocalParameters),
NumRequirements(NumRequirements) { }
Implement mangling rules for C++20 concepts and requires-expressions. This implements proposals from: - https://github.com/itanium-cxx-abi/cxx-abi/issues/24: mangling for constraints, requires-clauses, requires-expressions. - https://github.com/itanium-cxx-abi/cxx-abi/issues/31: requires-clauses and template parameters in a lambda expression are mangled into the <lambda-sig>. - https://github.com/itanium-cxx-abi/cxx-abi/issues/47 (STEP 3): mangling for template argument is prefixed by mangling of template parameter declaration if it's not "obvious", for example because the template parameter is constrained (we already implemented STEP 1 and STEP 2). This changes the manglings for a few cases: - Functions and function templates with constraints. - Function templates with template parameters with deduced types: `typename<auto N> void f();` - Function templates with template template parameters where the argument has a different template-head: `template<template<typename...T>> void f(); f<std::vector>();` In each case where a mangling changed, the change fixes a mangling collision. Note that only function templates are affected, not class templates or variable templates, and only new constructs (template parameters with deduced types, constrained templates) and esoteric constructs (templates with template template parameters with non-matching template template arguments, most of which Clang still does not accept by default due to `-frelaxed-template-template-args` not being enabled by default), so the risk to ABI stability from this change is relatively low. Nonetheless, `-fclang-abi-compat=17` can be used to restore the old manglings for cases which we could successfully but incorrectly mangle before. Fixes #48216, #49884, #61273 Reviewed By: erichkeane, #libc_abi Differential Revision: https://reviews.llvm.org/D147655
2023-09-12 18:53:54 -07:00
RequiresExpr *RequiresExpr::Create(
ASTContext &C, SourceLocation RequiresKWLoc, RequiresExprBodyDecl *Body,
SourceLocation LParenLoc, ArrayRef<ParmVarDecl *> LocalParameters,
SourceLocation RParenLoc, ArrayRef<concepts::Requirement *> Requirements,
SourceLocation RBraceLoc) {
void *Mem =
C.Allocate(totalSizeToAlloc<ParmVarDecl *, concepts::Requirement *>(
LocalParameters.size(), Requirements.size()),
alignof(RequiresExpr));
Implement mangling rules for C++20 concepts and requires-expressions. This implements proposals from: - https://github.com/itanium-cxx-abi/cxx-abi/issues/24: mangling for constraints, requires-clauses, requires-expressions. - https://github.com/itanium-cxx-abi/cxx-abi/issues/31: requires-clauses and template parameters in a lambda expression are mangled into the <lambda-sig>. - https://github.com/itanium-cxx-abi/cxx-abi/issues/47 (STEP 3): mangling for template argument is prefixed by mangling of template parameter declaration if it's not "obvious", for example because the template parameter is constrained (we already implemented STEP 1 and STEP 2). This changes the manglings for a few cases: - Functions and function templates with constraints. - Function templates with template parameters with deduced types: `typename<auto N> void f();` - Function templates with template template parameters where the argument has a different template-head: `template<template<typename...T>> void f(); f<std::vector>();` In each case where a mangling changed, the change fixes a mangling collision. Note that only function templates are affected, not class templates or variable templates, and only new constructs (template parameters with deduced types, constrained templates) and esoteric constructs (templates with template template parameters with non-matching template template arguments, most of which Clang still does not accept by default due to `-frelaxed-template-template-args` not being enabled by default), so the risk to ABI stability from this change is relatively low. Nonetheless, `-fclang-abi-compat=17` can be used to restore the old manglings for cases which we could successfully but incorrectly mangle before. Fixes #48216, #49884, #61273 Reviewed By: erichkeane, #libc_abi Differential Revision: https://reviews.llvm.org/D147655
2023-09-12 18:53:54 -07:00
return new (Mem)
RequiresExpr(C, RequiresKWLoc, Body, LParenLoc, LocalParameters,
RParenLoc, Requirements, RBraceLoc);
}
RequiresExpr *
RequiresExpr::Create(ASTContext &C, EmptyShell Empty,
unsigned NumLocalParameters, unsigned NumRequirements) {
void *Mem =
C.Allocate(totalSizeToAlloc<ParmVarDecl *, concepts::Requirement *>(
NumLocalParameters, NumRequirements),
alignof(RequiresExpr));
return new (Mem) RequiresExpr(C, Empty, NumLocalParameters, NumRequirements);
}