From @masak

Rakudo r35994 seems mightly confused about whether to compile a module
containing a bareword that hasn't been declared, and whether to
compile modules that depend on such a module.

$ cat A.pm
use B;
$ cat B.pm
class B does C;
$ $PARROT_DIR/parrot $PARROT_DIR/languages/perl6/perl6.pbc
--target=pir --output=B.pir B.pm
$ $PARROT_DIR/parrot $PARROT_DIR/languages/perl6/perl6.pbc
--target=pir --output=A.pir A.pm
Null PMC access in find_method()
[...]

There are two things wrong with the above. First B.pm shouldn't
compile. Second, A.pm shouldn't compile less often than B.pm does.

Note that running either A.pm or B.pm also produces the same Null PMC
access. Please fix that too.

From @masak

$ cat A.pm
use v6;
use B;

class A does C {
}
$ cat B.pm
use v6;
use C;
$ cat C.pm
use v6;

role C {
}
$ perl6 A.pm # works

I've encountered cases where this fails during PIR compilation, but I
am unable to reproduce them right now. AFAIU, it should fail always.

From @masak

masak (>)​:

$ cat A.pm
use v6;
use B;

class A does C {
}
$ cat B.pm
use v6;
use C;
$ cat C.pm
use v6;

role C {
}
$ perl6 A.pm # works

I've encountered cases where this fails during PIR compilation, but I
am unable to reproduce them right now. AFAIU, it should fail always.

This bug is, as jnthn++ pointed out over IRC, largely bogus. An
indirectly declared C should be visible in A, so the above code should
never fail, not always as I claimed.

The failure during PIR compilation turned out to be due to an undeclared
identifier 'B'.

$ cat A.pm
use v6;

class A {
  has B $!b;
}
$ cat A/B.pm
use v6;
use A;

class A​::B is A {
}
$ perl6 --target=pir --output=A.pir A.pm
$ perl6 --target=pir --output=A/B.pir A/B.pm
Lexical 'self' not found
[...]

But that makes this bug a variant of #​67268. Marking it as such.

@masak - Status changed from 'new' to 'open'

From @masak

masak (>)​:

But that makes this bug a variant of #​67268

Oops, mean #​62768, of course.

@masak - Status changed from 'new' to 'open'

From @jnthn

On Fri Jan 30 01​:29​:38 2009, masak wrote​:

The failure during PIR compilation turned out to be due to an undeclared
identifier 'B'.

$ cat A.pm
use v6;

class A {
has B $!b;
}
$ cat A/B.pm
use v6;
use A;

class A​::B is A {
}
$ perl6 --target=pir --output=A.pir A.pm
$ perl6 --target=pir --output=A/B.pir A/B.pm
Lexical 'self' not found
[...]

But that makes this bug a variant of #​67268. Marking it as such.

Actually you don't need anything fancy to re-produce this, just​:

class A { has B $.x }

In the REPL does it.

Jonathan

From @jnthn

On Wed Feb 11 05​:15​:12 2009, jnthn@​jnthn.net wrote​:

On Fri Jan 30 01​:29​:38 2009, masak wrote​:

The failure during PIR compilation turned out to be due to an undeclared
identifier 'B'.

$ cat A.pm
use v6;

class A {
has B $!b;
}
$ cat A/B.pm
use v6;
use A;

class A​::B is A {
}
$ perl6 --target=pir --output=A.pir A.pm
$ perl6 --target=pir --output=A/B.pir A/B.pm
Lexical 'self' not found
[...]

But that makes this bug a variant of #​67268. Marking it as such.

Actually you don't need anything fancy to re-produce this, just​:

class A { has B $.x }

In the REPL does it.

And that now reports a "Malformed declaration" at compile time,
following STD.pm's lead (though we can't say it's a my or has
declaration yet, but I've put in a comment noting the difference).

So, fixed in git fba805c.

Thanks,

Jonathan

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