Skip Menu |
Report information
Id: 131490
Status: resolved
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: cpan [at] zoffix.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: Crash in Junction:D.BUILDALL `This type (Scalar) does not support elems`
Download (untitled) / with headers
text/plain 335b
While chasing some other bugs, came across this one: <Zoffix__> m: Junction.new.BUILDALL: {} <camelia> rakudo-moar ef9872: OUTPUT: «This type (Scalar) does not support elems␤ in block <unit> at <tmp> line 1␤␤» Not sure how much it matters in itself, but figured I'd report it, in case it's a symptom of a bigger bug.
On Fri, 02 Jun 2017 18:58:22 -0700, cpan@zoffix.com wrote: Show quoted text
> While chasing some other bugs, came across this one: > > <Zoffix__> m: Junction.new.BUILDALL: {} > <camelia> rakudo-moar ef9872: OUTPUT: «This type (Scalar) does not > support elems␤ in block <unit> at <tmp> line 1␤␤» > > Not sure how much it matters in itself, but figured I'd report it, in > case it's a symptom of a bigger bug.
This can be golfed to just: Junction.new; And it has been fixed to throw a better error message now: ➜ Junction.new; Cannot resolve caller new(Junction: ); none of these signatures match: (Junction $: \values, Str :$type!, *%_) (Junction $: Str:D \type, \values, *%_) According to bisectable¹, it was fixed by a commit² in June. The 'bigger issue' was possibly RT #131395. Is `Junction.new` meant to be public API? If not, do we still need a test for this? --- [1] https://gist.github.com/Whateverable/13556140482322fd5bf4080092a1d284 [2] https://github.com/rakudo/rakudo/commit/61ecfd511
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 485b
On Sat, 30 Sep 2017 12:28:48 -0700, smls75@gmail.com wrote: Show quoted text
> Is `Junction.new` meant to be public API?
Don't see a reason why not. Show quoted text
> If not, do we still need a test for this?
If it weren't, all fixed bugs still need a test to cover them. If the test should not become part of the spec, it should be placed into rakudo's test suite instead. Show quoted text
Download (untitled) / with headers
text/plain 801b
On Sat, 30 Sep 2017 13:13:31 -0700, cpan@zoffix.com wrote: Show quoted text
> Don't see a reason why not.
Well, passing a 'type' string parameter to select between what is essentially different object sub-types, seems internal-ish. I can't think of anything else in the public Perl 6 API which does this; a more Perl 6'ish API would dispatch based on *different* named parameters, or simply make the object sub-types available as separate subclasses. So it might make sense to consider `Junction.new` as "not public API" for now, until this is ironed out. Show quoted text
> If it weren't, all fixed bugs still need a test to cover them.
Noted; Marking the ticket as TESTNEEDED. A test for the current behavior could look like: use Test; throws-like { Junction.new }, X::Multi::NoMatch, "Junction.new with no arguments";


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org