[perl #122929] quoted LHS of pair constructor inside enum definition makes elements be ignored
Fixed in 754664ed54aea24f9c9162002b6e68aadd311412.
On Wed, 08 Oct 2014 05:20:07 -0700, timo wrote:
> compare:
>
> > perl6-m -e 'enum Bug ("foo" => -1, "A", "B"); say +A; say +B;'
> > 1
> > 2
>
> and:
>
> > perl6-m -e 'enum Bug (foo => -1, "A", "B"); say +A; say +B;'
> > 0
> > 1
>
> and see also:
>
> > perl6-m -e 'enum Bug ("foo" => -1, "A", "B"); say foo'
> > ===SORRY!=== Error while compiling -e
> > Undeclared routine:
> > foo used at line 1
>
> vs
>
> > perl6-m -e 'enum Bug (foo => -1, "A", "B"); say foo'
> > foo
>
> I think this should at least warn or die, not silently drop an element
> from the list.
>
> This bit me in my Cairo binding, as it requires an enum to start at -1
> and i accidentally quoted the LHS of the initial pair.
[perl #128017] enum treats a Seq of Pairs as a List of Str
Fixed in 754664ed54aea24f9c9162002b6e68aadd311412.
On Thu, 28 Apr 2016 07:06:42 -0700, gfldex wrote:
> enum Bits ( (('Bit-' X~ 1..8) Z=> (1, 2, 4 ... 256)) ); dd Bits.enums;
> # OUTPUT«{"Bit-1\t1" => 0, "Bit-2\t2" => 1, "Bit-3\t4" => 2, "Bit-
> 4\t8" => 3, "Bit-5\t16" => 4, "Bit-6\t32" => 5, "Bit-7\t64" => 6,
> "Bit-8\t128" => 7}»
>
> # expected:
> # OUTPUT«{"Bit-1" => 1, "Bit-2" => 2, "Bit-3" => 4, "Bit-4" => 8,
> "Bit-5" => 16, "Bit-6" => 32, "Bit-7" => 64, "Bit-8" => 128}»
[perl #130446] [REGRESSION] [LTA] Creating an enum from a Hash does not work but no longer warns (enum Bits (%thing))
Fixed in 754664ed54aea24f9c9162002b6e68aadd311412. Note however, that there's a braino above, since the 'my' is initialized after the value is needed. So the fix is to warn about an empty variable, not to make it work. (It does work if you make it a constant, or put the my inside a BEGIN.) On Thu, 29 Dec 2016 14:36:55 -0800, alex.jakime...@gmail.com wrote: > Code: > my %h = ; enum Bits (%h); dd Bits.enums > > > Result (2016.05): > WARNINGS for /tmp/R9MG8i4xtv: > Useless use of %h in sink context (line 1) > Map.new(()) > > > Result (HEAD): > Map.new(()) > > > It is kinda sad that the error message is no longer there. Is there > anything we can do about it?
[perl #130041] [BUG] Pair in enum declaration should either DWIM or parsefail
Actually, the Z=> misbehavior is already called out in #128017. On Tue, 28 Nov 2017 00:04:05 -0800, larry wrote: > This also showed up when doing things like: > enum Foo ( Z=> 1,2,3); > > Fixed in d9021cf16e7df051c5e17c33919c9bde44c5e0db but tests needed. > > > On Mon, 07 Nov 2016 11:37:06 -0800, FROGGS.de wrote: > > m: enum Foo ( A => 42, 'B', 'C', 'D' ); say +B > > rakudo-moar e10f76: OUTPUT«43» > > > > m: enum Foo ( 'A' => 42, 'B', 'C', 'D' ); say +B > > rakudo-moar e10f76: OUTPUT«1» > > > > m: enum Foo ( 'A' => 42, 'B', 'C', 'D' ); say +A > > rakudo-moar e10f76: OUTPUT«===SORRY!=== Error while compiling > > Undeclared name:A used at line 1» > > > > B should either yield 43, or the entire expression should fail to parse. > > (I'd prefer the former fwiw.) > > > >
[perl #130041] [BUG] Pair in enum declaration should either DWIM or parsefail
Actually, the Z=> misbehavior is already called out in #128017. On Tue, 28 Nov 2017 00:04:05 -0800, larry wrote: > This also showed up when doing things like: > enum Foo ( Z=> 1,2,3); > > Fixed in d9021cf16e7df051c5e17c33919c9bde44c5e0db but tests needed. > > > On Mon, 07 Nov 2016 11:37:06 -0800, FROGGS.de wrote: > > m: enum Foo ( A => 42, 'B', 'C', 'D' ); say +B > > rakudo-moar e10f76: OUTPUT«43» > > > > m: enum Foo ( 'A' => 42, 'B', 'C', 'D' ); say +B > > rakudo-moar e10f76: OUTPUT«1» > > > > m: enum Foo ( 'A' => 42, 'B', 'C', 'D' ); say +A > > rakudo-moar e10f76: OUTPUT«===SORRY!=== Error while compiling > > Undeclared name:A used at line 1» > > > > B should either yield 43, or the entire expression should fail to parse. > > (I'd prefer the former fwiw.) > > > >
[perl #130041] [BUG] Pair in enum declaration should either DWIM or parsefail
This also showed up when doing things like: enum Foo ( Z=> 1,2,3); Fixed in d9021cf16e7df051c5e17c33919c9bde44c5e0db but tests needed. On Mon, 07 Nov 2016 11:37:06 -0800, FROGGS.de wrote: > m: enum Foo ( A => 42, 'B', 'C', 'D' ); say +B > rakudo-moar e10f76: OUTPUT«43» > > m: enum Foo ( 'A' => 42, 'B', 'C', 'D' ); say +B > rakudo-moar e10f76: OUTPUT«1» > > m: enum Foo ( 'A' => 42, 'B', 'C', 'D' ); say +A > rakudo-moar e10f76: OUTPUT«===SORRY!=== Error while compiling > Undeclared name:A used at line 1» > > B should either yield 43, or the entire expression should fail to parse. > (I'd prefer the former fwiw.) >
[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails
Yes, as noted above, this is a dup of rejected ('better docs needed', really)
ticket #130562.
[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails
Yes, as noted above, this is a dup of rejected ('better docs needed', really)
ticket #130562.
[perl #131922] [LTA] "Variadic" or "slurpy"?
Only *@foo and *%foo are slurpy, as in "slurping up the rest of the arguments.
But the term "variadic" refers to all optional arguments including named ones,
so it would be incorrect to call those "slurpy", because they don't. It's like
the difference between * and ? in regex.
Larry
On Fri, 18 Aug 2017 07:10:52 -0700, comdog wrote:
> Consider this program which I don't expect to work (and it doesn't compile):
>
> sub show-the-arguments ( *@args, $i ) {
> put "The arguments are @args[]";
> }
>
> show-the-arguments( 1, 3, 7 );
>
> The error message says "variadic":
>
> Cannot put required parameter $i after variadic parameters
>
> But another sort of error uses a different term:
>
> sub show-the-arguments ( *@args, $i ) {
> put "The arguments are @args[]";
> }
>
> This time the error messages say "slurpy":
>
> Only one slurpy positional allowed
>
> The docs almost almost always say "slurpy" and the uses of "variadic"
> only appear as synonyms next to "slurpy":
>
> * https://github.com/perl6/doc/search?utf8=✓=variadic=
>
> * https://github.com/perl6/doc/search?utf8=✓=slurpy=
[perl #131922] [LTA] "Variadic" or "slurpy"?
Only *@foo and *%foo are slurpy, as in "slurping up the rest of the arguments.
But the term "variadic" refers to all optional arguments including named ones,
so it would be incorrect to call those "slurpy", because they don't. It's like
the difference between * and ? in regex.
Larry
On Fri, 18 Aug 2017 07:10:52 -0700, comdog wrote:
> Consider this program which I don't expect to work (and it doesn't compile):
>
> sub show-the-arguments ( *@args, $i ) {
> put "The arguments are @args[]";
> }
>
> show-the-arguments( 1, 3, 7 );
>
> The error message says "variadic":
>
> Cannot put required parameter $i after variadic parameters
>
> But another sort of error uses a different term:
>
> sub show-the-arguments ( *@args, $i ) {
> put "The arguments are @args[]";
> }
>
> This time the error messages say "slurpy":
>
> Only one slurpy positional allowed
>
> The docs almost almost always say "slurpy" and the uses of "variadic"
> only appear as synonyms next to "slurpy":
>
> * https://github.com/perl6/doc/search?utf8=✓=variadic=
>
> * https://github.com/perl6/doc/search?utf8=✓=slurpy=
[perl #131695] [LTA] Confusion in precedence with <<$foo>>[0]
We now warn on the ambiguity of >> or » when used where it could easily be intended as either a hyper or the quotewords terminator. While we could, in theory, do some lookahead to try to suppress this warning in some cases, it will be brittle in the face of languages that mutate the postfix space, so I think it's better to just warn outright and let people disambiguate with whitespace or a suitable change to the hyper or quote delims. (As for retargeting this ticket to the more general case of multiline quote errors, please note that a runaway hyper is not a kind of quote, and that we already warning on runaway quotes that cross line boundaries. Also, the problem here is essentially independent of multi-line-ness. So I've changed the title of this bug back to the original, since that's the problem we're fixing.)
[perl #123572] [BUG] :256[list of numbers] wrongly allows the numbers to exceed 255 in Rakudo
On Fri, 09 Jan 2015 10:59:08 -0800, masak wrote: > m: say :256["☺".ords] > rakudo-moar c5dcdf: OUTPUT«9786» > m: say :256[0x263a] > rakudo-moar c5dcdf: OUTPUT«9786» > seems we could use a check there... > m: say :256[256,256] > rakudo-moar c5dcdf: OUTPUT«65792» > * masak submits rakudobug I suspect we should disallow out-of-radix entries for all but the first, since there are uses for allowing the first entry to overflow, such as encoding hours, minutes, and seconds. On the other hand, if we had something to do a reverse polymod, we wouldn't need to use :radix[] for that purpose, and could restrict all the digits on the assumption that it is only to be used for normal homogenous numeric bases.
Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly
On Fri, Sep 23, 2016 at 11:42:20PM -0700, Itsuki Toyota wrote:
: # New Ticket Created by Itsuki Toyota
: # Please include the string: [perl #129346]
: # in the subject line of all future correspondence about this issue.
: # https://rt.perl.org/Ticket/Display.html?id=129346 >
:
:
: See the following results
:
: $ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; }; foo(10);'
: Constraint type check failed for parameter 'a'
: in sub foo at -e line 1
: in block at -e line 1
Even if .WHAT were not special, this wouldn't ever work, because you've got
a double-closure there, one from the curlies, and the other from the *. So
the outer closure would return the inner closure, which would always evaluate
to true.
: $ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
foo(10);'
: Constraint type check failed for parameter 'a'
: in sub foo at -e line 1
: in block at -e line 1
This will never work because \e.WHAT returns a Capture object, which will never
=== Int.
: $ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
foo(10);'
: Hello
That is, in fact, a correct way to write it.
: It seems that "Whatever *" cannot handle sigilless values correctly.
The sigilless variable isn't declared yet, so a.WHAT doesn't work either. But
this is another correct way to write it:
$ perl6 -e 'sub foo(\a where { .WHAT === Int } ) { say "Hello"; }; foo(10);'
Hello
Larry
[perl #114438] [@LARRY] Rakudo gives an error about a missing 'self' when a subroutine uses an invocant parameter
Rakudo now gives a decent error (X::Syntax::Signature::InvocantNotAllowed), and there's even a test for it.
[perl #77664] [@LARRY] Rakudo parses q\\ as quoting but STD as routine q call
I'm fine with the rakudo behavior here.
[perl #77550] [@LARRY] $. in regexp accepted by Rakudo but not by STD
The chance of someone using $. inside a regex and meaning what it means in Perl 5 is minimal. Best to just leave this as a "can never match".
[perl #124568] [GLR] [@LARRY] 'Rakudo still uses Nil here' (Or bogus test?)
Test was bogus. Replaced with test that assumes Empty semantics on next. test fixed in 06f9c5d010986a7a8dde907971e25985e8ba4601
[perl #128550] [@LARRY] <[a..z]> ranges break grapheme awareness
The code generator in nqp for char ranges was incorrectly using ordat and ordfirst to find the character to compare, which throw away information on synthetic characters. We now use the getcp_s instruction instead, which leaves synthetics negative, so that they drop out of the character range correctly (but only when :m is not specified, of course). nqp fix in 2df0a0656e4b20a72bd73e6d2b6214b584d095ac rakudo bump in fe90be01c6546e1dbb2ee7ff794e8b6ea1491268 Tests updated in 172f6945653ddbce944af1d7cae9ad956f3a70b9
[perl #128860] [LTA] [@LARRY] List.invert only works if the list contains Pairs but the error message isn't very clear about that fact
Binding of the map routine internally now requires list elements to bind as Pair, which improves the error message. (The alternate approach of inserting a CATCH into the map closure could in theory produce an even better message, but it appeared to slow things down more than the Pair binding approach.) Note that we cannot make the degenerate case of .invert the same as .antipairs, because .invert must expand list values into multiple antipairs. In any case, .antipairs is 5-10 times faster since it doesn't have to check for such expansion. Fix in baeabb4c4e8f5d223da8632130b4dfcd020d40ba Test in 63c1f009b910a5c87186b2201383682ad7a0f724
[perl #123072] [GLR] 'for' loop in sink context isn't invoking block in sink context
Some method calls were not properly sunk as a final statement in a loop. Fix in 977797fa401856e5310155f13469b7e6ff5f620a Test in bc8fa4fd8d449573eb6001b5f43f8890f65b9196
[perl #127879] [BUG] map subroutine ignores the sequence in the specific case
The unwanted() routine needed to add an explicit sink to certain methods found in a block-final Want node. (Method calls for dispatch:<.=> and Pair.new are exempt, however. In the case of .=, it is 'nosink' because it's essentially going to cause a side effect anyway, and doing it twice tends to drain Seq prematurely if that's what .= returns. With Pair.new, wrapping in .sink suppressed sink warnings on useless use of pairs.) Other than those exceptions, it seems more reasonable to default method calls to sinking on the chance that the method will return a sequence that needs to be iterated for its side effects. Fix in 328402599c16077e182bb38baf68e435b8bc1082 Test in b6012e0cd755d9c89ddff00dc45ce81a82bcbdcc
[perl #127563] repeat while loop not being entered when inside a routine and block
The repeat and loop constructs weren't properly self-sinking at statementlist level. Fixed in 589061eac14f2847e2c4b401d2ff2eb30c62675e Test in cbbff3ba0f1120fe7dfded0a980f9b73263f0868
[perl #128596] [BUG] repeat {} doesn't repeat when it's last item inside a sub called from a loop
The repeat and loop constructs were not properly sinking themselves at statementlist level. Fixed in 589061eac14f2847e2c4b401d2ff2eb30c62675e Untodo'd existing test.
[perl #128830] [LTA] Error on while (0){}
We now examine the preceding character, and if it's a closing brace, suggest use of whitespace before curlies taken as a hash subscript. Fixed in 7ec824e52ab5b285cda47179e6f41e452d870762
[perl #128802] [BUG] Spurious useless use warning in for (@a xx 1) { }
This turns out to be a fascinating bug, not the usual "useless use of useless use". We were cloning a closure twice because we were calling EXPR twice on the same expression, namely inside the 'for' rule that looks for a C-style for loop. It was doing this inside a because it was just conjecturally seeing if it could parse 3 expressions separated by two semicolons. In general, we should not have side effects when conjecturally parsing, but in this case EXPR could call down into the code that thunkifies statements and xx and such, and clone a copy of the thunk into the current lexical scope, which is stored in $*W rather than in the current parse tree. So when the AST was thrown away, the extra code remained, and triggered the useless use warning, because it really was, in some sense. The solution is to set $*SUPPOSING=1 inside and , and then prevent such spurious side effects when we're merely parsing conjecturally. Fix in nqp to set $*SUPPOSING: e0e113dcbf0e02ab8b22216521ea74f18f6a1bef Fix in rakudo to make use of $*SUPPOSING to suppress thunk refs: 9c7b3c1f47622b0751f3752f52d93e257cc4b8d5 I'm resolving this, but someone can still write a test if they can figure out how... :)
[perl #128811] non-associatives are somehow getting treated as list associatives
We've split the non-associative exceptions into the base class, X::Syntax::NonAssociative, with a subclass off X::Syntax::NonListAssociative. nqp's EXPR now calls a different method to fail list associativity, and rakudo provides the alternate method to get the appropriate message. nqp fix in 9073af7ab6049485a245fce383a034a41603cfd8 rakudo fix in f568db26f85909a2431325491405fea6a1efed87 tests in 5939e74f80322a1288fbd891b24311186b015eb8
[perl #128766] Useless use of $a in sink context is spurious
The onearg form of reduce wasn't correctly marking wantedness of either the operator or the argument. Fixed in fc28b67185d711cf8e4b3f9e6987e1ceee34e37b. (We don't test sink warnings currenlty.)
[perl #128770] 5334cb725 causes erroneous sink on ($_ with "foo")
The logical ops andthen, notandthen, and orelse were not propagating wantedness to their thunky args. Fixed in 7ba6dbfae97f5ff9398336e49267d51606512df9. Note that we don't generally test sink warnings currently.
[perl #127965] [BUG] Texas hyper doesn't parse correctly in topicalized quoteword associative index assignment
Not A Bug. LTM requires it to recognize => over = inside, and then you're missing a >. Looking at it from the other direction, thinking that it will find the >> on the end and then back up to isolate the = is a subtle mental trap of two-pass parsing, which is typically forbidden in Perl 6. To write the Texas form of this operator, you must write >>[=>]>> instead.
[perl #127097] Error message for calling $.attr in BUILD could be improved
Now says: Virtual method call $.foo may not be used on partially constructed object (maybe you mean $!foo for direct attribute access here?) Fix in 5a69da88b9b16f916125add8f89aff68113a9877
[perl #127013] [BUG] 'while' only returns list from routine with explicit return
Fix in 386905f6f62f9fa3525c887a8a86fa48b22b4b35 and 37e742f0bb6f36f1a9d9a5f947c5c0de15d236c2 Test in ba521fa8101f3114c87ec1a295707cb68b5b
[perl #127069] [BUG] Simple loop dies
Dup of #127013. Tests for this particular ticket in a8bbde8fa06d5d55bc6d5879a0c84a669d7f0481
[perl #127022] [BUG] Can't find infix < in the middle of nowhere (a given)
Dup of #127013, see fix there.
[perl #126005] UNDO always fires for while, until, loop, whenever, with/without, (others too)?
Fixed in 02588190492349fabde00c5a15b873ea61a9333e Tested in 2f126a3ab7d0991767ca84c562b8f3ae97b25c4e There are no tests there for with or whenever, but those did not appear to misbehave when I tried them on the command line. Feel free to add more tests for those.
[perl #125769] Failure bound to variable, as result of if statement, sinks and throws
Fixed in 091ee7507464595e7712f4ae911d95d467e5281b Tests in 8b97aa4f6191affdd91da78607eca4ae6dc73b11
[perl #100232] Implementation details leak through in variable interpolation into regexes
A new restricted dialect of regex is implemented in 28ab83f947b4899a4f8698eee5bc056742f356f1 and 19d84be0066978f616ace6fa9f506e742161a378 Tests in 1becd7c9b456b707a14bfba40d672ec28945f199
[perl #125769] Failure bound to variable, as result of if statement, sinks and throws
Minimal test case:
{ my $f := Failure.new("bar"); }
This doesn't seem to be sink related, at least not directly. It seems more to
be related to the difference between storing things in a local vs in a lexical,
and how those are treated on statement or return boundaries.
[perl #121406] [BUG] No "useless use in sink context" warning on in sink context in Rakudo
fixed in 323a5c077efeaa058de48871963046507e33b272
[perl #126926] [BUG] Pairs of numbers don't sort consistently
I shouldn't file bugs when I haven't slept...
[perl #81336] [BUG] infix:<~~> isn't chaining in Rakudo
~~ is now chaining where it can be; it obviously makes little sense to chain something on both sides that is not a normal data value. So if you include a regex or a closure, it must be the final test. Also, in order to get $a ~~ $b ~~ $c to work, we cannot topicalize $b. Fix in f457007181bb6e2dcb6aefe857f36d648ae38401 Tests in cf080c9f958bc3153dde217b107c65ddb617afe6
[perl #118791] [BUG] Rxx doesn't thunk its rhs in Rakudo
Fixed, along with all the other metaops, in: 1e1556b1a25bc4c73a505fdd249d4179ffc813de 0a2303c0f6a2a3782fecb13db1523cb5442467de 67202d697d3fe48b800e95262bebe6da17bfcf49 e2e23fb8853808839884f23a0b8aa91f458fd310 97ef742f350e84dae275ed2dc9d453795f057dba 6516930c86d6ff4296ee8699a64eb1315eed2583 Tests: 200ec05eb0865b9cbc128ba77b726111cc5a171a 52e3715b882ce8f7fa9761029ce7166725eb0bee
[perl #125811] 2 ** 99999999999999999999999999999999999 = 0
Fixed with 67795245fd9b17ca11036b63aa04e17deabb8e7a Tests needed.
[perl #126761] [BUG] tighter and export not working together
The add_categorical method was assuming it was adding a fresh definition of an operator, not one borrowed from a module, so it overrode the existing precedence with the defaults, which are wrong if the existing precedence doesn't happen to match the default. Fixed with bb598968c68bff2163322aea040bd81ec6097ae4 Test in fae390f38efad9e51d2224951d7eb3d47fe9b889
[perl #126771] internal error with m:i:m
fix in MoarVM, 6da907f72a8a0015f4631b7d11a20fc428e9aad4 test in 0d2a5c01972d11c0a35573e8362c040bf974cde3
[perl #126789] A caught exception still exits a sub ?
The default of die is to, er, die. You can resume after a die, but only if you
do so explicitly, in which case you are responsible for overriding the
expectations of whoever wrote the die and likely did not expect it to return.
> p6 'sub a($a) { $a(); CATCH { default { say "default"; .resume } }; 42 }; say
> a( -> { die } )'
default
42
Here's the problem with that:
> p6 'sub a($a) { $a(); CATCH { default { say "default"; .resume } }; 42 }; say
> a( -> { die unless $*INVARIANT; } )'default
42
Okay so far, but suppose we violate the invariant...
> p6 'sub a($a) { $a(); CATCH { default { say "default"; .resume } }; 42 }; say
> a( -> { die unless $*INVARIANT; say "assume $*INVARIANT" } )'
default
default
default
This exception is not resumable
in block at -e:1
in block at -e:1
So resuming is never going to be the default for die. (That's why we have
warn, after all.)
[perl #126739] [BUG] HyperSeq erroneously returns empty list
Dup of #126597
[perl #120916] [BUG] Stubbed attributes in roles don't die at compose time like stubbed methods do in Rakudo
The purpose of stubbing is to guarantee the public interface is complete, and since the public interface of attributes is entirely via accessors, it suffices to merely stub the accessor, and leave it up to the class whether it should implement that name via an explicit method or an attribute declaration. It should probably be part of the documentation of a role whether it's intended that a particular name be implemented by by an attribute, but really, it's entirely up to the class whether a given part of the interface is represented by an actual attribute or a virtual attribute. Larry
[perl #126746] [BUG] <![a]> doesn't match at EOS
Fixed for moarvm with nqp patch 2661d275d2427a1d3ceeed0f5ac9fb1494e4e122 (jvm not patched yet)
[perl #126746] [BUG] <![a]> doesn't match at EOS
nqp/jvm fix in f17e8c56ff171377999e468fe65e75a3ba807a4b tests in aef8ea1df4beed8f69b6ecb80784e78c6e2c6680
[perl #88340] backreferences to quantified captures are inconsistent in rakudo
Matching only the final match is not desirable, in my opinion. It should match the string traversed by all the matches in $0, including intervening separators, if any. The problem is that ~$0 has spaces interpolated, which will match only if the separators happen to be a single space, so there is now a $0.backref that returns the string actually traversed by the entire list of matches. Matching $0 as a backref should use that method. > p6 'my $abc = " a,b,c, "; $abc ~~ /(\w+ % ",")/; say $0.backref' a,b,c BTW, matching just the final match can be accomplished with something like $($0[*-1]), I suspect.
[perl #126476] [BUG] non-matching S/// should return unmodified string
Fixed in 9e4902f772b0e86fe96771b22039aaf1a57fae34
[perl #126557] Fancy ‘’ quotes in rules
Fixed in 36a35142a0b7dadd65a5b09bcba7f460845ae3e9 Tests in 2ccb4443d61efd053419239203106e5636b021ce and 7cd9f97ccdad6299c3b6dc4d4b071c6580c0b66c
[perl #126394] [BUG] Assigning Failure to typed variable swallows Failure information
On Mon Oct 19 07:02:44 2015, elizabeth wrote:
> Fixed with a31cc91a0d604a8a74529 . Tests are still needed
>
> > On 19 Oct 2015, at 03:42, Carsten Hartenfels (via RT) > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Carsten Hartenfels
> > # Please include the string: [perl #126394]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=126394 >
> >
> >
> > This bug is for Rakudo version 2015.09-419-gfae01fb built on MoarVM
> > version 2015.09-79-gee9fc2b, according to `perl6 --version`.
> >
> > The following code, in `t.pl`:
> >
> > sub s { fail 'important failure message' }
> > my Int $x = s();
> > say $x;
> >
> > will output:
> >
> > Type check failed in assignment to $x; expected Int but got Failure
> > in block at t.pl:2
> >
> > But it omits the important failure message, as well as where it was
> > actually thrown. Opposed to that, omitting the type:
> >
> > sub s { fail 'important failure message' }
> > my $x = s();
> > say $x;
> >
> > will output the much more useful message:
> >
> > important failure message
> > in sub s at t.pl:1
> > in block at t.pl:2
> >
> > Actually thrown at:
> > in block at t.pl:3
> >
> > This seems to make typed variables much less useful, since they
> > potentially eat failure messages every time you assign to them.
> >
> > Ideally, the type check message would include the failure information
> > too, something like:
> >
> > Type check failed in assignment to $x; expected Int but got Failure
> > important failure message
> > in sub s at t.pl:1
> > in block at t.pl:2
The existing 'method priors' wasn't working correctly due to a precedence error
originally made by TimToady-- that ate the priors result as part of the ??!!
conditional. Simply adding a "do" fixes that and renders the previous patch
unnecessary. Fixed in 48a0888cced2e772d9b347460a69507fc822bd2d (tests still
needed).
[perl #126318] [BUG] trait 'is default' on attributes has no effect
On Sat Oct 10 08:33:13 2015, FROGGS.de wrote:
> say class { has Int $.foo is default(0) }.new.foo
> rakudo-moar 025ec1: OUTPUT«(Int)»
>
> class Foo { has Int $.foo is default(0) }; say Foo.new.foo
> rakudo-moar 025ec1: OUTPUT«(Int)»
>
> I would expect that foo is zero in both cases.
Even less sensical, it violates its own :D here:
> p6 'say class { has Int:D $.foo is default(0) }.new.foo'
(Int:D)
[perl #126370] [BUG] hyper multidim subscript doesn't meet postcircumfix:<[; ]> API
Fixed with 23248109c9c93db2774fcc9ce0c849a73a01fdad Tested with f8c0844fbffeac6022603cda8bfbc4f1f35e9a57
[perl #126359] [BUG] deconfuse language name and compiler in -v and -V
On Wed Oct 14 09:46:18 2015, larry wrote:
> 09:39 < TimToady> HLL::Compiler is very confused about what is the language
> name/version vs compiler name/version, and this shows up in both -v and -V
> 09:40 < TimToady> "This is perl6 version 2015.09-373-g254c1a8"
> 09:42 < TimToady> should be more like "This is rakudo version
> 2015.09-373-g254c1a8 implementing Perl v6b" or so
>
> (well, that, and it should still mention the backend version too)
Also, make sure the Perl version is stored in only one place. In addition to
the HLL::Compiler spot, we currently have:
./core/Perl.pm: :$!version = Version.new("6b"),
./Perl6/Grammar.nqp: my $vhave := $*W.find_symbol(['Version']).new('6.b'); #
XXX need to use same source as Version.pm
[perl #126241] operator names need to be valid, parsable Perl
nqp fix in a79e4abbe60d28f59b451416e7946ee433db7199 rakudo fix in 091637fd5ace48a0835fc8af786f2caa372381cf roast fix in dc3e1335232bb617b42d335ddbcc42be0a9dedaa
[perl #79174] [BUG] Either Rakudo or STD.pm6 is wrong about comma before 'given' statement modifier
Statement modifiers now behave as terminators. Tests in 6fa03d9816b1613762f12def4bbc556dbb5fb3d5
[perl #126292] [BUG] feeds don't correctly append to an argument list anymore
Whoops, posted the wrong examples. These actually show the difficulty:
> p6 'say() <== map { $_ * 2 } <== 1...10'
(2 4 6 8 10 12 14 16 18 20)
> p6 'say() <== map { $_ * 2 },0 <== 1...10'
(0 20)
So this really looks like an insidious case of accidental one-arg semantics.
[perl #114464] Confusing parsing (and spec?) for my A $a .= new.foo
This works now, due to the precedence changes associated with adding the dot infix operator.
[perl #126049] [BUG] [GLR] Implicitly returning nothing from a subroutine returns an empty container
In C culture, a bare return means "This is a procedure, not a function, and I'm not expecting to return anything", and so I think the absence of a meaningful value is properly conveyed by Nil in Perl 6. If the intent of a return is to allow interpolation of Slip or (), then that choice should be made explicit. Nil is a better default because it doesn't accidentally disappear in an unintended list context. In this sense, Nil can be considered the most basic failure value, designed to trip things up downstream if abused. Roast changes: https://github.com/perl6/roast/commit/cecbb2a9a7
[perl #122395] Mu should smartmatch
Mu ~~ 0 now works but will always return False, since we don't want people to start using Mu as a numeric semipredicate.
[perl #124536] Roast rakudo skip/todo test:./S03-operators/orelse.t line:28 reason: 'orelse passes as multiple arguments'
There's no reason orelse should bind a single undefined value to multiple formals. Test removed with https://github.com/perl6/roast/commit/30f08b143a
[perl #67128] [BUG] Null PMC access when matching against grammar G in module M in a rule in Rakudo
Don't need this, using the Top or other rule name is sufficient.
