Bug #131559 for Type-Tiny: compilation error for function signatures with Moose enum TypeConstraints

Fri Jan 24 21:48:39 2020 SHERRARDB [...] cpan.org - Ticket created

Subject:

compilation error for function signatures with Moose enum TypeConstraints

~$ perl -e '{ package My::Shapes; BEGIN { use Moose::Util::TypeConstraints qw( enum ); enum 'ColorEnum' => [ qw( white black brown ) ]; } use strict; use warnings; use Moose; use Kavorka qw( fun ); fun print_color(ColorEnum :$color!) { print "$color\n"; } has "color" => ( is=> "ro", isa=> "ColorEnum" ); }' Global symbol "%enums0" requires explicit package name at -e line 1. Execution of -e aborted due to compilation errors. vs sburton@d01:~/kavorka-test$ perl -e '{ package My::Shapes; BEGIN { use Moose::Util::TypeConstraints qw( enum ); enum 'ColorEnum' => [ qw( white black brown ) ]; } use strict; use warnings; use Moose; use Kavorka qw( fun ); fun print_color(Str :$color!) { print "$color\n"; } has "color" => ( is=> "ro", isa=> "ColorEnum" ); }' the issue seems to be that the inline_environment that is necessary to initialize %enums0 is not drawn into the code being inlined in Type::Tiny { 'Type::Tiny->inlined' => '( do { defined($color) && !ref($color) && $enums0{$color} } )' } at p5-type-tiny/lib/Type/Tiny.pm line 868. Type::Tiny::inline_assert(Type::Tiny=HASH(0x442ee30), "\$color") called at /usr/local/share/perl/5.20.2/Kavorka/Parameter.pm line 612 Kavorka::Parameter::_injection_type_check(Kavorka::Parameter=HASH(0x4207ea0), "\$color") called at /usr/local/share/perl/5.20.2/Kavorka/Parameter.pm line 379 Kavorka::Parameter::_injection_conditional_type_check(Kavorka::Parameter=HASH(0x4207ea0), Kavorka::Signature=HASH(0x3366b30), "exists(\$_{\"color\"})", "\$color") called at /usr/local/share/perl/5.20.2/Kavorka/Parameter.pm line 349 Kavorka::Parameter::injection(Kavorka::Parameter=HASH(0x4207ea0), Kavorka::Signature=HASH(0x3366b30)) called at /usr/local/share/perl/5.20.2/Kavorka/Signature.pm line 346 Kavorka::Signature::_injection_named_params(Kavorka::Signature=HASH(0x3366b30)) called at /usr/local/share/perl/5.20.2/Kavorka/Signature.pm line 202 Kavorka::Signature::injection(Kavorka::Signature=HASH(0x3366b30)) called at /usr/local/share/perl/5.20.2/Kavorka/Sub.pm line 96 Kavorka::Sub::inject_prelude(Kavorka::Sub::Fun=HASH(0x31ea148)) called at /usr/local/share/perl/5.20.2/Kavorka/Sub.pm line 369 Kavorka::Sub::parse_body(Kavorka::Sub::Fun=HASH(0x31ea148)) called at /usr/local/share/perl/5.20.2/Kavorka/Sub.pm line 154 Kavorka::Sub::parse("Kavorka::Sub::Fun", "keyword", "fun") called at /usr/local/share/perl/5.20.2/Kavorka.pm line 187 Kavorka::parse_fun("fun") called at -e line 1 i hope i have provided enough context and detail. if not, let me know. TIA

Sat Jan 25 04:36:03 2020 perl [...] toby.ink - Correspondence added

Yeah, I think I know how to fix it. Kavorka converts Moose type constraints to Type::Tiny type constraints using Types::TypeTiny. Type::Tiny type constraints never have any inline_environment (it is always {}). So a Moose type that has a non-empty inline_environment ought to be considered not inlineable to Type::Tiny. Around line 275 of Types::TypeTiny is where it makes the decision of whether to consider the imported Moose type as inlineable. It should be checking for the existence of a non-empty inline_environment here.

Sat Jan 25 04:36:03 2020 The RT System itself - Status changed from 'new' to 'open'

Sat Jan 25 04:36:03 2020 perl [...] toby.ink - Taken

Sat Jan 25 09:02:06 2020 SHERRARDB [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #131559] compilation error for function signatures with Moose enum TypeConstraints
Date:	Sat, 25 Jan 2020 08:55:04 -0500
To:	bug-Type-Tiny [...] rt.cpan.org
From:	sherrardb <sherrardb [...] cpan.org>

On 1/25/20 4:36 AM, Toby Inkster via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=131559 > > > Yeah, I think I know how to fix it. > > Kavorka converts Moose type constraints to Type::Tiny type constraints using Types::TypeTiny. Type::Tiny type constraints never have any inline_environment (it is always {}). So a Moose type that has a non-empty inline_environment ought to be considered not inlineable to Type::Tiny. > > Around line 275 of Types::TypeTiny is where it makes the decision of whether to consider the imported Moose type as inlineable. It should be checking for the existence of a non-empty inline_environment here. >

you mean here? :-) diff --git a/lib/Types/TypeTiny.pm b/lib/Types/TypeTiny.pm index fc8273b5..888dd248 100644 --- a/lib/Types/TypeTiny.pm +++ b/lib/Types/TypeTiny.pm @@ -272,7 +272,19 @@ sub _TypeTinyFromMoose $opts{display_name} = $t->name; $opts{constraint} = $t->constraint; $opts{parent} = to_TypeTiny($t->parent) if $t->has_parent; - $opts{inlined} = sub { shift; $t->_inline_check(@_) } if $t->can("can_be_inlined") && $t->can_be_inlined; + $opts{inlined} = sub { + shift; + my @inline_checks = $t->_inline_check(@_); + if ( ref( $t->_inline_environment ) eq 'HASH' ) { + foreach my $param ( reverse( sort( keys( %{$t->_inline_environment} ) ) ) ) { + foreach my $check ( @inline_checks ) { + require Data::Dumper; + $check = sprintf "my %s = %%{%s}; %s", $param, Data::Dumper->new( [ $t->_inline_environment->{$param} ] )->Terse( 1 )->Indent( 0 )->Sortkeys( 1 )->Dump(), $check; + } + } + } + return @inline_checks; + } if $t->can("can_be_inlined") && $t->can_be_inlined; $opts{message} = sub { $t->get_message($_) } if $t->has_message; $opts{moose_type} = $t; i didn't include this in the bug report because i thought of it as a horrible hack, and more of a proof of concept. i also figured that it probably was not the right place to implement the fix. my assumption, from poking around in the internals of Moose and Type::Tiny is that the proper solution would involve eval_closure(), rather than manual string injection of variable.

Sun Jan 26 05:18:22 2020 perl [...] toby.ink - Correspondence added

Injecting the dump would work for this particular case, but not in the general case, because if you're closing over a hash %foo, the expectation is that if $foo{'bar'} later gets changed, any code that closed over %foo will be able to see the new value. That won't happen if you dump %foo out and inline a copy of it. Type::Tiny's general solution to that is the cowardly one - just to say "this type cannot be inlined at all". That is, it should be returning false from the can_be_inlined method. So I'll probably do that to start with, but long term, a better solution would be if to_TypeTiny recognized certain specific Moose::Meta::TypeConstraint subclasses (like Enum, Class, Role), and instead of making a Type::Tiny object, made a Type::Tiny::Enum, Type::Tiny::Class, or Type::Tiny::Role object as appropriate. (Maybe also do the same for ::Union.) Type::Tiny::Enum, Type::Tiny::Class, and Type::Tiny::Role are all always inlineable.

Sun Jan 26 07:08:03 2020 SHERRARDB [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #131559] compilation error for function signatures with Moose enum TypeConstraints
Date:	Sun, 26 Jan 2020 07:07:38 -0500
To:	bug-Type-Tiny [...] rt.cpan.org
From:	sherrardb <sherrardb [...] cpan.org>

what are the implications of not being inlineable? does that mean that we simply bypass some compile-time code, or that Kavorka cannot recognize that particular Moose constraint at all? i am currently using regexes as stand-ins, but obviously the enum is much more concise. beside switching that particular type constraint fully over to Type::Tiny, is there some manipulation/preparation that i can do to the Moose constraint (keeping it as an enum) outside of the Type::Tiny core to make it consumable/inlineable? On 1/26/20 5:18 AM, Toby Inkster via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=131559 > > > Injecting the dump would work for this particular case, but not in the general case, because if you're closing over a hash %foo, the expectation is that if $foo{'bar'} later gets changed, any code that closed over %foo will be able to see the new value. That won't happen if you dump %foo out and inline a copy of it. > > Type::Tiny's general solution to that is the cowardly one - just to say "this type cannot be inlined at all". That is, it should be returning false from the can_be_inlined method. > > So I'll probably do that to start with, but long term, a better solution would be if to_TypeTiny recognized certain specific Moose::Meta::TypeConstraint subclasses (like Enum, Class, Role), and instead of making a Type::Tiny object, made a Type::Tiny::Enum, Type::Tiny::Class, or Type::Tiny::Role object as appropriate. (Maybe also do the same for ::Union.) > > Type::Tiny::Enum, Type::Tiny::Class, and Type::Tiny::Role are all always inlineable. >

Mon Jan 27 03:13:32 2020 perl [...] toby.ink - Correspondence added

Kavorka is able to use non-inlineable types fine. It just calls $type->assert_valid($value) on the type whenever it needs to check the value. This won't be as fast as an inline check because it needs to do a method call, but it will still work.

Wed Jan 29 07:16:39 2020 perl [...] toby.ink - Correspondence added

https://metacpan.org/release/TOBYINK/Type-Tiny-1.008004 Can you verify that it works okay once 1.008004 is installed?

Wed Jan 29 09:55:46 2020 SHERRARDB [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #131559] compilation error for function signatures with Moose enum TypeConstraints
Date:	Wed, 29 Jan 2020 09:55:16 -0500
To:	bug-Type-Tiny [...] rt.cpan.org
From:	sherrardb <sherrardb [...] cpan.org>

On 1/29/20 7:16 AM, Toby Inkster via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=131559 > > > https://metacpan.org/release/TOBYINK/Type-Tiny-1.008004 > > Can you verify that it works okay once 1.008004 is installed? >

it sure seems to work in the test context. ~$ perl -e '{ package My::Shapes; BEGIN { use Moose::Util::TypeConstraints qw( enum ); enum 'ColorEnum' => [ qw( white black brown ) ]; } use strict; use warnings; use Moose; use Kavorka qw( fun ); fun print_color(ColorEnum :$color!) { print "$color\n"; } } My::Shapes::print_color( color=> "pink" );' Value "pink" did not pass type constraint "ColorEnum" at -e line 1 Value "pink" did not pass type constraint "ColorEnum" "ColorEnum" is defined as: sub { package Moose::Meta::TypeConstraint::Enum; exists $values{$_[0]}; } ~$ perl -e '{ package My::Shapes; BEGIN { use Moose::Util::TypeConstraints qw( enum ); enum 'ColorEnum' => [ qw( white black brown ) ]; } use strict; use warnings; use Moose; use Kavorka qw( fun ); fun print_color(ColorEnum :$color!) { print "$color\n"; } } My::Shapes::print_color( color=> "black" );' black i hope to test this in my actual use case later, but don't expect the results to be any different. thank you for addressing this so quickly.

Wed Jan 29 11:45:02 2020 perl [...] toby.ink - Correspondence added

No problem. I will at some point get around to the stuff to make Moose::Meta::TypeConstraint::Enum objects into Type::Tiny::Enum objects (which are always inlineable) instead of generic Type::Tiny objects (which are in this case not inlineable), and the same with Class/Role/Union, but that's probably a big enough change to warrant bumping the version to 1.010.

Wed Jan 29 11:45:03 2020 perl [...] toby.ink - Status changed from 'open' to 'resolved'

Tue Feb 04 06:36:33 2020 perl [...] toby.ink - Correspondence added

Branch for improved handling of Moose::Meta::TypeConstraint::{Enum,Class,Role,DuckType,Union} https://github.com/tobyink/p5-type-tiny/compare/feature/better-moose-import

Tue Feb 04 09:27:16 2020 sburton [...] allafrica.com - Correspondence added

Subject:	Re: [rt.cpan.org #131559] compilation error for function signatures with Moose enum TypeConstraints
Date:	Tue, 4 Feb 2020 09:20:27 -0500
To:	bug-Type-Tiny [...] rt.cpan.org, SHERRARDB [...] cpan.org
From:	Sherrard Burton <sburton [...] allafrica.com>

ACK. will try to put it through the ringer soon. thanks On 2/4/20 6:36 AM, Toby Inkster via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=131559 > > > Branch for improved handling of Moose::Meta::TypeConstraint::{Enum,Class,Role,DuckType,Union} > > https://github.com/tobyink/p5-type-tiny/compare/feature/better-moose-import >

Fri Feb 07 09:54:02 2020 SHERRARDB [...] cpan.org - Correspondence added

On Tue Feb 04 09:27:16 2020, sburton@allafrica.com wrote: Show quoted text

> ACK. > > will try to put it through the ringer soon. > > thanks

very nice! especially the detailed message ~$ perl -I./p5-type-tiny/lib -Mstrict -e '{ package My::Shapes; BEGIN { use Moose::Util::TypeConstraints qw( enum ); enum 'ColorEnum' => [ qw( white black brown ) ]; } use strict; use warnings; use Moose; use Kavorka qw( fun ); fun print_color(ColorEnum :$color!) { print "$color\n"; } } My::Shapes::print_color( color=> "pink" );' Value "pink" did not pass type constraint "ColorEnum" at -e line 1 "ColorEnum" requires that the value is equal to "black", "brown", or "white" Show quoted text

> > On 2/4/20 6:36 AM, Toby Inkster via RT wrote:

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=131559 > > > > > Branch for improved handling of > > Moose::Meta::TypeConstraint::{Enum,Class,Role,DuckType,Union} > > > > https://github.com/tobyink/p5-type-tiny/compare/feature/better-moose- > > import > >

Fri Feb 07 17:15:30 2020 perl [...] toby.ink - Correspondence added

Better error messages were an unplanned bonus. :) I'll get 1.010 released fairly soon probably. I can't think of many more changes that should get done first.