Routine parameter constrained with a native type, doesn't realize when it gets boxed

[p6rt]

Migrated from rt.perl.org#132052 (status was 'open')

Searchable as RT132052$

[p6rt]

From vittore.scolari@gmail.com

The following script​:

  use NativeCall :types;

  class a {   method new(size_t $size, :$init, :$type) {   my $s = $size;   Blob[size_t].new($s);   }   }

  my $a = a.new(10);

  class b {   method new(size_t $size, :$init, :$type) {   Blob[size_t].new($size);   }   }

  my $b = b.new(12);

dies with error Type check failed in initializing element #​0 to Blob[NativeCall​::Types​::size_t]; expected NativeCall​::Types​::size_t but got Int (12)

[p6rt]

From @smls

It doesn't seem to be specific to type `size_t` - it also happens with other native types such as `int`.

Shorter example​:

  ➜ sub a (int $a) { Blob[int].new($a) }; say a 12;   Type check failed in initializing element #​0 to Blob[int]; expected int but got Int (12)

Examples that *don't* fail​:

  ➜ sub a (int $a is copy) { Blob[int].new($a) }; say a 12;   Blob[int]​:0x\<0c>  
  ➜ sub a (Int $a) { Blob[int].new($a) }; say a 12;   Blob[int]​:0x\<0c>

  ➜ my int $a = 12; say Blob[int].new($a);   Blob[int]​:0x\<0c>

I think it's safe to say that in all four cases, `$a` gets boxed to an `Int`.

But in the first case, it's as if the Blob constructor nonetheless uses the code path for `int` and subsequently gets surprised.

Maybe the `int $a` signature leads the compiler to think that it will always be an `int`?

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[dogbert17]

The above two failures seems to have disappeared:

dogbert@dogbert-VirtualBox ~ $ perl6 -v
This is Rakudo version 2020.05.1-285-g8134470 built on MoarVM version 2020.05-85-g02c8cf7
implementing Raku 6.d.
dogbert@dogbert-VirtualBox ~ $ perl6 -e 'sub a (int $a) { Blob[int].new($a) }; say a 12;'
Blob[int]:0x<0C>

[JJ]

So, closing them?