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.