From carsten.hartenfels@googlemail.com

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 <unit> 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 <unit> at t.pl​:2

  Actually thrown at​:
  in block <unit> 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 <unit> at t.pl​:2

From @lizmat

Fixed with a31cc91a0d604a8a74529 . Tests are still needed

On 19 Oct 2015, at 03​:42, Carsten Hartenfels (via RT) <perl6-bugs-followup@​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.
# <URL​: https://rt-archive.perl.org/perl6/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 <unit> 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 <unit> at t.pl​:2

Actually thrown at​:
in block <unit> 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 <unit> at t.pl​:2

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

From @TimToady

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) <perl6-bugs-
followup@​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.
# <URL​: https://rt-archive.perl.org/perl6/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 <unit> 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 <unit> at t.pl​:2

Actually thrown at​:
in block <unit> 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 <unit> 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).

From @AlexDaniel

jmerelo++, tests added in Raku/roast@ce173d4

Closing

On 2015-10-19 07​:43​:11, larry wrote​:

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) <perl6-bugs-
followup@​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.
# <URL​: https://rt-archive.perl.org/perl6/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 <unit> 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 <unit> at t.pl​:2

Actually thrown at​:
in block <unit> 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 <unit> 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).

@AlexDaniel - Status changed from 'open' to 'resolved'