[PATCH] D138914: Make evaluation of nested requirement consistent with requires expr.

Erich Keane via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Dec 1 06:44:51 PST 2022


erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

Happy now, thanks!



================
Comment at: clang/include/clang/AST/ExprConcepts.h:428
+      : Requirement(RK_Nested,
+                    Constraint && Constraint->isInstantiationDependent(),
+                    Constraint && Constraint->containsUnexpandedParameterPack(),
----------------
usaxena95 wrote:
> erichkeane wrote:
> > erichkeane wrote:
> > > I'm a little concerned that we're changing to a situation where the constraint in a nested-requirement can be null like this.  The other cases it can be null we consider it a 'substitution failure' (see the 1st constructor).
> > > 
> > > It seems to me that we perhaps need a different state here for that.
> > I still have this concern, we need to make sure that NestedRequirement is written to consider this type of failure, it likely needs a separate constructor that contains information about the failure.  We probably want at least some sort of stored diagnostic here, sot hat we dont lose the output we have below.
> NestedRequirement will no more capture a substitution failure. I am planning to remove all references to SubstitutionDiagnostics for it. I have **temporarily** added unreachable tags to the references of SubstitutionDiagnostics. 
> 
> If this looks fine to you then I would move forward with refactoring it to remove all support for SubstitutionDiagnostics in NestedRequirement. WDYT ?
Ok, that works for me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138914/new/

https://reviews.llvm.org/D138914



More information about the cfe-commits mailing list