New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combination of Perl 6 and Perl 6 modules in a class fails #5393
Comments
From @zoffixznetIf a Perl 6 module and a Perl 5 module are used in the same class, using that class fails. Here's some tests done: * I tried several Perl 6 and Perl 5 modules and the effect is the same zoffix@VirtualBox:~/CPANPRC/Ticket-Trakr$ cat lib/Ticket/Trakr/Tickets.pm6 use DBIish; Actually thrown at: zoffix@VirtualBox:~/CPANPRC/Ticket-Trakr$ Notice how adding the Perl 5 module after precompiling with just one `use` no longer triggers the error, but the added `update` method isn't there either: zoffix@VirtualBox:~/CPANPRC/Ticket-Trakr$ rm -fr lib/.precomp/ use DBIish; method update { zoffix@VirtualBox:~/CPANPRC/Ticket-Trakr$ |
From @zoffixznetA small update: I was able to reproduce the bug on three different boxes and I found that it's NOT present in 2016.04 release but *is* present in the 2015.05 release. |
From @zoffixznetI've bisected and found this commit introduced the bug: rakudo/rakudo@bf59085 Further to previous symptoms, it's not just loading a Perl 6 module that causes an issue, but one that was installed with zef or panda (i.e. not one you coded yourself and added via -Ilib or whatever--those work fine) |
From @zoffixznetTurns out a Perl 5 module isn't even needed for this bug, it just uncovers it. It just needs a module with deps to be used by a module one's `use`ing and precompilation hides the issue. With `no precomipilation` the bug appears even without a Perl 5 module: $ cat bug-test/A.pm6 $ ./perl6-m -Ibug-test -MA -e 'A.new' |
From @zoffixznetI spent an exorbitant amount of time trying to debug this, but unfortunately I still failed. Here's how far I got. It feels like the fix is around the corner, so maybe it'd be obvious for someone familiar with the code. Here's the simplest way to reproduce the bug. Have a chain of three modules, A, B, and C. Our script uses A, A uses B, and B uses C. A has "no precompilation" pragma. Try to run the script, you get the "Undeclared name A" error. Any other combination of 'no precompilation' and its absence in the three modules does NOT produce the error. The original bug I described was introduced by this commit rakudo/rakudo@bf59085 and I'm pretty sure the bug reproduced by instructions above is the same bug. I traced the issue to this line in CompUnit::Handle::globalish-package() https://github.com/rakudo/rakudo/blob/23daf3bb448b9278499162b4c7c4ebb964fbcd36/src/core/CompUnit/Handle.pm#L63 When the issue occurs, it returns NQPMu instead of a null or GLOBAL. I've no idea why or how to fix that. Here's the code that reproduces the bug, note that it's important to delete precomp files on each run: zoffix@VirtualBox:~/CPANPRC/rakudo$ tree bug-test/ |
From @ninerDebugged a little more: I have a hunch that this is a remaining issue of BEGIN time EVALs and indeed, replacing the EVAL in CompUnit::PrecompilationUnit by psch++'s jvm workaround fixes the issue. |
From @ninerThis demonstrates the BEGIN time EVAL's lexicals leaking into the outer compilation unit:
The output should be (GLOBAL) instead of (Qux) |
The RT System itself - Status changed from 'new' to 'open' |
From @ninerFixed in rakudo commit 027dd390ea74b0dd2cbfcaf88adedf13e4e731fc Thanks for the excellent work on narrowing down this bug! |
@niner - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#128457 (status was 'resolved')
Searchable as RT128457$
The text was updated successfully, but these errors were encountered: