Null PMC access when doing 'say $foo::' (which shouldn't even parse) in Rakudo #1913

p6rt · 2010-07-06T16:19:06Z

Migrated from rt.perl.org#76400 (status was 'resolved')

Searchable as RT76400$

p6rt · 2010-07-06T16:19:10Z

From @masak

<p6eval> std 31559: OUTPUT«ok 00:01 111m␤»
<TimToady> I didn't expect that to work :)
<masak> std bug.
* TimToady bug
<TimToady> I'm not entirely sure how it parsed...
<TimToady> oh, morename allows a final :: component, but that's not
quite what you want here
<TimToady> std: $defeat-the-name-checker::
<p6eval> std 31559: OUTPUT«ok 00:01 108m␤»
<masak> rakudo: $foo::; say "alive"
<p6eval> rakudo 04a918: OUTPUT«alive␤»
* masak submits rakudobug
<TimToady> rakudo: $foo:: = 42; say $foo::;
<p6eval> rakudo 04a918: OUTPUT«Null PMC access in getprop() [...]
<masak> ok, that goes in the same ticket :)
* masak upgrades the ticket to a Null PMC access
<masak> rakudo: say $foo::
<p6eval> rakudo 04a918: OUTPUT«Null PMC access in type() [...]

p6rt · 2010-07-29T13:45:21Z

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

p6rt · 2011-10-08T20:03:15Z

From @coke

On Tue Jul 06 09:19:10 2010, masak wrote:

<p6eval> std 31559: OUTPUT«ok 00:01 111m␤»
<TimToady> I didn't expect that to work :)
<masak> std bug.
* TimToady bug
<TimToady> I'm not entirely sure how it parsed...
<TimToady> oh, morename allows a final :: component, but that's not
quite what you want here
<TimToady> std: $defeat-the-name-checker::
<p6eval> std 31559: OUTPUT«ok 00:01 108m␤»
<masak> rakudo: $foo::; say "alive"
<p6eval> rakudo 04a918: OUTPUT«alive␤»
* masak submits rakudobug
<TimToady> rakudo: $foo:: = 42; say $foo::;
<p6eval> rakudo 04a918: OUTPUT«Null PMC access in getprop() [...]
<masak> ok, that goes in the same ticket :)
* masak upgrades the ticket to a Null PMC access
<masak> rakudo: say $foo::
<p6eval> rakudo 04a918: OUTPUT«Null PMC access in type() [...]

No more NPAs:

16:01 < [Coke]> rakudo: $foo:: = 42; say $foo::;
16:01 <+p6eval> rakudo 88c5a5: OUTPUT«42␤»
16:01 < [Coke]> rakudo: say $foo::
16:01 <+p6eval> rakudo 88c5a5: OUTPUT«Any()␤»

Closable with tests.

--
Will "Coke" Coleda

p6rt · 2013-11-13T02:06:24Z

From @coke

On Sat Oct 08 13:03:15 2011, coke wrote:

On Tue Jul 06 09:19:10 2010, masak wrote:

<p6eval> std 31559: OUTPUT«ok 00:01 111m␤»
<TimToady> I didn't expect that to work :)
<masak> std bug.
* TimToady bug
<TimToady> I'm not entirely sure how it parsed...
<TimToady> oh, morename allows a final :: component, but that's not
quite what you want here
<TimToady> std: $defeat-the-name-checker::
<p6eval> std 31559: OUTPUT«ok 00:01 108m␤»
<masak> rakudo: $foo::; say "alive"
<p6eval> rakudo 04a918: OUTPUT«alive␤»
* masak submits rakudobug
<TimToady> rakudo: $foo:: = 42; say $foo::;
<p6eval> rakudo 04a918: OUTPUT«Null PMC access in getprop() [...]
<masak> ok, that goes in the same ticket :)
* masak upgrades the ticket to a Null PMC access
<masak> rakudo: say $foo::
<p6eval> rakudo 04a918: OUTPUT«Null PMC access in type() [...]

No more NPAs:

16:01 < [Coke]> rakudo: $foo:: = 42; say $foo::;
16:01 <+p6eval> rakudo 88c5a5: OUTPUT«42␤»
16:01 < [Coke]> rakudo: say $foo::
16:01 <+p6eval> rakudo 88c5a5: OUTPUT«Any()␤»

Closable with tests.

Behavior changed again:

21:05 < [Coke]> r: $foo:: = 42; say $foo::; # RT # 76400
21:05 <+camelia> rakudo-jvm e54ad4: OUTPUT«===SORRY!=== Error while compiling
/tmp/MANE8TYdIa␤Variable '$foo' is not declared␤at
/tmp/MANE8TYdIa:1␤------> $foo::⏏ = 42; say $foo::; # RT #
76400␤ expecting any of:␤ postfix␤»
21:05 <+camelia> ..rakudo-parrot e54ad4: OUTPUT«===SORRY!=== Error while
compiling /tmp/Ry4A8W96Ye␤Variable '$foo' is not declared␤at
/tmp/Ry4A8W96Ye:1␤------> $foo::⏏ = 42; say $foo::; # RT #
76400␤ expecting any of:␤ postfix␤»

--
Will "Coke" Coleda

p6rt · 2014-10-28T20:47:21Z

From @usev6

We're back to the behaviour from 2011:

$ perl6 -e '$foo:: = 42; say $foo::'
42

$ perl6-m -e 'say $foo::'
(Any)

But I wonder whether this is really correct. The subject states that 'say $foo::' should not parse and TimToadys remarks sound likewise:

<p6eval> std 31559: OUTPUT«ok 00:01 111m␤»
<TimToady> I didn't expect that to work :)
<masak> std bug.
* TimToady bug
<TimToady> I'm not entirely sure how it parsed...
<TimToady> oh, morename allows a final :: component, but that's not
quite what you want here
<TimToady> std: $defeat-the-name-checker::
<p6eval> std 31559: OUTPUT«ok 00:01 108m␤»

$ ./viv -e '$foo::'
[...]
└─VAST::statementlist, BEG: 0, END: 7
├─VAST::statement, BEG: 0, END: 7
│ └─VAST::term__S_variable, BEG: 0, END: 6, SYM: variable, _specific: 1
│ └─VAST::variable, BEG: 0, END: 6
│ ├─VAST::sigil__S_Dollar, BEG: 0, END: 1, SYM: $, TEXT: $, _specific: 1
│ └─VAST::desigilname, BEG: 1, END: 6
│ └─VAST::longname, BEG: 1, END: 6
│ └─VAST::name, BEG: 1, END: 6
│ │ └─morename: - !!perl/hash:VAST::morename
│ │ BEG: 4
│ │ END: 6
│ │ EXPR: []
│ │ TEXT: '::'
│ │ identifier: []
│ └─VAST::identifier, BEG: 1, END: 4, TEXT: foo
└─VAST::eat_terminator, BEG: 7, END: 7, TEXT: , WS: 1

p6rt · 2014-10-28T20:47:21Z

From @usev6

We're back to the behaviour from 2011:

$ perl6 -e '$foo:: = 42; say $foo::'
42

$ perl6-m -e 'say $foo::'
(Any)

But I wonder whether this is really correct. The subject states that 'say $foo::' should not parse and TimToadys remarks sound likewise:

<p6eval> std 31559: OUTPUT«ok 00:01 111m␤»
<TimToady> I didn't expect that to work :)
<masak> std bug.
* TimToady bug
<TimToady> I'm not entirely sure how it parsed...
<TimToady> oh, morename allows a final :: component, but that's not
quite what you want here
<TimToady> std: $defeat-the-name-checker::
<p6eval> std 31559: OUTPUT«ok 00:01 108m␤»

$ ./viv -e '$foo::'
[...]
└─VAST::statementlist, BEG: 0, END: 7
├─VAST::statement, BEG: 0, END: 7
│ └─VAST::term__S_variable, BEG: 0, END: 6, SYM: variable, _specific: 1
│ └─VAST::variable, BEG: 0, END: 6
│ ├─VAST::sigil__S_Dollar, BEG: 0, END: 1, SYM: $, TEXT: $, _specific: 1
│ └─VAST::desigilname, BEG: 1, END: 6
│ └─VAST::longname, BEG: 1, END: 6
│ └─VAST::name, BEG: 1, END: 6
│ │ └─morename: - !!perl/hash:VAST::morename
│ │ BEG: 4
│ │ END: 6
│ │ EXPR: []
│ │ TEXT: '::'
│ │ identifier: []
│ └─VAST::identifier, BEG: 1, END: 4, TEXT: foo
└─VAST::eat_terminator, BEG: 7, END: 7, TEXT: , WS: 1

p6rt · 2015-03-08T20:51:18Z

From @Mouq

FWIW, it working with -e is a consequence of the implicit 'no strict'. Turning strict has what is probably a more correct result:

$ perl6 -e 'use strict; $foo:: = 42; say $foo::'
===SORRY!=== Error while compiling -e
Variable '$foo' is not declared
at -e:1
------> use strict; $foo::⏏ = 42; say $foo::
expecting any of:
postfix
$ perl6 -e 'use strict; say $foo::'
===SORRY!=== Error while compiling -e
Variable '$foo' is not declared
at -e:1
------> use strict; say $foo::⏏<EOL>
expecting any of:
postfix

This is the correct behavior (dying, since $foo *wasn't* declared). Thus this is back to testneeded.

On Tue Oct 28 13:47:21 2014, bartolin@gmx.de wrote:

We're back to the behaviour from 2011:

$ perl6 -e '$foo:: = 42; say $foo::'
42

$ perl6-m -e 'say $foo::'
(Any)

But I wonder whether this is really correct. The subject states that
'say $foo::' should not parse and TimToadys remarks sound likewise:

<p6eval> std 31559: OUTPUT«ok 00:01 111m␤»
<TimToady> I didn't expect that to work :)
<masak> std bug.
* TimToady bug
<TimToady> I'm not entirely sure how it parsed...
<TimToady> oh, morename allows a final :: component, but that's not
quite what you want here
<TimToady> std: $defeat-the-name-checker::
<p6eval> std 31559: OUTPUT«ok 00:01 108m␤»

$ ./viv -e '$foo::'
[...]
└─VAST::statementlist, BEG: 0, END: 7
├─VAST::statement, BEG: 0, END: 7
│ └─VAST::term__S_variable, BEG: 0, END: 6, SYM: variable,
_specific: 1
│ └─VAST::variable, BEG: 0, END: 6
│ ├─VAST::sigil__S_Dollar, BEG: 0, END: 1, SYM: $, TEXT: $,
_specific: 1
│ └─VAST::desigilname, BEG: 1, END: 6
│ └─VAST::longname, BEG: 1, END: 6
│ └─VAST::name, BEG: 1, END: 6
│ │ └─morename: - !!perl/hash:VAST::morename
│ │ BEG: 4
│ │ END: 6
│ │ EXPR: []
│ │ TEXT: '::'
│ │ identifier: []
│ └─VAST::identifier, BEG: 1, END: 4, TEXT: foo
└─VAST::eat_terminator, BEG: 7, END: 7, TEXT: , WS: 1

p6rt · 2015-05-02T19:20:23Z

From @jdv

Added test to t/spec/S02-names/symbolic-deref.t

p6rt · 2015-05-02T19:20:23Z

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

p6rt closed this as completed May 2, 2015

p6rt added Bug testneeded labels Jan 5, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Null PMC access when doing 'say $foo::' (which shouldn't even parse) in Rakudo #1913

Null PMC access when doing 'say $foo::' (which shouldn't even parse) in Rakudo #1913

p6rt commented Jul 6, 2010

p6rt commented Jul 6, 2010

p6rt commented Jul 29, 2010

p6rt commented Oct 8, 2011

p6rt commented Nov 13, 2013

p6rt commented Oct 28, 2014

p6rt commented Oct 28, 2014

p6rt commented Mar 8, 2015

p6rt commented May 2, 2015

p6rt commented May 2, 2015

Null PMC access when doing 'say $foo::' (which shouldn't even parse) in Rakudo #1913

Null PMC access when doing 'say $foo::' (which shouldn't even parse) in Rakudo #1913

Comments

p6rt commented Jul 6, 2010

p6rt commented Jul 6, 2010

From @masak

p6rt commented Jul 29, 2010

p6rt commented Oct 8, 2011

From @coke

p6rt commented Nov 13, 2013

From @coke

p6rt commented Oct 28, 2014

From @usev6

p6rt commented Oct 28, 2014

From @usev6

p6rt commented Mar 8, 2015

From @Mouq

p6rt commented May 2, 2015

From @jdv

p6rt commented May 2, 2015