in some cases wrong multi candidates are selected #5312
Comments
From @usev6The following code from S03-metaops/hyper.t dies on rakudo-j: $ perl6-j -e '[[2, 3], [4, [5, 6]]]».combinations.gist' Output with --ll-exception: $ perl6-j --ll-exception -e '[[2, 3], [4, [5, 6]]]».combinations.gist' I did a bisect and it breaks with commit rakudo/rakudo@b5c041a6ca -- namely the changes to lines 45 and 46 (changing postfix:<++> to prefix:<++> cause the error. |
From @lizmatDoesn’t this imply that prefix ++ on native ints is broken on the JVM. And thus, a lot of more got broken recently due to my changes?? Liz
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @lizmatReverted for JVM in d9b19da , but I think this warrants further research.:
|
From @usev6On Wed May 11 00:51:48 2016, elizabeth wrote:
That was my first thought, too. But this was the only place where rakudo-j got a hickup. Prefix++ works fine in different other places (and you changed some other postfix++ to prefix++ recently, IIRC). Probably this is another bug surfacing. On Wed May 11 00:59:24 2016, elizabeth wrote:
Thanks, Liz! I already tried to find the cause of the problem before I opened the ticket, but without success. However, we'll keep this ticket open until the problem has be resolved. |
From @usev6I found another strange test failure on rakudo-j related to the use The test in isolation works fine, but the failure happens in ====
|
1 similar comment
From @usev6I found another strange test failure on rakudo-j related to the use The test in isolation works fine, but the failure happens in ====
|
From @usev6I found another strange failure which dies the same way. The error happens in S32-list/combinations.t and can be golfed down to this: $ ./perl6-j -e 'say (1).combinations(0..1); say ().combinations' Like my original report this happens while using 'combinations' (this time as a method). Even if this one blows up in postfix:<++> I believe there is the same bug surfacing. Therefore I use this ticket to report the new error. I didn't bisect yet, but 78ba3df7e1 was still good and bc722abe2c was already bad. Note, that there is an NQP bump in between. $ perl6-j --ll-exception -e 'say (1).combinations(0..1); say ().combinations' |
1 similar comment
From @usev6I found another strange failure which dies the same way. The error happens in S32-list/combinations.t and can be golfed down to this: $ ./perl6-j -e 'say (1).combinations(0..1); say ().combinations' Like my original report this happens while using 'combinations' (this time as a method). Even if this one blows up in postfix:<++> I believe there is the same bug surfacing. Therefore I use this ticket to report the new error. I didn't bisect yet, but 78ba3df7e1 was still good and bc722abe2c was already bad. Note, that there is an NQP bump in between. $ perl6-j --ll-exception -e 'say (1).combinations(0..1); say ().combinations' |
From @usev6On Sun May 22 01:55:32 2016, bartolin@gmx.de wrote:
The test from integration/weird-errors.t passes again. I didn't bisect yet, but I suspect it passes due to the recent changes to src/core/Any-iterable-methods.pm with commit 4c773b1e0e. |
From @usev6And now a lot of tests from roast exploded with "Expected a native int argument for '$a'" after this commit introduced two uses of postfix:<++> and postfix:<--> in lib/Test.pm6: rakudo/rakudo@ffb5789 Modifying the two relevant lines seems to fix those failures (did not run full spectest yet): Inline Patchdiff --git a/lib/Test.pm6 b/lib/Test.pm6
index 45bb86f..5d052e9 100644
--- a/lib/Test.pm6
+++ b/lib/Test.pm6
@@ -339,9 +339,9 @@ multi sub subtest(&subtests, $desc = '') is export {
_push_vars();
_init_vars();
$indents ~= " ";
- $subtest_level++;
+ $subtest_level += 1;
subtests();
- $subtest_level--;
+ $subtest_level -= 1;
done-testing() if nqp::iseq_i($done_testing_has_been_run,0);
my $status =
$num_of_tests_failed == 0 && $num_of_tests_planned == $num_of_tests_run; |
1 similar comment
From @usev6And now a lot of tests from roast exploded with "Expected a native int argument for '$a'" after this commit introduced two uses of postfix:<++> and postfix:<--> in lib/Test.pm6: rakudo/rakudo@ffb5789 Modifying the two relevant lines seems to fix those failures (did not run full spectest yet): Inline Patchdiff --git a/lib/Test.pm6 b/lib/Test.pm6
index 45bb86f..5d052e9 100644
--- a/lib/Test.pm6
+++ b/lib/Test.pm6
@@ -339,9 +339,9 @@ multi sub subtest(&subtests, $desc = '') is export {
_push_vars();
_init_vars();
$indents ~= " ";
- $subtest_level++;
+ $subtest_level += 1;
subtests();
- $subtest_level--;
+ $subtest_level -= 1;
done-testing() if nqp::iseq_i($done_testing_has_been_run,0);
my $status =
$num_of_tests_failed == 0 && $num_of_tests_planned == $num_of_tests_run; |
From @usev6All code examples from above are running fine now. Instead there are four skipped tests in S32-array/adverbs.t which die because the wrong multi postcircumfix:<[ ]> is selected. I'll change the subject of this ticket and leave it open to collect those weird errors about wrong multi candidates used. |
1 similar comment
From @usev6All code examples from above are running fine now. Instead there are four skipped tests in S32-array/adverbs.t which die because the wrong multi postcircumfix:<[ ]> is selected. I'll change the subject of this ticket and leave it open to collect those weird errors about wrong multi candidates used. |
From @usev6On Tue, 13 Sep 2016 12:42:03 -0700, bartolin@gmx.de wrote:
And now the tests in S32-array/adverbs.t are also passing. I'm closing this ticket as 'resolved' -- even if I neither know what caused the breakage nor what fixed it. |
|
@usev6 - Status changed from 'open' to 'resolved' |
From @usev6Just for the records: As far as I can tell, the bug that caused the above failures was an "off by one" in the multi cache implementation. It was fixed with Raku/nqp@7eaebf5abd |
1 similar comment
From @usev6Just for the records: As far as I can tell, the bug that caused the above failures was an "off by one" in the multi cache implementation. It was fixed with Raku/nqp@7eaebf5abd |
Migrated from rt.perl.org#128123 (status was 'resolved')
Searchable as RT128123$
The text was updated successfully, but these errors were encountered: