Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash in Junction:D.BUILDALL This type (Scalar) does not support elems #6308

Closed
p6rt opened this issue Jun 3, 2017 · 7 comments
Closed

Crash in Junction:D.BUILDALL This type (Scalar) does not support elems #6308

p6rt opened this issue Jun 3, 2017 · 7 comments

Comments

@p6rt
Copy link

p6rt commented Jun 3, 2017

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

Searchable as RT131490$

@p6rt
Copy link
Author

p6rt commented Jun 3, 2017

From @zoffixznet

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.

@p6rt
Copy link
Author

p6rt commented Sep 30, 2017

From @smls

On Fri, 02 Jun 2017 18​:58​:22 -0700, cpan@​zoffix.com wrote​:

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] rakudo/rakudo@61ecfd511

@p6rt
Copy link
Author

p6rt commented Sep 30, 2017

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

@p6rt
Copy link
Author

p6rt commented Sep 30, 2017

From @zoffixznet

On Sat, 30 Sep 2017 12​:28​:48 -0700, smls75@​gmail.com wrote​:

Is `Junction.new` meant to be public API?

Don't see a reason why not.

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.

---
[1] https://gist.github.com/Whateverable/13556140482322fd5bf4080092a1d284
[2] rakudo/rakudo@61ecfd511

@p6rt
Copy link
Author

p6rt commented Sep 30, 2017

From @smls

On Sat, 30 Sep 2017 13​:13​:31 -0700, cpan@​zoffix.com wrote​:

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.

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";

@p6rt
Copy link
Author

p6rt commented Oct 13, 2017

From @zoffixznet

Tests​: Raku/roast@5ebf6f9303

@p6rt
Copy link
Author

p6rt commented Oct 13, 2017

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

@p6rt p6rt closed this as completed Oct 13, 2017
@p6rt p6rt added the testneeded label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant