[perl #131305] Useless Useless Use Warning when invoking colonpaired routines

[Christian Bartolomaeus via RT]

On Wed, 10 Jan 2018 17:32:30 -0800, c...@zoffix.com wrote:
> Thank you for the report. This is now fixed.
> 
> Fix:  https://github.com/rakudo/rakudo/commit/c6b7012a9c61133
> Test: https://github.com/rakudo/rakudo/commit/c6b7012a9c61133

For the records: The Rakudo fix made some previously passing tests die on the 
JVM backend. One example is:

$ ./perl6-j -e 'say infix:["+"](2,3)'
===SORRY!===
setcodeobj can only be used with a CodeRef

I'm not going to reopen this ticket, but I'll add the ticket number to the 
fudge message (so that the connection to Rakudo commit c6b7012a9c61133 is 
clear).

[perl6/specs] 5e5a0c: Center

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 5e5a0c5dbabac0ab3171608e2af56d25c1c973db
  
https://github.com/perl6/specs/commit/5e5a0c5dbabac0ab3171608e2af56d25c1c973db
  Author: Zoffix Znet 
  Date:   2018-01-13 (Sat, 13 Jan 2018)

  Changed paths:
M html/perl-with-historical-message.css

  Log Message:
  ---
  Center 

Getting a neck cramp reading left-aligned 730px  on 1440p/27" monitor

[perl #132711] [LTA] Stupidly using `is assoc` with unary prefix operator has an error message from the deep

[Zoffix Znet via RT]

On Fri, 12 Jan 2018 03:50:19 -0800, c...@zoffix.com wrote:
> This looks to be the same issue as RT#131099. It lists a potential fix
> that fails compilation:
> https://rt.perl.org/Ticket/Display.html?id=131099#txn-1455809

The fix is to throw on attempt to use list assoc on non-infixes, but
there're explosions with many other assocs; looks like anything that isn't 
unary. And
we can't throw on those, because assoc is meant to be used to disambiguate 
between
prefix/postfix that have same precedence.

It explodes in EXPR parser when trying to pop from @termstack. That area is too 
hard
for me right now, so I'm giving up on this ticket, in case anyone else wants to 
give a go...

[perl #132711] [LTA] Stupidly using `is assoc` with unary prefix operator has an error message from the deep

[Zoffix Znet via RT]

On Fri, 12 Jan 2018 03:50:19 -0800, c...@zoffix.com wrote:
> This looks to be the same issue as RT#131099. It lists a potential fix
> that fails compilation:
> https://rt.perl.org/Ticket/Display.html?id=131099#txn-1455809

The fix is to throw on attempt to use list assoc on non-infixes, but
there're explosions with many other assocs; looks like anything that isn't 
unary. And
we can't throw on those, because assoc is meant to be used to disambiguate 
between
prefix/postfix that have same precedence.

It explodes in EXPR parser when trying to pop from @termstack. That area is too 
hard
for me right now, so I'm giving up on this ticket, in case anyone else wants to 
give a go...

[perl #132718] BUG: Unhandled kind 3 with int32 argument

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW it was “working” before this commit:
https://github.com/rakudo/rakudo/commit/ec18f24d27ce61fa71d177ab76c4044ee1d1a75e

But that's probably irrelevant because I'm pretty sure it was cheating with
something.
On 2018-01-13 13:56:54, elizabeth wrote:
>
> > On 13 Jan 2018, at 22:38, Curt Tilmes (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Curt Tilmes
> > # Please include the string: [perl #132718]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=132718 >
> >
> >
> >  m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
> >  rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind
> > 3␤»
>
> FWIW, this also happens for int8 and int16 with different Unhandled
> kind values (1 and 2 respectively).
>
> Casual introspection shows that apparently no support for int8, int16
> or int32 has been added at this level.

[perl #132718] BUG: Unhandled kind 3 with int32 argument

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW it was “working” before this commit:
https://github.com/rakudo/rakudo/commit/ec18f24d27ce61fa71d177ab76c4044ee1d1a75e

But that's probably irrelevant because I'm pretty sure it was cheating with
something.
On 2018-01-13 13:56:54, elizabeth wrote:
>
> > On 13 Jan 2018, at 22:38, Curt Tilmes (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Curt Tilmes
> > # Please include the string: [perl #132718]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=132718 >
> >
> >
> >  m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
> >  rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind
> > 3␤»
>
> FWIW, this also happens for int8 and int16 with different Unhandled
> kind values (1 and 2 respectively).
>
> Casual introspection shows that apparently no support for int8, int16
> or int32 has been added at this level.

Re: [perl #132718] BUG: Unhandled kind 3 with int32 argument

[Elizabeth Mattijsen via RT]

> On 13 Jan 2018, at 22:38, Curt Tilmes (via RT)  
> wrote:
> 
> # New Ticket Created by  Curt Tilmes 
> # Please include the string:  [perl #132718]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132718 >
> 
> 
>  m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
>  rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind 3␤»

FWIW, this also happens for int8 and int16 with different Unhandled kind values 
(1 and 2 respectively).

Casual introspection shows that apparently no support for int8, int16 or int32 
has been added at this level.

Re: [perl #132718] BUG: Unhandled kind 3 with int32 argument

[Elizabeth Mattijsen]

> On 13 Jan 2018, at 22:38, Curt Tilmes (via RT)  
> wrote:
> 
> # New Ticket Created by  Curt Tilmes 
> # Please include the string:  [perl #132718]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132718 >
> 
> 
>  m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
>  rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind 3␤»

FWIW, this also happens for int8 and int16 with different Unhandled kind values 
(1 and 2 respectively).

Casual introspection shows that apparently no support for int8, int16 or int32 
has been added at this level.

[perl #132718] BUG: Unhandled kind 3 with int32 argument

[via RT]

# New Ticket Created by  Curt Tilmes 
# Please include the string:  [perl #132718]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132718 >


 m: sub foo(int32 $x) { say "ok" if $x }; foo(12);
 rakudo-moar f25fdbdf0: OUTPUT: «===SORRY!===␤Unhandled kind 3␤»

[perl #126973] [BUG] No sink warnings when Inf or NaN is in sink context ( ∞ )

[Zoffix Znet via RT]

On Sat, 19 Dec 2015 20:29:14 -0800, alex.jakime...@gmail.com wrote:
> Code:
> ∞
> 
> Result:
> (no output)
> 
> Same thing with NaN and Inf. I was expecting a warning.
> 
> Something like this:
> 
> Code:
> 42
> 
> Result:
> WARNINGS for -e:
> Useless use of constant integer 42 in sink context (line 1)


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/e9c9dc4695495ac
Test: https://github.com/perl6/roast/commit/6869312c030f1df3a

[perl #126973] [BUG] No sink warnings when Inf or NaN is in sink context ( ∞ )

[Zoffix Znet via RT]

On Sat, 19 Dec 2015 20:29:14 -0800, alex.jakime...@gmail.com wrote:
> Code:
> ∞
> 
> Result:
> (no output)
> 
> Same thing with NaN and Inf. I was expecting a warning.
> 
> Something like this:
> 
> Code:
> 42
> 
> Result:
> WARNINGS for -e:
> Useless use of constant integer 42 in sink context (line 1)


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/e9c9dc4695495ac
Test: https://github.com/perl6/roast/commit/6869312c030f1df3a

[perl #128692] [BUG] useless uses of "useless use ... in sink context" warning in sink context

[Zoffix Znet via RT]

On Thu, 21 Jul 2016 09:20:38 -0700, ajs wrote:
> The core issue is this simple code:
> 
> my @a = lazy gather { say 'we actually run' }; sink @a;
> 
> Which gives:
> 
> OUTPUT«WARNINGS for :␤Useless use of @a in sink context (line 1)␤we
> actually run␤»
> 
> Note that if you insert "quietly" before sink, it still gives the warning,
> which is also questionable.
> 
> From the discussion on IRC:
> 
> 
> [11:59]  Speaking of sink, I'm not convinced that the warning for
> useless use of iterables in sink context should be a thing. e.g.:
> [11:59]  m: sink ^1000
> [11:59] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of "^" in expression "^1000" in sink context (line 1)␤»
> [12:00]  I'm explicitly asking for the expansion of the sequence to
> be performed and ignored. That's not something that should get a warning,
> is it?
> [12:00]  I don't think it's a warning for iterables in general
> [12:00]  It's for a useless use of the (known pure) range constructor
> [12:01]  m: sink 1, 1, *+* ... 8
> [12:01] <+camelia> rakudo-moar 86843a: ( no output )
> [12:01]  Note no warning there
> [12:02]  m: my @foo = 1,1,*+*...8; sink @foo
> [12:02] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @foo in sink context (line 1)␤»
> [12:03]  The assignment to the array is already eager in that case
> [12:05]  jnthn: that's not why we get the warning. I won't do the
> version with 8 replaced by * as it never terminates, but it also gives the
> warning.
> [12:06]  m: sink 1, 1, *+* ... *
> [12:06] <+camelia> rakudo-moar 86843a: OUTPUT«Memory allocation failed;
> could not allocate 1146880 bytes␤»
> [12:06]  m: my @foo = 1,1,*+*...8; sink @foo;
> [12:06] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @foo in sink context (line 1)␤»
> [12:06]  But that terminates.
> [12:07]  It just feels to me as if "sink" means "just do it" and
> getting a warning that "it" isn't useful just doesn't sit well with me.
> YMMV.
> [12:08]  It's not telling you it isn't useful, it's telling you
> there's nothing to do and you wrote dead code.
> [12:09]  Which the vast majority of the time implies a confused
> programmer.
> [12:09]  Except it doesn't know that. @a might be anything, and
> iterating over it might be extremely useful (e.g. it might do a full read
> from a DB, and I might be timing that)
> [12:09]  m: quietly sink ^1000
> [12:09] <+camelia> rakudo-moar 86843a: ( no output )
> [12:10]  m: my @a = lazy gather { say 'we actually run' }; sink @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @a in sink context (line 1)␤we actually run␤»
> [12:10]  Nice example.
> [12:10]  m: my @a = lazy gather { say 'we actually run' };
> quietly sink @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @a in sink context (line 1)␤we actually run␤»
> [12:10]  Yeah, that one is more interesting, but now I want to know
> why the ... one up above didn't hang
> [12:10]  m: my @a = lazy gather { say 'we actually run' }; sink
> quietly @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @a in sink context (line 1)␤we actually run␤»
> [12:11]  oh wait, 'cus I wrote it wrong
> [12:11]  Interesting.
> [12:11]  m: my @foo = 1,1,*+*...*; sink @foo;
> [12:11] <+camelia> rakudo-moar 86843a: OUTPUT«(signal SEGV)WARNINGS for
> :␤Useless use of @foo in sink context (line 1)␤»
> [12:11]  Yeah, I'd agree on a variable it's rather dubious.
> [12:11]  You get the segv award!
> [12:12]  On sink ^1000 I think it's spot on
> [12:12]  Yeah, at best ^n is just a weird sort of timing test, and
> I could reasonably expect to have to quiet that manually.
> [12:12]  But yeah, feel free to file it against the @foo case. That
> does look a bit bogus
> [12:12]  And I might expect that the optimizer would not be my
> friend there
> 
> --
> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/99da4a5a6c45244
Test: https://github.com/rakudo/rakudo/commit/99da4a5a6c45244

[perl #128692] [BUG] useless uses of "useless use ... in sink context" warning in sink context

[Zoffix Znet via RT]

On Thu, 21 Jul 2016 09:20:38 -0700, ajs wrote:
> The core issue is this simple code:
> 
> my @a = lazy gather { say 'we actually run' }; sink @a;
> 
> Which gives:
> 
> OUTPUT«WARNINGS for :␤Useless use of @a in sink context (line 1)␤we
> actually run␤»
> 
> Note that if you insert "quietly" before sink, it still gives the warning,
> which is also questionable.
> 
> From the discussion on IRC:
> 
> 
> [11:59]  Speaking of sink, I'm not convinced that the warning for
> useless use of iterables in sink context should be a thing. e.g.:
> [11:59]  m: sink ^1000
> [11:59] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of "^" in expression "^1000" in sink context (line 1)␤»
> [12:00]  I'm explicitly asking for the expansion of the sequence to
> be performed and ignored. That's not something that should get a warning,
> is it?
> [12:00]  I don't think it's a warning for iterables in general
> [12:00]  It's for a useless use of the (known pure) range constructor
> [12:01]  m: sink 1, 1, *+* ... 8
> [12:01] <+camelia> rakudo-moar 86843a: ( no output )
> [12:01]  Note no warning there
> [12:02]  m: my @foo = 1,1,*+*...8; sink @foo
> [12:02] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @foo in sink context (line 1)␤»
> [12:03]  The assignment to the array is already eager in that case
> [12:05]  jnthn: that's not why we get the warning. I won't do the
> version with 8 replaced by * as it never terminates, but it also gives the
> warning.
> [12:06]  m: sink 1, 1, *+* ... *
> [12:06] <+camelia> rakudo-moar 86843a: OUTPUT«Memory allocation failed;
> could not allocate 1146880 bytes␤»
> [12:06]  m: my @foo = 1,1,*+*...8; sink @foo;
> [12:06] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @foo in sink context (line 1)␤»
> [12:06]  But that terminates.
> [12:07]  It just feels to me as if "sink" means "just do it" and
> getting a warning that "it" isn't useful just doesn't sit well with me.
> YMMV.
> [12:08]  It's not telling you it isn't useful, it's telling you
> there's nothing to do and you wrote dead code.
> [12:09]  Which the vast majority of the time implies a confused
> programmer.
> [12:09]  Except it doesn't know that. @a might be anything, and
> iterating over it might be extremely useful (e.g. it might do a full read
> from a DB, and I might be timing that)
> [12:09]  m: quietly sink ^1000
> [12:09] <+camelia> rakudo-moar 86843a: ( no output )
> [12:10]  m: my @a = lazy gather { say 'we actually run' }; sink @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @a in sink context (line 1)␤we actually run␤»
> [12:10]  Nice example.
> [12:10]  m: my @a = lazy gather { say 'we actually run' };
> quietly sink @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @a in sink context (line 1)␤we actually run␤»
> [12:10]  Yeah, that one is more interesting, but now I want to know
> why the ... one up above didn't hang
> [12:10]  m: my @a = lazy gather { say 'we actually run' }; sink
> quietly @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for :␤Useless
> use of @a in sink context (line 1)␤we actually run␤»
> [12:11]  oh wait, 'cus I wrote it wrong
> [12:11]  Interesting.
> [12:11]  m: my @foo = 1,1,*+*...*; sink @foo;
> [12:11] <+camelia> rakudo-moar 86843a: OUTPUT«(signal SEGV)WARNINGS for
> :␤Useless use of @foo in sink context (line 1)␤»
> [12:11]  Yeah, I'd agree on a variable it's rather dubious.
> [12:11]  You get the segv award!
> [12:12]  On sink ^1000 I think it's spot on
> [12:12]  Yeah, at best ^n is just a weird sort of timing test, and
> I could reasonably expect to have to quiet that manually.
> [12:12]  But yeah, feel free to file it against the @foo case. That
> does look a bit bogus
> [12:12]  And I might expect that the optimizer would not be my
> friend there
> 
> --
> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/99da4a5a6c45244
Test: https://github.com/rakudo/rakudo/commit/99da4a5a6c45244

[perl #131331] [BUG] Wrong useless use warning in grep + try + after

[Zoffix Znet via RT]

On Sat, 13 Jan 2018 00:09:32 -0800, c...@zoffix.com wrote:
> On Fri, 19 May 2017 15:24:06 -0700, c...@zoffix.com wrote:
> >  m: ^2 .grep: {try 1 after 0}
> >  rakudo-moar a7c23a: OUTPUT: «WARNINGS for :␤Useless use
> > of "after" in expression "1 after 0" in sink context (line 1)␤»
> 
> 
> Thank you for the report. This is now fixed.
> 
> Fix:  https://github.com/rakudo/rakudo/commit/728acf597cf31fb
> Test: https://github.com/rakudo/rakudo/commit/728acf597cf31fb


Correction:

Fix:  https://github.com/rakudo/rakudo/commit/ef2dc1b8ba7d45b
Test: https://github.com/rakudo/rakudo/commit/ef2dc1b8ba7d45b

[perl #131331] [BUG] Wrong useless use warning in grep + try + after

[Zoffix Znet via RT]

On Sat, 13 Jan 2018 00:09:32 -0800, c...@zoffix.com wrote:
> On Fri, 19 May 2017 15:24:06 -0700, c...@zoffix.com wrote:
> >  m: ^2 .grep: {try 1 after 0}
> >  rakudo-moar a7c23a: OUTPUT: «WARNINGS for :␤Useless use
> > of "after" in expression "1 after 0" in sink context (line 1)␤»
> 
> 
> Thank you for the report. This is now fixed.
> 
> Fix:  https://github.com/rakudo/rakudo/commit/728acf597cf31fb
> Test: https://github.com/rakudo/rakudo/commit/728acf597cf31fb


Correction:

Fix:  https://github.com/rakudo/rakudo/commit/ef2dc1b8ba7d45b
Test: https://github.com/rakudo/rakudo/commit/ef2dc1b8ba7d45b

[perl #131123] [BUG] Useless use of useless use in smartmatch + block + try

[Zoffix Znet via RT]

On Sat, 13 Jan 2018 00:09:49 -0800, c...@zoffix.com wrote:
> On Fri, 14 Apr 2017 14:12:54 -0700, fernandocor...@gmail.com wrote:
> > Em Fri, 07 Apr 2017 19:59:42 -0700, c...@zoffix.com escreveu:
> > >
> > >  m: say so 42 ~~ { try $_ == 5 }
> > >  rakudo-moar af50e0: OUTPUT: «WARNINGS for :␤Useless
> > > use
> > > of "==" in expression "$_ == 5" in sink context (line 1)␤False␤»
> > >
> > >  m: say so 42 ~~ { $_ == 5 }
> > >  rakudo-moar af50e0: OUTPUT: «False␤»
> > 
> > 
> > I think the problem is only with block + try...
> > 
> >  m: say {try 5 == 5}()
> >  combined, experimental evalbot rakudo-moar 7f73f9: OUTPUT:
> > «WARNINGS for :␤Useless use of "==" in expression "5 == 5" in
> > sink context (line 1)␤True␤»
> 
> 
> Thank you for the report. This is now fixed.
> 
> Fix:  https://github.com/rakudo/rakudo/commit/728acf597cf31fb
> Test: https://github.com/rakudo/rakudo/commit/728acf597cf31fb


Correction:

Fix:  https://github.com/rakudo/rakudo/commit/ef2dc1b8ba7d45b
Test: https://github.com/rakudo/rakudo/commit/ef2dc1b8ba7d45b

[perl #131123] [BUG] Useless use of useless use in smartmatch + block + try

[Zoffix Znet via RT]

On Sat, 13 Jan 2018 00:09:49 -0800, c...@zoffix.com wrote:
> On Fri, 14 Apr 2017 14:12:54 -0700, fernandocor...@gmail.com wrote:
> > Em Fri, 07 Apr 2017 19:59:42 -0700, c...@zoffix.com escreveu:
> > >
> > >  m: say so 42 ~~ { try $_ == 5 }
> > >  rakudo-moar af50e0: OUTPUT: «WARNINGS for :␤Useless
> > > use
> > > of "==" in expression "$_ == 5" in sink context (line 1)␤False␤»
> > >
> > >  m: say so 42 ~~ { $_ == 5 }
> > >  rakudo-moar af50e0: OUTPUT: «False␤»
> > 
> > 
> > I think the problem is only with block + try...
> > 
> >  m: say {try 5 == 5}()
> >  combined, experimental evalbot rakudo-moar 7f73f9: OUTPUT:
> > «WARNINGS for :␤Useless use of "==" in expression "5 == 5" in
> > sink context (line 1)␤True␤»
> 
> 
> Thank you for the report. This is now fixed.
> 
> Fix:  https://github.com/rakudo/rakudo/commit/728acf597cf31fb
> Test: https://github.com/rakudo/rakudo/commit/728acf597cf31fb


Correction:

Fix:  https://github.com/rakudo/rakudo/commit/ef2dc1b8ba7d45b
Test: https://github.com/rakudo/rakudo/commit/ef2dc1b8ba7d45b

[perl #131123] [BUG] Useless use of useless use in smartmatch + block + try

[Zoffix Znet via RT]

On Fri, 14 Apr 2017 14:12:54 -0700, fernandocor...@gmail.com wrote:
> Em Fri, 07 Apr 2017 19:59:42 -0700, c...@zoffix.com escreveu:
> >
> >  m: say so 42 ~~ { try $_ == 5 }
> >  rakudo-moar af50e0: OUTPUT: «WARNINGS for :␤Useless
> > use
> > of "==" in expression "$_ == 5" in sink context (line 1)␤False␤»
> >
> >  m: say so 42 ~~ { $_ == 5 }
> >  rakudo-moar af50e0: OUTPUT: «False␤»
> 
> 
> I think the problem is only with block + try...
> 
>  m: say {try 5 == 5}()
>  combined, experimental evalbot rakudo-moar 7f73f9: OUTPUT:
> «WARNINGS for :␤Useless use of "==" in expression "5 == 5" in
> sink context (line 1)␤True␤»


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/728acf597cf31fb
Test: https://github.com/rakudo/rakudo/commit/728acf597cf31fb

[perl #131123] [BUG] Useless use of useless use in smartmatch + block + try

[Zoffix Znet via RT]

On Fri, 14 Apr 2017 14:12:54 -0700, fernandocor...@gmail.com wrote:
> Em Fri, 07 Apr 2017 19:59:42 -0700, c...@zoffix.com escreveu:
> >
> >  m: say so 42 ~~ { try $_ == 5 }
> >  rakudo-moar af50e0: OUTPUT: «WARNINGS for :␤Useless
> > use
> > of "==" in expression "$_ == 5" in sink context (line 1)␤False␤»
> >
> >  m: say so 42 ~~ { $_ == 5 }
> >  rakudo-moar af50e0: OUTPUT: «False␤»
> 
> 
> I think the problem is only with block + try...
> 
>  m: say {try 5 == 5}()
>  combined, experimental evalbot rakudo-moar 7f73f9: OUTPUT:
> «WARNINGS for :␤Useless use of "==" in expression "5 == 5" in
> sink context (line 1)␤True␤»


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/728acf597cf31fb
Test: https://github.com/rakudo/rakudo/commit/728acf597cf31fb

[perl #131331] [BUG] Wrong useless use warning in grep + try + after

[Zoffix Znet via RT]

On Fri, 19 May 2017 15:24:06 -0700, c...@zoffix.com wrote:
>  m: ^2 .grep: {try 1 after 0}
>  rakudo-moar a7c23a: OUTPUT: «WARNINGS for :␤Useless use
> of "after" in expression "1 after 0" in sink context (line 1)␤»


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/728acf597cf31fb
Test: https://github.com/rakudo/rakudo/commit/728acf597cf31fb

[perl #131331] [BUG] Wrong useless use warning in grep + try + after

[Zoffix Znet via RT]

On Fri, 19 May 2017 15:24:06 -0700, c...@zoffix.com wrote:
>  m: ^2 .grep: {try 1 after 0}
>  rakudo-moar a7c23a: OUTPUT: «WARNINGS for :␤Useless use
> of "after" in expression "1 after 0" in sink context (line 1)␤»


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/728acf597cf31fb
Test: https://github.com/rakudo/rakudo/commit/728acf597cf31fb