Don't make signature part of a callable named parameter

[vrurg]

When a named parameter is declared as :&foo:(Int) the name used for
parameter binding was foo:(Int) resulting in falling back to
parameter's default - Callable. A visible effect of this error was
parameter checking to attempt calling signature method on Callable
role.

Resolves #4537

[vrurg]

PR needs one more change. Declarations like :&foo:(Int) cannot be optional because they would fail to match against parameter default Callable. Need to add either a compile-time warning and make the parameter implicitly non-optional, or make it an error.

[vrurg]

I have fixed the case when a signature-constrained named parameter results in signature method called on Callable if a routine is not supplied with corresponding named argument. The fix makes any such parameter required implicitly unless ? is used which is a compile-time error.

There is a couple of notes on feasibility of making signature-constrained parameters optional. The primary problem about them is that the default value (which is Callable) doesn't have a signature method. And even if it would have it (I was playing with making Code the default for signature-constrained parameters); and the method would return some valid signature object (nonsense, but what if?) - even then it is unlikely to match user's constraint.

There are possible workarounds.

The first is to mixin a custom role into the parameter default with a signature method which returns the user's constraint signature.

The second is to add $!signature attribute to the Parameter class. Comes at the cost of extra memory footprint only to take care of rather rarely used feature. A workaround to this, again, is to mixin a role with the attribute. In this case we would need to move argument signature validation code from a post-constraint where block into signature binding. The downside: it's a lot of work for the basically deprecated compiler code facing the replacement with RakuAST.

User-based solution for optional callable parameter within the approach taken by this PR would be :&foo where { .defined && .signature ~~ :(Int) }.

UPD Optional constrained parameters are now implemented.

[vrurg]

There is a bug related to type captures:

sub foo(::T, &bar:(T)) { ... }

The constraining signature is not getting instantiated. Perhaps, instantiating post-constraints list would work as expected. If not then attaching the constraining signature onto the Parameter object would be a better solution.

[vrurg]

This PR is ready for merge. CI JVM failures are there on master, they are not caused by the PR.

Signature constraint information has been relocated from inside a when block in @!post_constraints list to a new attribute $!signature_constraint. Argument's signature is checked explicitly at parameter bind time. This move also allowed me to implement support for generics. So, sub foo(::T, &fn:(T)) {...} and role R[::T] { method foo(&fn:(T)) {...} } are both working now.

Aside of that, it should be possible now to consider the constraining signature in multi-dispatch deliberately, using it to better narrow down the selection of matching candidates. Unfortunately, I'm not sufficiently familiar with multi-dispatch guts to tweak them.

I have not found a reliable way to determine if a named parameter, or an optional positional, was actually passed with a routine call or not. For this reason I deduct the fact of it being missing by comparing parameter variable value to parameter's default type. It would be totally OK with the default &parameter declaration as Callable cannot be used as an argument for signature-constrained parameters. But if a trait changes Parameter $!type to something different this could become a potential problem.

[jnthn]

Aside of this, I think the whole thing is going to be different with RakuAST anyway. It is likely that dispatching will come as part of RakuAST implementation.

So far as RakuAST goes, my expectation is that we'll compile every kind of signature (including unpacks and destructuring), only using the slow-path binder for error reporting.