@@ -91,15 +91,84 @@ void bar() {
namespace GH82104 {
-template int Zero = 0;
+template int Value = sizeof...(D);
mizvekov wrote:
```suggestion
template constexpr int Value = sizeof...(D);
```
https://github.com/llvm/llvm-project/pull/89934
__
https://github.com/mizvekov approved this pull request.
I agree this is not the long term way forward, but it improves the current
interim solution, so LGTM, minus nit.
https://github.com/llvm/llvm-project/pull/89934
___
cfe-commits mailing list
cfe-c
@@ -91,15 +91,60 @@ void bar() {
namespace GH82104 {
-template int Zero = 0;
+template int Value = sizeof...(D);
-template
-using T14 = decltype([]() { return Zero; }());
+template
+using T14 = decltype([](auto Param) {
+ return Value + V + (int)sizeof(Param);
+}("hell
@@ -5554,38 +5869,50 @@ FunctionTemplateDecl *Sema::getMoreSpecializedTemplate(
// "that is a member function with no expicit object argument".
// Otherwise the ordering rules for methods with expicit objet arguments
// against anything else make no sense.
-Shou
https://github.com/mizvekov updated
https://github.com/llvm/llvm-project/pull/100692
>From f8fd471a954f5e304f3118df3236cf7ff4ef1020 Mon Sep 17 00:00:00 2001
From: Matheus Izvekov
Date: Wed, 24 Jul 2024 03:59:41 -0300
Subject: [PATCH] [clang] check deduction consistency when partial ordering
fu
@@ -972,8 +972,15 @@ static const Expr
*SubstituteConstraintExpressionWithoutSatisfaction(
// equivalence.
LocalInstantiationScope ScopeForParameters(S);
if (auto *FD = DeclInfo.getDecl()->getAsFunction())
-for (auto *PVD : FD->parameters())
- ScopeForParameters
@@ -972,8 +972,15 @@ static const Expr
*SubstituteConstraintExpressionWithoutSatisfaction(
// equivalence.
LocalInstantiationScope ScopeForParameters(S);
if (auto *FD = DeclInfo.getDecl()->getAsFunction())
-for (auto *PVD : FD->parameters())
- ScopeForParameters
@@ -972,8 +972,15 @@ static const Expr
*SubstituteConstraintExpressionWithoutSatisfaction(
// equivalence.
LocalInstantiationScope ScopeForParameters(S);
if (auto *FD = DeclInfo.getDecl()->getAsFunction())
-for (auto *PVD : FD->parameters())
- ScopeForParameters
mizvekov wrote:
I not opposed to exploring a solution now. I suspect there might be a nicer
solution that doesn't involve copies, I just have other priorities right now
and it will take me a while until I can sit down and think about this.
But if you want to think about the problem and find a
@@ -5399,11 +5434,85 @@ static QualType
GetImplicitObjectParameterType(ASTContext &Context,
return Context.getLValueReferenceType(RawType);
}
+static TemplateDeductionResult FinishTemplateArgumentDeduction(
+Sema &S, FunctionTemplateDecl *FTD, int ArgIdx, QualType P, Qu
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -std=c++23 -verify %s
+
+namespace t1 {
+template struct enable_if { typedef void type; };
+template class Foo {};
+template constexpr bool check() { return true; }
+template struct Bar {};
+
+template void func(Bar()>::type>) {}
+// expecte
@@ -1307,6 +1304,62 @@ DeduceTemplateArguments(Sema &S, TemplateParameterList
*TemplateParams,
return TemplateDeductionResult::Success;
}
+/// Deduce the template arguments by comparing the list of parameter
+/// types to the list of argument types, as in the parameter-type
@@ -859,8 +861,10 @@ class PackDeductionScope {
// by this pack expansion, then clear out the deduction.
DeducedFromEarlierParameter = !Deduced[Index].isNull();
DeducedPack Pack(Index);
-Pack.Saved = Deduced[Index];
-Deduced[Index] = TemplateArgument();
+
@@ -5421,34 +5635,139 @@ static bool isAtLeastAsSpecializedAs(Sema &S,
SourceLocation Loc,
// the partial ordering is done:
TemplateDeductionInfo Info(Loc);
switch (TPOC) {
- case TPOC_Call:
-if (DeduceTemplateArguments(S, TemplateParams, Args2.data(), Args2.size(
@@ -5421,34 +5635,139 @@ static bool isAtLeastAsSpecializedAs(Sema &S,
SourceLocation Loc,
// the partial ordering is done:
TemplateDeductionInfo Info(Loc);
switch (TPOC) {
- case TPOC_Call:
-if (DeduceTemplateArguments(S, TemplateParams, Args2.data(), Args2.size(
@@ -5395,11 +5520,100 @@ static QualType
GetImplicitObjectParameterType(ASTContext &Context,
return Context.getLValueReferenceType(RawType);
}
+static TemplateDeductionResult CheckDeductionConsistency(
+Sema &S, FunctionTemplateDecl *FTD, int ArgIdx, QualType P, QualTyp
@@ -1343,6 +1343,9 @@ namespace {
DeclarationName Entity;
// Whether to evaluate the C++20 constraints or simply substitute into
them.
bool EvaluateConstraints = true;
+// Whether Substitution was Incomplete, that is, we tried to substitute in
+// any templ
@@ -5554,38 +5869,50 @@ FunctionTemplateDecl *Sema::getMoreSpecializedTemplate(
// "that is a member function with no expicit object argument".
// Otherwise the ordering rules for methods with expicit objet arguments
// against anything else make no sense.
-Shou
@@ -5346,7 +5346,6 @@ static EvalStmtResult EvaluateStmt(StmtResult &Result,
EvalInfo &Info,
const Expr *RetExpr = cast(S)->getRetValue();
FullExpressionRAII Scope(Info);
if (RetExpr && RetExpr->isValueDependent()) {
- EvaluateDependentExpr(RetExpr, Info);
---
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
@@ -5968,11 +5962,21 @@
ASTNodeImporter::VisitTemplateTypeParmDecl(TemplateTypeParmDecl *D) {
}
if (D->hasDefaultArgument()) {
+// Default argument can be "inherited" when it has a reference to the
+// previous d
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/101836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
@@ -5968,11 +5962,21 @@
ASTNodeImporter::VisitTemplateTypeParmDecl(TemplateTypeParmDecl *D) {
}
if (D->hasDefaultArgument()) {
+// Default argument can be "inherited" when it has a reference to the
+// previous d
mizvekov wrote:
Yes, I think it's ok having the template instantiator own these lists, but only
copy them when needed.
Note I have a WIP patch that will eventually touch this area and this may force
me to seek a solution here.
Basically TemplateArgument lists will need to get the AST node uni
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
@@ -5968,11 +5962,21 @@
ASTNodeImporter::VisitTemplateTypeParmDecl(TemplateTypeParmDecl *D) {
}
if (D->hasDefaultArgument()) {
+// Default argument can be "inherited" when it has a reference to the
+// previous d
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
@@ -5934,8 +5928,8 @@
ASTNodeImporter::VisitObjCPropertyImplDecl(ObjCPropertyImplDecl *D) {
ExpectedDecl
ASTNodeImporter::VisitTemplateTypeParmDecl(TemplateTypeParmDecl *D) {
// For template arguments, we adopt the translat
https://github.com/mizvekov approved this pull request.
The assert was never added to the template template parameter case, but I think
a test case might be good here.
But in any case this LGTM.
https://github.com/llvm/llvm-project/pull/99813
___
cfe
@@ -4462,6 +4462,9 @@ TemplateDeductionResult Sema::DeduceTemplateArguments(
ParamTypesForArgChecking.push_back(ParamType);
if (ParamIdx == 0 && HasExplicitObject) {
+if (ObjectType.isNull())
+ return TemplateDeductionResult::InvalidExplicitArgumen
@@ -4462,6 +4462,9 @@ TemplateDeductionResult Sema::DeduceTemplateArguments(
ParamTypesForArgChecking.push_back(ParamType);
if (ParamIdx == 0 && HasExplicitObject) {
+if (ObjectType.isNull())
+ return TemplateDeductionResult::InvalidExplicitArgumen
@@ -4462,6 +4462,9 @@ TemplateDeductionResult Sema::DeduceTemplateArguments(
ParamTypesForArgChecking.push_back(ParamType);
if (ParamIdx == 0 && HasExplicitObject) {
+if (ObjectType.isNull())
+ return TemplateDeductionResult::InvalidExplicitArgumen
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/104328
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov commented:
I'd have expected we would have a previous step analogous to
CheckTemplateArgument which would have diagnosed null explicit arguments,
before we started trying to deduce anything.
https://github.com/llvm/llvm-project/pull/104328
__
mizvekov wrote:
@zygoloid ping, this is ready for another look.
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mizvekov wrote:
Closed as completed elsewhere.
https://github.com/llvm/llvm-project/pull/102510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov closed
https://github.com/llvm/llvm-project/pull/102510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov approved this pull request.
LGTM
As a note, it's helpful to pre-commit on an NFC patch all these test cases, and
then on the main PR we can see just which test cases changed behavior.
Which I see here are the three test cases at lines 76-78, 84-86, and 96-98.
htt
mizvekov wrote:
> Thinking twice, I think this is probably feasible to go. As an internal flag
> wouldn't be exposed to users, but we might have to refactor the function a
> lot more.
Yep. Just don't forget to assert in case the template arguments wouldn't get
added, to diagnose users passing
mizvekov wrote:
I think we could instead simplify the function to the following signature:
```C++
MultiLevelTemplateArgumentList Sema::getTemplateInstantiationArgs(
const Decl *D, bool LexicalParent, bool Final, .)
```
Ie we take a single decl, which we will assume is a NamedDecl in case
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/102922
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov commented:
I think I'd need to see how you would use it, to say if this would be the best
approach.
It's not clear to me why we would want to navigate to a DC that is unrelated to
the passed ND.
Can we at least assert the DC would be a parent (Lexical or Semantic)
mizvekov wrote:
> I think using "broken" in the name of the diagnostic and the internal option
> is a bit problematic -- that's too much of a value judgement, IMO. After all,
> the previous functionality worked well enough for those folks.
>
>
>
> Would it make more sense to name it somethin
mizvekov wrote:
> It is not only valuable to external resugarers. Another point that warrants
> an introduction of it is for unevaluated lambdas. These lambdas e.g.
> appearing as part of the `using Alias = decltype(lambda)` could carry a
> requires expression and thus evaluating it requires t
mizvekov wrote:
> Hmm. The best solution there is probably to use a consistent representation
> but introduce some sort of `GLValueThatTheStandardAbsurdlyPretendsIsAnRValue`
> (definitely the only and best word for this, ship it) that we can use as the
> value category. IIRC, something similar
mizvekov wrote:
> The description specifies "Reverted due to both regression reported on PR and
> https://github.com/llvm/llvm-project/issues/102353"; but somehow the commit
> message does not include the reason.
>
> (I just tried to look at reverts without reasons and remind the authors.)
I
https://github.com/mizvekov closed
https://github.com/llvm/llvm-project/pull/102551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mizvekov wrote:
> (It's #102353)
Updated, thanks for the correction.
https://github.com/llvm/llvm-project/pull/102551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/102551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov updated
https://github.com/llvm/llvm-project/pull/102551
>From c70e98cef58982fd7afb896fe08ebacc8b752009 Mon Sep 17 00:00:00 2001
From: Matheus Izvekov
Date: Thu, 8 Aug 2024 20:18:01 -0300
Subject: [PATCH] Revert "[clang] Reland: Instantiate concepts with sugared
tem
https://github.com/mizvekov created
https://github.com/llvm/llvm-project/pull/102551
This reverts commit 748371183ae769bfb485f1e7466a864bf1db93d5.
Reverted due to both regression reported on PR and #102253
>From cce965741a7496f792e3f94f47ae5acba06c4c39 Mon Sep 17 00:00:00 2001
From: Matheus Iz
@@ -6131,52 +6149,30 @@ class BTFTagAttributedType : public Type, public
llvm::FoldingSetNode {
class TemplateTypeParmType : public Type, public llvm::FoldingSetNode {
friend class ASTContext; // ASTContext creates these
- // Helper data collector for canonical types.
- s
mizvekov wrote:
> @mizvekov I will provide a more detailed response to the points you made in
> your last message separately, but for now I would like to ask you to revert
> the commit to unbreak us.
@gribozavr see https://github.com/llvm/llvm-project/pull/102510 for alternative.
> which mea
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/102510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov created
https://github.com/llvm/llvm-project/pull/102510
There are some external projects that can't rely on our own sugar propagation
for templated entities, because they need to resugar types which only exist
within their framework, and so are entirely invisible t
https://github.com/mizvekov approved this pull request.
LGTM
Are there any performance numbers worth mentioning?
https://github.com/llvm/llvm-project/pull/102481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
@@ -18075,6 +18075,15 @@ void Sema::ActOnTagFinishDefinition(Scope *S, Decl
*TagD,
if (NumInitMethods > 1 || !Def->hasInitMethod())
Diag(RD->getLocation(), diag::err_sycl_special_type_num_init_method);
}
+
+// If we're defining a dynamic class in a module
@@ -18075,6 +18075,15 @@ void Sema::ActOnTagFinishDefinition(Scope *S, Decl
*TagD,
if (NumInitMethods > 1 || !Def->hasInitMethod())
Diag(RD->getLocation(), diag::err_sycl_special_type_num_init_method);
}
+
+// If we're defining a dynamic class in a module
https://github.com/mizvekov approved this pull request.
LGTM, Thanks!
https://github.com/llvm/llvm-project/pull/102287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/102287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2376,6 +2376,12 @@ NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II,
unsigned ID,
FunctionDecl *New = CreateBuiltin(II, R, ID, Loc);
RegisterLocallyScopedExternCDecl(New, S);
+ // Builtin functions shouldn't be owned by any module.
+ if (New->hasOwningModule(
mizvekov wrote:
> We keep track of propagated and inferred nullability annotations in a [side
> data
> structure](https://github.com/google/crubit/blob/main/nullability/type_nullability.h#L185).
> Our approach allows us to save on memory by not actually re-instantiating
> everything with new
@@ -2376,6 +2376,12 @@ NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II,
unsigned ID,
FunctionDecl *New = CreateBuiltin(II, R, ID, Loc);
RegisterLocallyScopedExternCDecl(New, S);
+ // Builtin functions shouldn't be owned by any module.
+ if (New->hasOwningModule(
@@ -1225,13 +1252,7 @@ bool CodeGenVTables::isVTableExternal(const
CXXRecordDecl *RD) {
const FunctionDecl *Def;
// Otherwise, if we don't have a definition of the key function, the
// vtable must be defined somewhere else.
- if (!keyFunction->hasBody(Def))
-return
@@ -18484,11 +18484,15 @@ bool Sema::DefineUsedVTables() {
bool DefineVTable = true;
-// If this class has a key function, but that key function is
-// defined in another translation unit, we don't need to emit the
-// vtable even though we're using it.
c
@@ -1529,8 +1529,14 @@ void ASTDeclWriter::VisitCXXRecordDecl(CXXRecordDecl *D)
{
if (D->isThisDeclarationADefinition())
Record.AddCXXDefinitionData(D);
+ if (D->isCompleteDefinition() && D->isInNamedModule())
+Writer.AddDeclRef(D, Writer.ModularCodegenDecls);
+
@@ -5317,6 +5329,17 @@ void ASTWriter::WriteSpecialDeclRecords(Sema &SemaRef) {
}
if (!DeleteExprsToAnalyze.empty())
Stream.EmitRecord(DELETE_EXPRS_TO_ANALYZE, DeleteExprsToAnalyze);
+
+ RecordData VTablesToEmit;
+ for (CXXRecordDecl *RD : PendingEmittingVTables) {
+
@@ -1124,20 +1124,36 @@ bool Decl::isInAnotherModuleUnit() const {
if (!M)
return false;
+ // FIXME or NOTE: maybe we need to be clear about the semantics
+ // of clang header modules. e.g., if this lives in a clang header
+ // module included by the current unit, sho
@@ -1081,29 +1081,41 @@ llvm::GlobalVariable::LinkageTypes
CodeGenModule::getVTableLinkage(const CXXRecordDecl *RD) {
if (!RD->isExternallyVisible())
return llvm::GlobalVariable::InternalLinkage;
-
- // We're at the end of the translation unit, so the current key
- // f
@@ -1216,6 +1228,21 @@ bool CodeGenVTables::isVTableExternal(const
CXXRecordDecl *RD) {
TSK == TSK_ExplicitInstantiationDefinition)
return false;
+ // Itanium C++ ABI [5.2.3]:
+ // Virtual tables for dynamic classes are emitted as follows:
+ //
+ // - If the cla
@@ -5163,6 +5168,13 @@ void ASTWriter::PrepareWritingSpecialDecls(Sema
&SemaRef) {
// Write all of the DeclsToCheckForDeferredDiags.
for (auto *D : SemaRef.DeclsToCheckForDeferredDiags)
GetDeclRef(D);
+
+ // Write all classes need to emit the vtable definitions if req
@@ -12432,7 +12432,7 @@ bool ASTContext::DeclMustBeEmitted(const Decl *D) {
return false;
// Variables in other module units shouldn't be forced to be emitted.
- if (VD->isInAnotherModuleUnit())
+ if (VD->shouldEmitInExternalSource())
mizvekov wrote:
@@ -790,6 +790,11 @@ class ASTReader
/// the consumer eagerly.
SmallVector EagerlyDeserializedDecls;
+ /// The IDs of all vtables to emit. The referenced declarations are passed
+ /// to the consumers's HandleVTable eagerly after passing
mizvekov wrote:
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/102287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov commented:
Thanks!
The functional part LGTM, there are just a few nits.
https://github.com/llvm/llvm-project/pull/102287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
@@ -2376,6 +2376,12 @@ NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II,
unsigned ID,
FunctionDecl *New = CreateBuiltin(II, R, ID, Loc);
RegisterLocallyScopedExternCDecl(New, S);
+ // Builtin functions shouldn't be owned by any module.
+ if (New->hasOwningModule(
@@ -2376,6 +2376,12 @@ NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II,
unsigned ID,
FunctionDecl *New = CreateBuiltin(II, R, ID, Loc);
RegisterLocallyScopedExternCDecl(New, S);
+ // Builtin functions shouldn't be owned by any module.
+ if (New->hasOwningModule(
mizvekov wrote:
> I don't know, but it would be a lot of work, and would likely still mean
> preserving the same information as `SubstTemplateTypeParmType` nodes
> currently provide.
>
> Our scope is also larger than what Clang's resugarer aims to do, because for
> our purposes sometimes ther
@@ -6719,6 +6719,16 @@ QualType Sema::CheckVectorConditionalTypes(ExprResult
&Cond, ExprResult &LHS,
: UsualArithmeticConversions(LHS, RHS, QuestionLoc,
ACK_Conditional);
+if (ResultElementTy.isNull()) {
+ Diag(Que
https://github.com/mizvekov approved this pull request.
LGTM, Thanks!
https://github.com/llvm/llvm-project/pull/102206
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -5838,7 +5839,7 @@ QualType
TreeTransform::TransformDependentAddressSpaceType(
} else {
TypeSourceInfo *DI = getSema().Context.getTrivialTypeSourceInfo(
Result, getDerived().getBaseLocation());
-TransformType(TLB, DI->getTypeLoc());
+TLB.TypeWasModifie
https://github.com/mizvekov approved this pull request.
Yeah, looks NFC to me as well.
LGTM
https://github.com/llvm/llvm-project/pull/101765
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
mizvekov wrote:
Is this a dataflow analysis in upstream clang, or is this something you are
developing?
https://github.com/llvm/llvm-project/pull/102196
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
mizvekov wrote:
Do you have a C++ source file example which presents misbehaviour when compiled
through clang, which this change fixes?
If so, you can reduce that example and add is as a regression test. These go in
`clang/test/` and are basically composed of C++ source and some annotations to
mizvekov wrote:
Is this a bug fix? If so, do you have a test case for this?
If the change is supposed to be user or API visible, a release note explaining
it would also be useful.
https://github.com/llvm/llvm-project/pull/102196
___
cfe-commits maili
mizvekov wrote:
> I agree that we don't need `SubstTemplateTypeParmType` nodes if all
> resuraging that we ever do is related to types that the Clang frontend itself
> knows. However that is not universally true.
>
> For example, we (Google) have a tool for inferring and checking nullability
mizvekov wrote:
One possibility here is that if you have the type, then you will have a
template specialization type for the template alias, and that gives you the
template arguments used to specialize the alias. Which should answer this need.
But of course, if you have a lossy semantic adjust
mizvekov wrote:
The basic premise here was implemented back in D134604, and this has been for
a few years applied in some cases, like substitution of default arguments.
We leave a Subst* node behind with the purpose of somewhere down the line
changing it back to what the user wrote.
So we do
https://github.com/mizvekov commented:
I agree that the issue with many parameters is pre-existing.
So you add a new flag to the UnresolvedLookupExpr which just forwards to the
same flag in the base class OverloadExpr.
OverloadExpr already suffers, even worse, from this problem of too many
pa
@@ -8629,13 +8629,14 @@
ASTNodeImporter::VisitUnresolvedLookupExpr(UnresolvedLookupExpr *E) {
return UnresolvedLookupExpr::Create(
Importer.getToContext(), *ToNamingClassOrErr, *ToQualifierLocOrErr,
*ToTemplateKeywordLocOrErr, ToNameInfo, E->requiresADL(),
@@ -8629,13 +8629,14 @@
ASTNodeImporter::VisitUnresolvedLookupExpr(UnresolvedLookupExpr *E) {
return UnresolvedLookupExpr::Create(
Importer.getToContext(), *ToNamingClassOrErr, *ToQualifierLocOrErr,
*ToTemplateKeywordLocOrErr, ToNameInfo, E->requiresADL(),
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/100392
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov updated
https://github.com/llvm/llvm-project/pull/100692
>From 561c9125d28c21676e4c28f0f04247433a860d62 Mon Sep 17 00:00:00 2001
From: Matheus Izvekov
Date: Wed, 24 Jul 2024 03:59:41 -0300
Subject: [PATCH] [clang] check deduction consistency when partial ordering
fu
mizvekov wrote:
@zygoloid ping, this is ready for another round of review.
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov updated
https://github.com/llvm/llvm-project/pull/100692
>From 3771ffabce14ab67f53d2a2f4357b0bd13c8088a Mon Sep 17 00:00:00 2001
From: Matheus Izvekov
Date: Wed, 24 Jul 2024 03:59:41 -0300
Subject: [PATCH] [clang] check deduction consistency when partial ordering
fu
mizvekov wrote:
> @mizvekov, do you have any idea how to get back the lost
> `SubstTemplateTypeParmType`? It plays an important role in the IWYU tool
> analysis. Thanks!
So from my undertstanding, IWYU only needs the SubstTemplateTypeParmType for
resugaring purposes, in order to recover the t
https://github.com/mizvekov closed
https://github.com/llvm/llvm-project/pull/101858
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov updated
https://github.com/llvm/llvm-project/pull/101858
>From 1c6bfceea2a50b822a111996a481afe8fb8e522d Mon Sep 17 00:00:00 2001
From: Matheus Izvekov
Date: Sun, 23 Oct 2022 16:57:12 +0200
Subject: [PATCH] [clang] Reland: Instantiate alias templates with sugar
This
https://github.com/mizvekov edited
https://github.com/llvm/llvm-project/pull/101858
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov closed
https://github.com/llvm/llvm-project/pull/101782
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mizvekov wrote:
Since this is relanding of patch that has been previously reviewed, with no
notable changes except rebase and canonicalization when indexing the
satisfaction cache, I am going to go ahead and merge.
https://github.com/llvm/llvm-project/pull/101782
__
https://github.com/mizvekov updated
https://github.com/llvm/llvm-project/pull/101782
>From 6a172a93121fdbeb0e58b33ec3140f150ecb524a Mon Sep 17 00:00:00 2001
From: Matheus Izvekov
Date: Sun, 23 Oct 2022 11:37:20 +0200
Subject: [PATCH] [clang] Reland: Instantiate concepts with sugared template
a
https://github.com/mizvekov closed
https://github.com/llvm/llvm-project/pull/101594
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
101 - 200 of 855 matches
Mail list logo
