[c++-concepts] Check function concept definitions

This fixes an ICE trying to normalize a function concept with multiple
statements. That error will now be diagnosed at the point of
definition.

Jason, do you want to review this before I commit? This is a pretty small patch.

2014-09-01  Andrew Sutton  <andrew.n.sutton@gmail.com>

        Check requirements on function concept definitions.
        * gcc/cp/decl.c (finish_function): Check properties of a function
        concept definition.
        * gcc/cp/constraint.cc (check_function_concept): New. Check
        for deduced return type and multiple statements.
        (normalize_misc): Don't normalize multiple statements.
        (normalize_stmt_list): Removed.
        * gcc/cp/cp-tree.h (check_function_concept): New.
        * gcc/testsuite/g++.dg/concepts/fn-concept1.C: New.

Andrew

On 09/29/2014 10:55 AM, Andrew Sutton wrote:
> Jason, do you want to review this before I commit? This is a pretty small patch.

No need to wait for review before committing to the branch.

> +  // If fn was declared with auto, make sure the result type is bool.
> +  if (FNDECL_USED_AUTO (fn) && TREE_TYPE (fn) != boolean_type_node)
> +    error_at (loc, "deduced type of concept definition %qD is not %qT",
> +              fn, boolean_type_node);

This should say what the deduced type is.

> +  // Check that the function is comprised of only a single
> +  // return statements.

*statement

> +template<typename T>
> +  concept bool Tuple() { // { dg-error "multiple statements" }
> +    static_assert(T::value, "");
> +    return true;
> +  }

Hmm, have we actually discussed this in core review?  I'm not seeing it 
on the wiki.  Constexpr started out this way too, and allowing 
static_assert was added pretty fast.  C++11 said

its function-body shall be = delete, = default, or a compound-statement 
that contains only
— null statements,
— static_assert-declarations
— typedef declarations and alias-declarations that do not define classes 
or enumerations,
— using-declarations,
— using-directives,
— and exactly one return statement;

Is there a reason we want to be more strict than this for concept functions?

Jason

> Hmm, have we actually discussed this in core review?  I'm not seeing it on
> the wiki.  Constexpr started out this way too, and allowing static_assert
> was added pretty fast.  C++11 said
>
> its function-body shall be = delete, = default, or a compound-statement that
> contains only
> — null statements,
> — static_assert-declarations
> — typedef declarations and alias-declarations that do not define classes or
> enumerations,
> — using-declarations,
> — using-directives,
> — and exactly one return statement;
>
> Is there a reason we want to be more strict than this for concept functions?


I don't remember much controversy on that particular limitation in
either Rapperswil or the previous telecon review.

The main reason for the restriction is that concept definitions are
normalized into a single constraint-expression. And it's not obvious
how things like using declarations and static-assertions should be
interpreted within the constraint language.

That said, having a static_assert inside a concept kind of defeats the
purpose since it triggers a diagnostic when its condition isn't
satisfied. That's not very SFINAE friendly :)

Maybe the restriction can relaxed when we consider the TS for adoption in 17.

Andrew

On 09/29/2014 11:46 AM, Andrew Sutton wrote:
> The main reason for the restriction is that concept definitions are
> normalized into a single constraint-expression. And it's not obvious
> how things like using declarations and static-assertions should be
> interpreted within the constraint language.

A using-declaration just affects name lookup.  They and typedefs/aliases 
can help to make the return statement easier to write.

> That said, having a static_assert inside a concept kind of defeats the
> purpose since it triggers a diagnostic when its condition isn't
> satisfied. That's not very SFINAE friendly :)

True. It might still be useful if for some reason testing a concept for 
a certain class of types indicates an error somewhere else.  And people 
are likely to try it, as indicated by the bug report.  :)

> Maybe the restriction can relaxed when we consider the TS for adoption in 17.

I suppose, but I'd prefer not to wait that long.  I guess we can talk 
about it on the call today.

Jason

On 2014-09-29 18:32, Jason Merrill wrote:
> On 09/29/2014 11:46 AM, Andrew Sutton wrote:
>> The main reason for the restriction is that concept definitions are
>> normalized into a single constraint-expression. And it's not obvious
>> how things like using declarations and static-assertions should be
>> interpreted within the constraint language.
>
> A using-declaration just affects name lookup.  They and
> typedefs/aliases can help to make the return statement easier to write.
>
>> That said, having a static_assert inside a concept kind of defeats the
>> purpose since it triggers a diagnostic when its condition isn't
>> satisfied. That's not very SFINAE friendly :)
>
> True. It might still be useful if for some reason testing a concept
> for a certain class of types indicates an error somewhere else.  And
> people are likely to try it, as indicated by the bug report.  :)
>
>> Maybe the restriction can relaxed when we consider the TS for
>> adoption in 17.
>
> I suppose, but I'd prefer not to wait that long.  I guess we can talk
> about it on the call today.
>
> Jason
>
Since I sent that sample code with the static_assert inside the concept,
let me add that I wanted to test something completely different and
stumbled over that internal error by accident :-)

That being said, I had expected the same rules for concepts as for
constexpr functions indeed. It seemed quite natural (and would require
less RAM in my brain).

Best,

Roland