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

module objects badly behaved for type checks #4854

Open
p6rt opened this issue Dec 13, 2015 · 5 comments
Open

module objects badly behaved for type checks #4854

p6rt opened this issue Dec 13, 2015 · 5 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Dec 13, 2015

Migrated from rt.perl.org#126891 (status was 'open')

Searchable as RT126891$

@p6rt
Copy link
Author

p6rt commented Dec 13, 2015

From zefram@fysh.org

my Int $a = CORE
$a.WHAT.say
(CORE)
CORE.^isa(Int)
Cannot call isa(Perl6​::Metamodel​::ModuleHOW​: CORE, Int); none of these signatures match​:
  (Mu \SELF​: Mu $type, *%_)
  (Mu \SELF​: Str​:D $name, *%_)
  in block <unit> at <unknown file>​:1
(sub (Int $a) { 1 })(CORE)
Type check failed in binding $a; expected Int but got CORE
  in sub at <unknown file>​:1
  in block <unit> at <unknown file>​:1

CORE is a module object; other module objects behave similarly. As shown
above, they can be assigned to type-constrained variables despite not
meeting the type constraint. Additionally, the .^isa method fails to
operate on them; don't know whether these two faults are really related.
Type constraint does apply as expected to a subroutine parameter.

-zefram

@p6rt
Copy link
Author

p6rt commented Dec 13, 2015

From @lizmat

Zefram,

On 13 Dec 2015, at 05​:56, Zefram (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Zefram
# Please include the string​: [perl #​126891]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=126891 >

my Int $a = CORE
$a.WHAT.say
(CORE)
CORE.^isa(Int)
Cannot call isa(Perl6​::Metamodel​::ModuleHOW​: CORE, Int); none of these signatures match​:
(Mu \SELF​: Mu $type, *%_)
(Mu \SELF​: Str​:D $name, *%_)
in block <unit> at <unknown file>​:1
(sub (Int $a) { 1 })(CORE)
Type check failed in binding $a; expected Int but got CORE
in sub at <unknown file>​:1
in block <unit> at <unknown file>​:1

CORE is a module object; other module objects behave similarly. As shown
above, they can be assigned to type-constrained variables despite not
meeting the type constraint. Additionally, the .^isa method fails to
operate on them; don't know whether these two faults are really related.
Type constraint does apply as expected to a subroutine parameter.

thanks for submitting these tickets!

Some further data points​:

This seems to apply to any variable type and any PseudoStash​:

$ 6 'my Str $a = MY; say $a'
(MY)

Oddly enough, binding *does* fail with a typecheck error​:

$ 6 'my Str $a := GLOBAL'
Type check failed in binding; expected Str but got GLOBAL
  in block <unit> at -e​:1

Liz

@p6rt
Copy link
Author

p6rt commented Dec 13, 2015

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

@p6rt
Copy link
Author

p6rt commented Dec 16, 2015

From zefram@fysh.org

Elizabeth Mattijsen via RT wrote​:

This seems to apply to any variable type and any PseudoStash​:

Further generalisation​: it also happens for any package object (GLOBAL,
MAIN) and any role object (Iterable, Dateish). In both cases, the
.^isa misbehaviour is seen as well as the actual ability to bypass
type constraints.

-zefram

@p6rt p6rt added the Bug label Jan 5, 2020
@usev6
Copy link

usev6 commented Oct 6, 2023

It looks like these are indeed two different problems.

The first problem (package objects or role objects bypassing the type constraint checks) seems to be solved:

$ ./rakudo-m -e 'my Int $a = CORE'
Type check failed in assignment to $a; expected Int but got CORE (CORE)
  in block <unit> at -e line 1

$ ./rakudo-m -e 'my Int $a = Iterable'
Type check failed in assignment to $a; expected Int but got Iterable (Iterable)
  in block <unit> at -e line 1

According to bisectable6 (https://colabti.org/irclogger/irclogger_log/raku-dev?date=2023-10-06#l86) this has been fixed back in 2018 with rakudo/rakudo@d3c5381b74.

The second problem (.^isa misbehaviour) is still present:

$ ./rakudo-m -e 'CORE.^isa(Int)'
Cannot resolve caller isa(Perl6::Metamodel::ModuleHOW:D: CORE:U, Int:U); none of these signatures matches:
    (Mu \SELF: Mu $type, *%_ --> Bool)
    (Mu \SELF: Str:D $name, *%_ --> Bool)
  in block <unit> at -e line 1

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

No branches or pull requests

2 participants