r45619 (merge of stringnull branch) causes Rakudo failure in t/spec/S06-signature/introspection.t

[moritz]

A not yet triaged change in Parrot causes Rakudo to fail the last test in t/spec/S06-signature/introspection.t if built on top of parrot r45768, but works fine on r45386.

With a new parrot, the test dies with

Cannot substr on a null string
current instr.: 'perl6;Any;substr' pc 392639 (src/gen/core.pir:39216)
called from Sub 'perl6;Signature;_block22064' pc 490745 (src/gen/core.pir:74260)
called from Sub 'perl6;Signature;_block22012' pc 489600 (src/gen/core.pir:73755)
called from Sub 'perl6;Signature;_block21990' pc 489362 (src/gen/core.pir:0)
called from Sub 'perl6;GatherIterator;' pc 512916 (src/gen/core.pir:82140)
called from Sub 'perl6;GatherIterator;get' pc 512896 (src/gen/core.pir:82135)
called from Sub 'perl6;Iterator;eager' pc 10834 (src/builtins/Role.pir:143)
called from Sub 'perl6;Seq;!STORE' pc 14241 (src/builtins/Routine.pir:76)
called from Sub 'perl6;Signature;perl' pc 489127 (src/gen/core.pir:73565)
...

[moritz]

According to my bisecting, r45619 ("merge stringnull") is to blame. I'd love to get some input if this is parrot's or Rakudo's fault.

[whiteknight]

On r45386 the test fails for me with this error:

ok 27 - .name for slurpies
ok 28 - multi named_names
ok 29 - ... and .name still works
not ok 30 - .default returns closure
ok 31 - first closure works
Null PMC access in type()
current instr.: '_block465' pc 4019 (EVAL_1:1214)
called from Sub '_block435' pc 3487 (EVAL_1:1043)
called from Sub '_block14' pc 29 (EVAL_1:0)
called from Sub '!YOU_ARE_HERE' pc 364018 (src/gen/core.pir:27559)
called from Sub '!UNIT_START' pc 1299 (src/glue/run.pir:24)
called from Sub 'perl6;PCT;HLLCompiler;eval' pc -1 ((unknown file):-1)
called from Sub 'perl6;PCT;HLLCompiler;evalfiles' pc 1318 (compilers/pct/src/PCT/HLLCompiler.pir:714)
called from Sub 'perl6;PCT;HLLCompiler;command_line' pc 1504 (compilers/pct/src/PCT/HLLCompiler.pir:801)
called from Sub 'perl6;Perl6;Compiler;main' pc -1 ((unknown file):-1

I'm trying with a later revision now.

[whiteknight]

I get this same error at r45786:

ok 31 - first closure works
Null PMC access in type()
current instr.: '_block465' pc 4019 (EVAL_1:1214)
called from Sub '_block435' pc 3487 (EVAL_1:1043)
called from Sub '_block14' pc 29 (EVAL_1:0)
called from Sub '!YOU_ARE_HERE' pc 364018 (src/gen/core.pir:27559)
called from Sub '!UNIT_START' pc 1299 (src/glue/run.pir:24)
called from Sub 'perl6;PCT;HLLCompiler;eval' pc -1 ((unknown file):-1)
called from Sub 'perl6;PCT;HLLCompiler;evalfiles' pc 1318 (compilers/pct/src/PCT/HLLCompiler.pir:714)
called from Sub 'perl6;PCT;HLLCompiler;command_line' pc 1504 (compilers/pct/src/PCT/HLLCompiler.pir:801)
called from Sub 'perl6;Perl6;Compiler;main' pc -1 ((unknown file):-1)

Any idea what I'm doing wrong/differently that I'm seeing this error and not what you are seeing?

[plobsing]

Replying to whiteknight:

Any idea what I'm doing wrong/differently that I'm seeing this error and not what you are seeing?

I get that error when I run the spectest and the reported error when I run the fudged test (t/spec/S06-signature/introspection.rakudo).

Here's what I'm fairly sure is happening:

• Failure is in Signature.perl (src/core/Signature.pm:42)
• You're calling $param.name on an *anonymous* parameter, which returns stingnull
• stringnull used to have "empty string" semantics, making this line harmless
• these empty string semantics were wrong because in the mutable strings system of Parrot, any valid string can be *modified*, including empty-stringish-stringnull. Disaster ensued when this happened.

I'm not sure how to fix this problem. Once we get immutable strings, "null is an empty string" would be able to work (not sure if we want that). We could put a anonymous-check or null-check at that line to prevent this particular error. We could put a check in the rakudo substr routine to guard against null strings, if that's how Perl 6 expects things to work. Or we could try and work back where this stringnull came from, and make it into a non-null empty string (my bet is either an uninitialized string reg, or an uninitialized String pmc).

[moritz]

Thanks for the detailed analysis, plobsing.

I've now pushed a workaround in Rakudo (I'm surprised it didn't surface in many more places). With this workaround in place I'm fine with waiting with the decision if we want empty string behaviour for null strings after the immutable strings are in place.

[bacek]

Just my $0.02. If we want to change (or clarify) behaviour of null strings it's better to do it now and put deprecation notice into 2.3 release.