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

Make it harder for typechecking exceptions themselves to throw #3531

Merged
merged 5 commits into from
Jul 20, 2020

Conversation

Kaiepi
Copy link
Contributor

@Kaiepi Kaiepi commented Mar 3, 2020

Typechecking exceptions were using $. syntax to get their $!expected and $!got attributes' values. This expects them to have an item method, which is not always the case. On top of that, in some places it expected methods like raku to exist on them or name to exist on their HOW, which isn't always the case either, and would containerize values with Scalar.

This makes it so typechecking exceptions don't containerize values, nqp calls are instead of method calls wherever possible, and whether or not a method exists on a value is confirmed before calling it wherever that isn't possible. Now, the only times they should throw are when .raku or .^name throw, which are errors the user should know about anyway.

Typechecking errors aren't the only cases where you can wind up with Exception handler not loaded for catch being thrown, but are by far the most annoying ones.

Passes make spectest. Not sure if it passes make test or not since t/06-telemetry/02-usage.t fails on master as well as this, but all other tests pass.

X::TypeCheck exceptions would throw if they got a value whose type does
not have an `item` method on it. Prevent `expected` and `got` method
calls from trying to containerize their attributes' values so the only
time these methods should throw is when their `raku` method (if any) or
their HOW's `name` method (if any) throws, which are cases where the
user should know about these errors anyway.
@lizmat
Copy link
Contributor

lizmat commented Mar 3, 2020

I thought the $.foo and self.foo syntax were completely equivalent??

@Kaiepi
Copy link
Contributor Author

Kaiepi commented Mar 3, 2020

$., @., %. will call the item, list, and hash methods respectively on their method's return value:

class Foo {
    has $.foo;
    method bar() { $.foo }
    method baz() { @.foo }
    method qux() { %.foo }
}

class Bar {
    multi method item(|) {
        say 'called item';
        callsame
    }
    multi method list(|) {
        say 'called list';
        ()
    }
    multi method hash(|) {
        say 'called hash';
        %()
    }
}

my Foo:D $foo .= new: foo => Bar.new;
$foo.bar; # OUTPUT: called item
$foo.baz; # OUTPUT: called list
$foo.qux; # OUTPUT: called hash

Normally, this wouldn't matter, but it does here since uninstantiated generics that can pop up from time to time don't have that method, and types made with custom HOWs may not either.

@vrurg
Copy link
Member

vrurg commented Mar 3, 2020

BTW, not really related to this PR, but $. family also don't support class-qualification.

@lizmat lizmat merged commit 8ca13eb into rakudo:master Jul 20, 2020
@lizmat
Copy link
Contributor

lizmat commented Jul 20, 2020

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants