Page MenuHomePhabricator

[Concepts] Type Constraints
Needs ReviewPublic

Authored by saar.raz on Mar 10 2018, 4:13 AM.



Added support for type-constraints in template type parameters. Depends on D43357.

Diff Detail

Event Timeline

saar.raz created this revision.Mar 10 2018, 4:13 AM
saar.raz updated this revision to Diff 138537.Mar 15 2018, 5:32 AM

Fixed test.

saar.raz updated this revision to Diff 147190.May 16 2018, 3:00 PM

Adjusted to changes in dependent patches.

saar.raz updated this revision to Diff 159378.Aug 6 2018, 1:24 PM

Split TryParseConstrainedParameter and ParseConstrainedTemplateParameter in preparation for requries expressions.

Herald added a reviewer: shafik. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: arphaman. · View Herald Transcript
martong requested changes to this revision.Apr 16 2019, 1:23 AM
martong added inline comments.

Please use the import function instead of VisitExpr. Calling VisitExpr would return immediately with an error, that's the default case of the StmtVisitor.
Also please check that there was no error during the import of the CE expression:

ExpectedExpr CEOrErr = import(D->getConstraintExpression());
if (!CEOrErr)
  return CEOrErr.takeError();

And could you please adjust the changes below too?

This revision now requires changes to proceed.Apr 16 2019, 1:23 AM
balazske added inline comments.Apr 16 2019, 3:40 AM

The code above works without the if (Expr *CE = D->getConstraintExpression()) too. The import returns nullptr for a nullptr (*CEOrErr will be nullptr and no error).

saar.raz updated this revision to Diff 195801.Apr 18 2019, 12:32 PM
  • Fixed bad ordering of associated constraints
  • Fixed ignoring of ScopeSpecifier in constrained parameters
  • Adjustments for template template parameter handling
  • Fixed constrained template template parameter and argument handling
rsmith requested changes to this revision.Apr 18 2019, 4:55 PM

This needs revision to reflect changes between the Concepts TS and C++20. In particular, only the name of a type-concept can be used to declare a template-parameter in the new rules:

template<typename> concept A = true;
template<template<typename> typename> B = true;
template<int> concept C = true;

template<A> struct XA {}; // ok
template<B> struct XB {}; // error, not a type-concept
template<C> struct XC {}; // error, not a type-concept

We don't appear to have any explicit representation of the type-concept as written, only of its immediately-declared constraint. One design goal of Clang is for the AST to directly represent the program as written (to the extent possible) to facilitate writing tools on top of Clang's AST. Please consider adding a representation of the TypeConstraint itself. (This could be as simple as a wrapper around the Expr* that you currently have, that provides access to the concept name and the template arguments, and additionally stores a flag to determine whether an explicit template argument list was specified, to distinguish TypeConcept from TypeConcept<>.)


This is out of date compared to the current C++20 wording.


This should not require tentative parsing. We should be able to annotate the nested-name-specifier (if any) then determine whether we have a type-name or a type-constraint with a single token of lookahead.


This is incorrect; this rule was removed when concepts were merged into C++20.


All the work to build expressions and establish the semantic effects of declarations should be done by Sema, not by the Parser. The Parser should just figure out how the program matches the grammar, and report to Sema what it found.

This revision now requires changes to proceed.Apr 18 2019, 4:55 PM
saar.raz updated this revision to Diff 196997.Apr 27 2019, 6:27 PM
saar.raz marked 4 inline comments as done.
  • removed old handling of constrained-parameters for type-constraints
  • use template-id annotations during parsing to avoid tentative parses and set the ground for placeholder type-constraints
  • add source information to the new TypeConstraint class, which shares a base class (ConceptReference) with ConceptSpecializationExpr
  • change TemplateTypeParmDecl to not return true for wasDeclaredWithTypename if a type-constraint was present (and update places that assumed only 'class' or 'typename' were possible)
saar.raz marked 2 inline comments as done.Apr 27 2019, 6:27 PM
saar.raz retitled this revision from [Concepts] Constrained template parameters to [Concepts] Type Constraints.Apr 27 2019, 6:28 PM
saar.raz edited the summary of this revision. (Show Details)
saar.raz updated this revision to Diff 203735.Jun 9 2019, 6:49 AM
  • Fixed bad wereArgumentsSpecified() implementation
saar.raz updated this revision to Diff 204786.Jun 14 2019, 9:18 AM

Adjust to changes in previous patches

saar.raz updated this revision to Diff 204789.Jun 14 2019, 9:26 AM

Fix incorrect patch upload

saar.raz updated this revision to Diff 204844.Jun 14 2019, 2:00 PM

Fix incorrect comparison of type-constraints in template template argument matching

saar.raz updated this revision to Diff 209698.Jul 13 2019, 8:42 AM

Rebase onto trunk.