From @masak

<masak> the latest spec change says 'break' outside of a topicalizer
block is a compile-time error.
<masak> rakudo​: break
<p6eval> rakudo 8566a6​: OUTPUT«␤»
* masak submits rakudobug

From @pmichaud

On Sat Sep 05 07​:26​:07 2009, masak wrote​:

<masak> the latest spec change says 'break' outside of a topicalizer
block is a compile-time error.
<masak> rakudo​: break
<p6eval> rakudo 8566a6​: OUTPUT«␤»
* masak submits rakudobug

Does this imply (as I guess it must) that we explicitly check in the
compiler for the use of "break" as a subroutine name and whenever it's
found we perform a compile-time check to ensure we're in a topicalizer
block?

It's okay if the answer is "yes" -- just wanting to make sure this is
the intended implementation/behavior .

Pm

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

From @masak

<masak> anyone else get this? I'm just loading a class through a
module, calling a method on it. Null PMC access.
http://gist.github.com/436120

$ cat A.pm
use v6;

class A {
  method x {
  }
}

$ perl6 -e 'use A; say A.new.x'
Null PMC access in type()
  in main program body at line 1

<masak> it feels strange that something like this would go unnoticed
for very long. maybe my local build is corrupted somehow.
* moritz_ gets the same
* masak submits rakudobug
<PerlJam> rakudo​: class A { method x {} }; say A.new.x
<p6eval> rakudo ae1300​: OUTPUT«Null PMC access in type() [...]
<PerlJam> rakudo​: class A { method x {return} }; say A.new.x
<p6eval> rakudo ae1300​: OUTPUT«␤»
<masak> those two are distinct.
<masak> oh wait. no.
<masak> PerlJam++'s is an easier case of mine.
<jnthn> It's probably the same old "null return" thing.
<colomon> rakudo​: class A { method x { 1; } }; say A.new.x
<PerlJam> seems so.
<p6eval> rakudo ae1300​: OUTPUT«1␤»
<PerlJam> rakudo​: class A { method x { ; } }; say A.new.x
<p6eval> rakudo ae1300​: OUTPUT«Null PMC access in type() [...]
<masak> rakudo​: sub x {}; say x
<p6eval> rakudo ae1300​: OUTPUT«Null PMC access in type() [...]
<masak> rakudo​: say {;}()
<p6eval> rakudo ae1300​: OUTPUT«Null PMC access in type() [...]
<masak> golf :)

From @masak

<masak> rakudo​: sub foo() { succeed }; say foo
<p6eval> rakudo 197b4b​: OUTPUT« at line 1␤Null PMC access in type() [...]
* masak submits rakudobug
* jnthn figures that's probably similarish to the one submitted yesterday
<masak> probably.
<masak> rakudo​: sub foo() { succeed; succeed; succeed }; say foo
<p6eval> rakudo 197b4b​: OUTPUT« at line 1␤ at line 1␤ at line 1␤Null PMC access in type() [...]
<masak> ok, yes, it's the same.
<masak> I'll put it as a comment to that one, then.
<jnthn> yeah, good to collect various cases.

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

From @pmichaud

The empty statement bug is resolved in 05684c07. The 'succeed' bug
looks like it will require a bit more work.

Pm

From @bbkr

in * release

[18​:16] <bbkr> rakudo​: break
[18​:16] <p6eval> rakudo efe72c​: OUTPUT«Could not find sub &break␤ in
main program body at line 22​:/tmp/3991IK9D0k␤»

[18​:18] <bbkr> std​: break
[18​:18] <p6eval> std 31897​:
OUTPUT«�[31m===�[0mSORRY!�[31m===�[0m␤Undeclared routine​:␤ 'break'
used at line 1␤Check failed␤FAILED 00​:01 114m␤»

taken for tests

From @masak

On Tue Aug 03 09​:18​:48 2010, bbkr wrote​:

in * release

[18​:16] <bbkr> rakudo​: break
[18​:16] <p6eval> rakudo efe72c​: OUTPUT«Could not find sub &break␤ in
main program body at line 22​:/tmp/3991IK9D0k␤»

[18​:18] <bbkr> std​: break
[18​:18] <p6eval> std 31897​:
OUTPUT«�[31m===�[0mSORRY!�[31m===�[0m␤Undeclared routine​:␤ 'break'
used at line 1␤Check failed␤FAILED 00​:01 114m␤»

taken for tests

No, don't take this for tests​:

(1) 'break' is now 'succeed'.
(2) The above error message only indicates (1), not that the feature requested by the ticket has
been implemented. See the original posting in this ticket.

From @bbkr

I didn't know break changed it's name, looked like it was removed from spec.

In this case ticket remains open and I'm assigning back to Nobody.

From @coke

On Sun Jun 27 23​:27​:38 2010, pmichaud wrote​:

The empty statement bug is resolved in 05684c07. The 'succeed' bug
looks like it will require a bit more work.

Pm

The former outputs Nil, the latter is now​:

00​:38 < [Coke]> rakudo​: sub foo() { succeed }; say foo
00​:38 <+p6eval> rakudo cbdd9b​: OUTPUT«Warning␤0␤»

--
Will "Coke" Coleda

From @coke

On Sat Aug 07 13​:30​:25 2010, masak wrote​:

On Tue Aug 03 09​:18​:48 2010, bbkr wrote​:

in * release

[18​:16] <bbkr> rakudo​: break
[18​:16] <p6eval> rakudo efe72c​: OUTPUT«Could not find sub &break␤
in
main program body at line 22​:/tmp/3991IK9D0k␤»

[18​:18] <bbkr> std​: break
[18​:18] <p6eval> std 31897​:
OUTPUT«�[31m===�[0mSORRY!�[31m===�[0m␤Undeclared routine​:␤
'break'
used at line 1␤Check failed␤FAILED 00​:01 114m␤»

taken for tests

No, don't take this for tests​:

(1) 'break' is now 'succeed'.
(2) The above error message only indicates (1), not that the feature
requested by the ticket has
been implemented. See the original posting in this ticket.

complains now​:
10​:51 < [Coke]> rakudo​: succeed
10​:51 <+p6eval> rakudo 38165a​: OUTPUT«succeed without when clause␤ in
block
  <anon> at /tmp/bkp6JWCw3l​:1␤ in <anon> at
/tmp/bkp6JWCw3l​:1␤»

Closable with tests.

--
Will "Coke" Coleda

From @diakopter

On Mon Sep 19 21​:40​:13 2011, coke wrote​:

On Sun Jun 27 23​:27​:38 2010, pmichaud wrote​:

The empty statement bug is resolved in 05684c07. The 'succeed' bug
looks like it will require a bit more work.

Pm

The former outputs Nil, the latter is now​:

00​:38 < [Coke]> rakudo​: sub foo() { succeed }; say foo
00​:38 <+p6eval> rakudo cbdd9b​: OUTPUT«Warning␤0␤»

The latter is now​: marking testneeded for both reported issues.

14​:35 <diakopter> rakudo​: sub foo() { succeed; succeed; succeed }; say
foo
14​:35 <p6eval> rakudo 223419​: OUTPUT«succeed without when clause␤ in
block <anon> at
  src/gen/CORE.setting​:327␤ in block <anon> at
src/gen/CORE.setting​:404␤ in
  sub foo at /tmp/zS6j4hX0ny​:1␤ in block <anon> at
/tmp/zS6j4hX0ny​:1␤␤»

From @diakopter

On Wed Jan 11 07​:51​:44 2012, coke wrote​:

Closable with tests.

Whoever writes/finds tests for this​: there is another open ticket that
mentions succeed and is also marked testneeded.

From @diakopter

On Tue May 29 12​:36​:59 2012, diakopter wrote​:

On Mon Sep 19 21​:40​:13 2011, coke wrote​:

On Sun Jun 27 23​:27​:38 2010, pmichaud wrote​:

The empty statement bug is resolved in 05684c07. The 'succeed'
bug
looks like it will require a bit more work.

Pm

The former outputs Nil, the latter is now​:

00​:38 < [Coke]> rakudo​: sub foo() { succeed }; say foo
00​:38 <+p6eval> rakudo cbdd9b​: OUTPUT«Warning␤0␤»

The latter is now​: marking testneeded for both reported issues.

14​:35 <diakopter> rakudo​: sub foo() { succeed; succeed; succeed }; say
foo
14​:35 <p6eval> rakudo 223419​: OUTPUT«succeed without when clause␤ in
block <anon> at
src/gen/CORE.setting​:327␤ in block <anon> at
src/gen/CORE.setting​:404␤ in
sub foo at /tmp/zS6j4hX0ny​:1␤ in block <anon> at
/tmp/zS6j4hX0ny​:1␤␤»

tests are in S04-statements/terminator.t the succeed one can't really
be tested since we want it to die and it was dying previously also.

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