Skip Menu |
Report information
Id: 130435
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: alex.jakimenko [at] gmail.com
Cc:
AdminCc:

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



Subject: [REGRESSION] UNIT::EXPORT and Foo::EXPORT are no longer comparable (Foo::EXPORT === UNIT::EXPORT)
Download (untitled) / with headers
text/plain 285b
Code: unit module Foo; sub foo() is export {}; say Foo::EXPORT === UNIT::EXPORT # unit makes the declared package the current UNIT Result (2016.04): True Result (HEAD): False Bisectable is pointing to https://github.com/rakudo/rakudo/commit/fe2be65806d907efbbaa0adc4f0175c2e23c3a40
Subject: [REGRESSION] UNIT::EXPORT has different .WHICH than unit scoped module::EXPORT
Download (untitled) / with headers
text/plain 1.2k
On Wed, 28 Dec 2016 19:46:01 -0800, alex.jakimenko@gmail.com wrote: Show quoted text
> Code: > unit module Foo; sub foo() is export {}; say Foo::EXPORT === > UNIT::EXPORT # unit makes the declared package the current UNIT > > Result (2016.04): > True > > Result (HEAD): > False > > > Bisectable is pointing to > https://github.com/rakudo/rakudo/commit/fe2be65806d907efbbaa0adc4f0175c2e23c3a40
Since that commit, https://github.com/rakudo/rakudo/commit/4d85cde90883e031650600b9f55a87e86acb632c also would have regressed this behavior if it had not already been regressed, and there have been other commits since that may also. The bug which 4d85cde9 was trying to address, #128931, pointed out that any two types with the same name had the same .WHICH. It is proper that we should have different .WHICH's on different type objects, even if they have the same name. However, it appears that in the case of UNIT:: and perhaps some other/future PseudoStash aliases, EXPORT may be being treated as a value type and copied around... (EXPORT is immutable outside of COMPILING and metaprogramming APIs): $ perl6 -e 'unit module Foo; use nqp; sub g is export { }; nqp::say(nqp::eqaddr(Foo::EXPORT, UNIT::EXPORT))' 0 ...that will either have to be fixed, or worked around.
Download (untitled) / with headers
text/plain 2.3k
On Wed, 28 Dec 2016 19:46:01 -0800, alex.jakimenko@gmail.com wrote: Show quoted text
> Code: > unit module Foo; sub foo() is export {}; say Foo::EXPORT === > UNIT::EXPORT # unit makes the declared package the current UNIT > > Result (2016.04): > True > > Result (HEAD): > False > > > Bisectable is pointing to > https://github.com/rakudo/rakudo/commit/fe2be65806d907efbbaa0adc4f0175c2e23c3a40
OK, I looked into this some more, and I don't think it is a bug. "unit module" is documented as such: in S02: unit # like our, but introduces a compilation-unit scoped name in S11: unit module Foo; # rest of scope is in module Foo None of that says UNIT and unit module Foo will be the same package, just that everything in the rest of the file will be lexically inside Foo. Note that the UNIT/SETTING/CORE packages are lexical scopes and your program is the next *block* below UNIT, whereas the GLOBAL "package scope" is what is above your *package* ... so there is an apples and oranges difference between "Foo::" and "UNIT::". The description of the EXPORT and UNIT::EXPORT classes are as such in S11: "Every compunit has a C<UNIT> package, which gets a lexically scoped C<EXPORT> package automatically. Declarations marked as C<is export> are bound into it, with their tagsets as inner packages. ... Exports contained within a module will also be bound into an our-scoped C<EXPORT> package nested in the module, again with the tagsets forming inner packages. This is so the C<import> keyword can be used with a package ... Inner packages automatically add their export list to packages in all their outer scopes (including UNIT)" ...note I think there is a typo in S11 where it says: the lexical C<IMPORT> package in C<UNIT>, on the other hand, is the only thing that is considered by C<use> for importing. ...in that IMPORT should be EXPORT. I don't see anything in roast that tests that the two EXPORTs are ===, so this behavior was never promised, it just "worked" by accident until other changes disrupted it. Now the question is, what was the use case of comparing the two EXPORT stashes, and/or what behavior results from them being different which is problematic? I'd consult IRC or the mailing list to figure out a different way to do whatever this was intended to do. Keeping this open so the spec typo may be verified by second opinion and fixed, but then we should close/reject this ticket.


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