Infinite loop in scala.reflect.internal.Types$TypeVar.isGround

[Eugene Burmako]

Guys we have a fresh bug that looks serious: https://issues.scala-lang.org/browse/SI-6499.
Take a look.

[Paul Phillips]

On Tue, Oct 9, 2012 at 11:54 PM, Eugene Burmako <eugene....@epfl.ch> wrote:
> Guys we have a fresh bug that looks serious: https://issues.scala-lang.org/browse/SI-6499.

It's an old bug with mutually recursive typevars. I don't think it's
any more serious than the other few thousand.

[Eugene Burmako]

As discussed in JIRA, this is a regression since M7

On Oct 10, 9:02 am, Paul Phillips <pa...@improving.org> wrote:

[Josh Suereth]

This one breaks the scalatest ant build.  It's an issue with too much inference and existential types.

[Paul Phillips]

On Wed, Oct 10, 2012 at 2:52 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
> As discussed in JIRA, this is a regression since M7

Sorry, by "old" I meant the stack trace. If it's a regression then
that's good news because it makes it easy to pinpoint. Man, this
thing is a godsend.

You can just revert the bad commit if you want - it is only for performance.

% scala-bisector v2.10.0-M7 2.10.0-wip $(pwd)/a.scala
Logs in /var/folders/1w/zm_1vksn3y7gn127bkwt841w0000gn/T/scala-bisect.p5F1w0qy
Bisecting: 267 revisions left to test after this (roughly 8 steps)
[9bcb335b8a08edb5cd88408e3f5be3fee6a7ca88] Merge pull request #1318
from odersky/ticket/6336
reconstructed args: -d
/var/folders/1w/zm_1vksn3y7gn127bkwt841w0000gn/T/scala-bisect.p5F1w0qy/out
[9bcb335b8a] bad
Bisecting: 132 revisions left to test after this (roughly 7 steps)
[ab5a9bbfb1e89764dacf6b5ea357a54ea4bb0479] Merge pull request #1266
from scalamacros/topic/removes-isconcrete
[ab5a9bbfb1] good
Bisecting: 66 revisions left to test after this (roughly 6 steps)
[5f674e44c5d3dccb55ce080c60d92b8e412d03ac] Rescued TreeBuilder from the parser.
[5f674e44c5] good
Bisecting: 32 revisions left to test after this (roughly 5 steps)
[83c1b1062957e50e5336c1b3409e54e0a5cce275] Merge pull request #1303
from paulp/210-relative-names
reconstructed args: -d
/var/folders/1w/zm_1vksn3y7gn127bkwt841w0000gn/T/scala-bisect.p5F1w0qy/out
[83c1b10629] bad
Bisecting: 16 revisions left to test after this (roughly 4 steps)
[f4a722d20547a5b4ffe47405d122b34b586c17c3] SI-6310 AbsTypeTag => WeakTypeTag
reconstructed args: -d
/var/folders/1w/zm_1vksn3y7gn127bkwt841w0000gn/T/scala-bisect.p5F1w0qy/out
[f4a722d205] bad
Bisecting: 8 revisions left to test after this (roughly 3 steps)
[76d4e9a8071f9e102106696664376b7f70622582] Merge pull request #1293
from jsuereth/fix/binary-push
reconstructed args: -d
/var/folders/1w/zm_1vksn3y7gn127bkwt841w0000gn/T/scala-bisect.p5F1w0qy/out
[76d4e9a807] bad
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[20f701bf504530cb12e9d24e2dd66fa42244664d] Merge pull request #1296
from paulp/210-errors-and-trees
[20f701bf50] good
Bisecting: 1 revision left to test after this (roughly 1 step)
[33ba866fd22a4a5542ae5e4dae8de8bf8d8ab2aa] Merge pull request #1294
from paulp/issue/6367
reconstructed args: -d
/var/folders/1w/zm_1vksn3y7gn127bkwt841w0000gn/T/scala-bisect.p5F1w0qy/out
[33ba866fd2] bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[6fbb4ac42a3fa00689a6c3bbde2be273b7c36b2d] Fix for SI-6367,
exponential time in inference.
reconstructed args: -d
/var/folders/1w/zm_1vksn3y7gn127bkwt841w0000gn/T/scala-bisect.p5F1w0qy/out
[6fbb4ac42a] bad
Bisecting: a merge base must be tested
[7e1f10d228c1f0c47db4f2136dda4b5690f43445] Merge pull request #1288
from jsuereth/fix/SI-6268
[7e1f10d228] good
6fbb4ac42a3fa00689a6c3bbde2be273b7c36b2d is the first bad commit
commit 6fbb4ac42a3fa00689a6c3bbde2be273b7c36b2d
Author: Paul Phillips <pa...@improving.org>
Date: Wed Sep 12 12:02:07 2012 -0700

Fix for SI-6367, exponential time in inference.

This pathology is not new - it can be witnessed in 2.9,
where compiling the test case enclosed with this ticket with
-Yinfer-debug will print a line with (pinky to lips) one million
type parameters. 1048576 actually, aka 2^20. But in 2.9 we were
somehow getting away with creating the list, presumably by not
spending much time looking at it. Somewhere between there and M1,
that changed.

I cut it off at the knees - don't create a list of one million
upper bound constraints when 1 will suffice. It would not be too
surprising if this proves to be a boon for performance.

:040000 040000 3df6f440a0518a6d3c4a8d1a3a2ca3e94570380d
d42041e590976bf5ff39d4d759316bf21c5b0283 M src
:040000 040000 cc965e355e131ce403c92ddc4a625d50a18abced
e9b951f4ad634447cc3738cc5aa536c0169b951b M test

[Paul Phillips]

And since even the abbreviated transcript kind of buries it:

[Paul Phillips]

On Wed, Oct 10, 2012 at 6:51 AM, Paul Phillips <pa...@improving.org> wrote:
> You can just revert the bad commit if you want - it is only for performance.

I better take that back - I forgot the motivation was this:

https://issues.scala-lang.org/browse/SI-6367

So I'll look at it.

[Eugene Burmako]

Could you share the sources of scala-bisector? Didn't find it at libscala.

[Paul Phillips]

On Wed, Oct 10, 2012 at 6:59 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
> Could you share the sources of scala-bisector? Didn't find it at libscala.

Yes - but I'd sure like not to have to maintain it. I'll make my twin
ambitions today publishing that macro code and adding that to
libscala.

[Josh Suereth]

Does this mean I should assign https://issues.scala-lang.org/browse/SI-6499 to you?   I'm cutting an RC1 tomorrow, come hell or high water, so if we can get a fix by tomorrow, that'd be great.  Otherwise this one gets to be a "known issue" until 2.10.1.

- Josh

[Paul Phillips]

On Wed, Oct 10, 2012 at 6:59 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
> Could you share the sources of scala-bisector? Didn't find it at libscala.

Okay, don't say I never did anything for you... (see attached.) Will
be committing to libscala soon.

[Paul Phillips]

Okay, it is pushed:

https://github.com/paulp/libscala

It is possible this won't work out of the box if you aren't me,
because I don't have strong partitioning between my personal ~/bin and
what's in libscala, so it would be easy for me to have let an
only-satisfiable-at-my-house dependency creep in. Please let me know
if that's the case.

[Paul Phillips]

On Wed, Oct 10, 2012 at 9:34 AM, Josh Suereth <joshua....@gmail.com> wrote:
> Does this mean I should assign https://issues.scala-lang.org/browse/SI-6499
> to you? I'm cutting an RC1 tomorrow, come hell or high water, so if we can
> get a fix by tomorrow, that'd be great. Otherwise this one gets to be a
> "known issue" until 2.10.1.

Looking at it now.

[Eugene Burmako]

This is very much appreciated and has excellent timing!

I just got my new laptop, so I'll be able to test it without doing dances with cygwin (will try to do that today).

[Josh Suereth]

Rock on.  Thanks much man!

[Paul Phillips]

Nothing against anyone, but all the TypeVar/TypeConstraint code should be taken behind the barn and shot until the ammunition is exhausted.

I might have fixed it, testing now.

[Eugene Burmako]

I finally got my hands on scala-bisector and libscala in general.

1) As I feared, I had to abandon zsh and downgrade to bash. Zsh can
work with bash completions, and it can even run bash scripts in
compatibility mode, but the latter is not perfect. Having BASH_SOURCE
sprinkled around (even in the scalac script) certainly didn't help.

2) No idea how scala-bisector is supposed to work, but it looks like
it doesn't like empty SCALA_PACKS_DIR. Maybe I misunderstand the
internal workings of bisect, but since every sha in an empty packs dir
doesn't have corresponding binaries, the script keeps invoking "bisect
skip yellow skipped", which leads to it *seemingly* randomly
downloading binaries without stopping. Why not write something like
"if [[ ! -f "$runner" ]]; then <download scala distro> fi"?

3) Finally, I managed to break the bisector:
https://lh5.googleusercontent.com/-PHRmrFVjxqg/UHsiOsNzaWI/AAAAAAAAAy4/I5oxvSyxeSY/s682/Screen+Shot+2012-10-14+at+22.34.44+.png.

On Oct 10, 7:08 pm, Paul Phillips <pa...@improving.org> wrote:

> On Wed, Oct 10, 2012 at 6:59 AM, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
> > Could you share the sources of scala-bisector? Didn't find it at libscala.
>
> Okay, don't say I never did anything for you... (see attached.) Will
> be committing to libscala soon.
>

>  bisect.png
> 470KViewDownload

[Paul Phillips]

On Sun, Oct 14, 2012 at 1:37 PM, Eugene Burmako <eugene....@epfl.ch> wrote:
> I finally got my hands on scala-bisector and libscala in general.
>
> 1) As I feared, I had to abandon zsh and downgrade to bash.

"libscala: bash-centric tools for scala developers"

That's the actual tagline on github.

> downloading binaries without stopping. Why not write something like
> "if [[ ! -f "$runner" ]]; then <download scala distro> fi"?

It has to do something with the many commits for which there is no build or there is no working build.

You know how to send pull requests.  If it doesn't break it for me, then I'll most likely include it.

> 3) Finally, I managed to break the bisector:
> https://lh5.googleusercontent.com/-PHRmrFVjxqg/UHsiOsNzaWI/AAAAAAAAAy4/I5oxvSyxeSY/s682/Screen+Shot+2012-10-14+at+22.34.44+.png.

I don't know what I'm supposed to see, but I attached a screenshot of what's at that link for, presumably, everyone who isn't you.

But if it's showing some brokenness, okay, it's not real shocking - I've given every indication this is not  a primary interest of mine.  I got it working for me; it's someone else's turn to move the ball forward.

[Eugene Burmako]

Strange, I thought G+ works for everyone (I even tested it in a browser that's not logged into my google account). Here's another take on publishing the screenshot: https://dl.dropbox.com/u/10497693/Screen%20Shot%202012-10-14%20at%2022.34.44%20.png

[Paul Phillips]

On Sun, Oct 14, 2012 at 2:38 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

Strange, I thought G+ works for everyone (I even tested it in a browser that's not logged into my google account). Here's another take on publishing the screenshot: https://dl.dropbox.com/u/10497693/Screen%20Shot%202012-10-14%20at%2022.34.44%20.png

As it suggests, it will be confused if bad revs seem to precede good revs.  It would be easier to say something about it if I knew what was in the test source.

[Eugene Burmako]

object Test {
  Map(): Map[_, Int] with Map[_, Int]
}

https://github.com/scalamacros/kepler/tree/zzz/topic/reflection

Tomorrow I'll try to re-test with an empty packs dir and an up-to-date branch.