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

`Cannot call method 'ACCEPTS' on a null object` in Slang::SQL #2080

Open
AlexDaniel opened this Issue Jul 16, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@AlexDaniel
Member

AlexDaniel commented Jul 16, 2018

This is a continuation of #2069.

Slang::SQL module is failing its tests and bisectable points to (2018-07-09) 6d27166

Error message:

===SORRY!===
Cannot call method 'ACCEPTS' on a null object

There is no golf yet.

@jnthn

This comment has been minimized.

Show comment
Hide comment
@jnthn

jnthn Jul 16, 2018

Member

Slang::SQL is using nqp::ops. It has this:

    sub lk(Mu \h, \k) {
      nqp::atkey(nqp::findmethod(h, 'hash')(h), k)
    }

And later:

      my $cb    := lk($/, 'pblock');
      # some unimportant lines omitted
      if Mu ~~ $cb.WHAT {

The sub sometimes returns nqp::null, and .WHAT on nqp::null is identity, and thus we try to call ACCEPTS on a null value, and fail in the way described here.

Not regressing this module pretty much leaves us with no choice except to re-instate the nqp::null -> Mu mapping in the spesh plugin, though that does at least come almost freely now, so I've just done that.

I'll mark it testneeded, but note we can't add a roast test for this since it can only occur if nqp::ops are used. However, if we want to cover it in the Rakudo tests, we can.

While it's arguable that we don't really support doing stuff with nqp::ops, in reality it's probably the only way to write various some kinds of slang at the moment, so pragmatically, when the cost to us is acceptable, we can try to keep such modules working.

Member

jnthn commented Jul 16, 2018

Slang::SQL is using nqp::ops. It has this:

    sub lk(Mu \h, \k) {
      nqp::atkey(nqp::findmethod(h, 'hash')(h), k)
    }

And later:

      my $cb    := lk($/, 'pblock');
      # some unimportant lines omitted
      if Mu ~~ $cb.WHAT {

The sub sometimes returns nqp::null, and .WHAT on nqp::null is identity, and thus we try to call ACCEPTS on a null value, and fail in the way described here.

Not regressing this module pretty much leaves us with no choice except to re-instate the nqp::null -> Mu mapping in the spesh plugin, though that does at least come almost freely now, so I've just done that.

I'll mark it testneeded, but note we can't add a roast test for this since it can only occur if nqp::ops are used. However, if we want to cover it in the Rakudo tests, we can.

While it's arguable that we don't really support doing stuff with nqp::ops, in reality it's probably the only way to write various some kinds of slang at the moment, so pragmatically, when the cost to us is acceptable, we can try to keep such modules working.

@jnthn jnthn added the testneeded label Jul 16, 2018

@jnthn jnthn removed their assignment Jul 17, 2018

@AlexDaniel

This comment has been minimized.

Show comment
Hide comment
@AlexDaniel

AlexDaniel Jul 18, 2018

Member

Looks ok here!

Member

AlexDaniel commented Jul 18, 2018

Looks ok here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment