This was fixed in (2015-12-13)
https://github.com/rakudo/rakudo/commit/3c81e335f3a327e4cacee993d1b5f265dfe3706e

W4anD0eR96++ added tests in https://github.com/perl6/roast/commit/89a96af777

Closing.

On 2015-01-08 12:47:58, jn...@jnthn.net wrote:
> On Thu Dec 18 19:01:29 2014, raiph wrote:
> > See http://irclog.perlgeek.de/perl6/2014-12-19#i_9827480:
> >
> > naddiseo m: enum A <Block>;subset B;
> > camelia rakudo-moar 30edf7: OUTPUT«===SORRY!===␤P6opaque: no such
> > attribute
> > '$!signature'␤»
> > naddiseo Yeah.. what's that about?
> > I know it's something to do with "Block"
> > but that error is very uninformative.
> >
> > raiph m: subset B
> > camelia rakudo-moar 30edf7: ( no output )
> > raiph m: enum A <Block>
> > camelia rakudo-moar 30edf7: ( no output )
> >
> > raiph m: enum A <Code>
> > camelia rakudo-moar 30edf7: OUTPUT«===SORRY!===␤P6opaque: no such
> > attribute
> > '$!signature'␤»
> >
> > Fwiw #123407 gives a similar error.
> >
> Code, Block, etc. are the names of types used to construct code
> objects, and these are currently resolved using normal lexical scoping
> rules. Therefore, hiding them with other symbols that don't uphold the
> expected contract with the compiler is going to lead to things like
> this.
>
> The issue first needs a decision at design level: how should such
> types be located? One option is to only ever look for them in the
> currently effective SETTING, for example.

Reply via email to