Skip Menu |
Report information
Id: 128287
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: pochi <autark [at] gmail.com>
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Date: Sun, 29 May 2016 17:50:21 +0200
From: David Ranvig <autark [...] gmail.com>
Subject: [BUG] Correctly typed function gives rise to type check failure under certain circumstances
To: rakudobug [...] perl.org
Download (untitled) / with headers
text/plain 602b
The bug can be reproduced with the following code spread over 3 files: main.pl6 ------------ use Zot; zot(); Zot.pm6 ----------- use XXX; sub zot() returns Array of Numeric is export { my Numeric @a; return @a; } XXX.pm6 ------------- my Numeric @x; When main.pl6 is run, the following error is reported: Type check failed for return value; expected Array[Numeric] but got Array[Numeric].new() in sub zot at ./Zot.pm6 (Zot) line 5 in block <unit> at main.pl6 line 2 $ perl6 --version This is Rakudo version 2016.05-6-g2c45068 built on MoarVM version 2016.05 implementing Perl 6.c.
Download (untitled) / with headers
text/plain 906b
Confirmed. I tried to golf it down further, but this is the best I could do: $ echo 'say Array[Int];' > B.pm $ echo 'use B; my Array[Int] $x = Array[Int].new;' > A.pm $ perl6 -I. -e 'use A;' Which prints: (Array[Int]) (Array[Int]) ===SORRY!=== Type check failed in assignment to $x; expected Array[Int] but got Array[Int].new() (Note: Beside the type check failure, another curious thing is that the `say` is executed twice.) The specific constellation needed to cause the issue, appears to be this: 1) The mainline uses a module module, which performs a type check involving a parameterized type. 2) That module in turn uses another module, which instantiates that same parameterized type. It's as if we end up with two "instances" of the same parameterized type, and the type check gets confused about which one to check against.
Download (untitled) / with headers
text/plain 168b
UPDATE: It seems to be a precomp issue. If precomp is disabled for B.pm, then the bug does not appear: $ echo 'no precompilation; say Array[Int];' > B.pm
Download (untitled) / with headers
text/plain 1.3k
On Sun, 29 May 2016 10:28:43 -0700, smls75@gmail.com wrote: Show quoted text
> It's as if we end up with two "instances" of the same parameterized > type, and the type check gets confused about which one to check > against.
If I'm understanding the code correctly, it looks like that's what's happening. The error is coming from type_check_store() in container.c, and when I modified it to print the name and location of rcd->of and obj, the names were both Array[Int], but the memory locations were different. You can confirm that by changing the test case (and get rid of the exception for now): A.pm: use B; say "A: "~Array[Int].WHICH; say "A (instance.WHAT): "~Array[Int].new.WHAT.WHICH; B.pm: say "B: "~Array[Int].WHICH; say "B (instance.WHAT): "~Array[Int].new.WHAT.WHICH; Then execute as before: perl6 -I. -e 'use A;' If you ignore precomp, the output is: B: Array[Int]|U132044096 B (instance.WHAT): Array[Int]|U132044096 A: Array[Int]|U132044648 A (instance.WHAT): Array[Int]|U132044096 So in the context of A.pm, Array[Int].new is being associated with the correct type representation in memory, but (undefined) Array[Int] is not. (By the way, I checked .HOW as well and found that that is not having an extra instance created.) So where are the type objects being created and failing to match with existing type objects? Is this type_object_for() in VMArray.c?
Download (untitled) / with headers
text/plain 169b
Also, if you print the .WHICH values during BEGIN, you'll find that they're consistent, so the problem occurs either when compiling A.pm or reading the precompiled data.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org