From @zoffixznet

If 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
* If I combine a Perl 5 module with one of the modules shipped with Rakudo (Test, Pod​::To​::Text), the error is gone
* If I comment out one of the use lines, run the program so it precompiles the module (without error this time), and then uncomment that use line, any further changes to the file (like adding a method) get ignored.

zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$ cat lib/Ticket/Trakr/Tickets.pm6
unit class Ticket​::Trakr​::Tickets;

use DBIish;
use Mojo​::PDF​:from<Perl5>;
zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$ rm -fr lib/.precomp/
zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$ perl6 -Ilib -MTicket​::Trakr​::Tickets -e 'Ticket​::Trakr​::Tickets.new'
Could not find symbol '&Tickets'
  in block <unit> at -e line 1

Actually thrown at​:
  in block <unit> at -e line 1

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/
zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$ cat lib/Ticket/Trakr/Tickets.pm6
unit class Ticket​::Trakr​::Tickets;
use DBIish;
zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$ perl6 -Ilib -MTicket​::Trakr​::Tickets -e 'Ticket​::Trakr​::Tickets.new'
zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$ cat lib/Ticket/Trakr/Tickets.pm6
unit class Ticket​::Trakr​::Tickets;

use DBIish;
use Mojo​::PDF​:from<Perl5>;

method update {
}
zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$ perl6 -Ilib -MTicket​::Trakr​::Tickets -e 'Ticket​::Trakr​::Tickets.new'
zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$ perl6 -Ilib -MTicket​::Trakr​::Tickets -e 'Ticket​::Trakr​::Tickets.new.update'
Method 'update' not found for invocant of class 'Ticket​::Trakr​::Tickets'
  in block <unit> at -e line 1

zoffix@​VirtualBox​:~/CPANPRC/Ticket-Trakr$

From @zoffixznet

A 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 @zoffixznet

I'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 @zoffixznet

Turns 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
no precompilation;
unit class A;
use Pastebin​::Gist;

$ ./perl6-m -Ibug-test -MA -e 'A.new'
===SORRY!=== Error while compiling -e
Undeclared name​:
  A used at line 1

From @zoffixznet

I 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/
bug-test/
├── A.pm6
├── B.pm6
└── C.pm6
0 directories, 3 files
zoffix@​VirtualBox​:~/CPANPRC/rakudo$ cat bug-test/A.pm6
no precompilation;
unit class A;
use B;
zoffix@​VirtualBox​:~/CPANPRC/rakudo$ cat bug-test/B.pm6
unit class B;
use C;
zoffix@​VirtualBox​:~/CPANPRC/rakudo$ cat bug-test/C.pm6
unit class C;
zoffix@​VirtualBox​:~/CPANPRC/rakudo$ rm -fr bug-test/.precomp/; ./perl6-m -Ibug-test -MA -e 'A.new'
===SORRY!=== Error while compiling -e
Undeclared name​:
  A used at line 1

From @niner

Debugged a little more​:
Note only does nqp​::atkey($lexpad, 'GLOBALish') return an NQPMu, nqp​::atkey($lexpad, '$?PACKAGE') and nqp​::atkey($lexpad, '​::?PACKAGE') both return CompUnit​::PrecompilationDependency​::File.

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 @niner

This demonstrates the BEGIN time EVAL's lexicals leaking into the outer compilation unit​:

perl6 -e 'use nqp; say nqp​::atkey(CompUnit​::Loader.load-source(q<package Qux { BEGIN EVAL q<> }; class Foo {};>.encode).unit, q<$?PACKAGE>);'
(Qux)

The output should be (GLOBAL) instead of (Qux)

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

From @niner

Fixed in rakudo commit 027dd390ea74b0dd2cbfcaf88adedf13e4e731fc
Tests in roast commit 6da250f05e1c38585c1162f44a8cca953f84fd55

Thanks for the excellent work on narrowing down this bug!

@niner - Status changed from 'open' to 'resolved'