Strange behavior of Set4 in scala 2.9.1?

Question

Making a migration from 2.8.1 to 2.9.1 found interesting thing. Tried to write this in console:

>>import collection.immutable.Set.Set4
>>new Set4[Int](1,2,3,4)

It gives:

java.lang.Error: Unexpected New
    at scala.tools.nsc.symtab.SymbolTable.abort(SymbolTable.scala:34)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$bac
..........................
That entry seems to have slain the compiler.  Shall I replayscala:660)
your session? I can re-run each line except the last one.reach(ListBuffer.scala:
[y/n]?

I am using Scala version 2.9.1.final (Java HotSpot(TM) Client VM, Java 1.6.0_26).
And same things happen with classes Set3 and Set2.
Are these known issues?
Or, maybe, I am making something wrong?
In scala 2.8.1 console it works, and returns:

res0: collection.immutable.Set.Set4[Int] = Set(1,2,3,4)

Must I report about these as bug?

Conscription

Is there a reason you use Set4 directly? – Asepsis

Yes, I want to have a key with four integers, that will be frequently used with Set operations(as |,&,&~), because of it wanted to have an object with optimized implementation. – Conscription

Set(1,2,3,4).isInstanceOf[collection.immutable.Set.Set4[Int]] == true this happens automatically already. – Asepsis

Cool, thanks, works perfect. If there is no reason to direct call, why we could import Set2, Set3 and Set4 to scope and use them directly? – Conscription

I can't think of one, except less method forwarding :-) – Asepsis

Answer 1

Yes. This is a compiler bug, go ahead and report it.

Laural

(Verified on 2.10. Don't forget to post the issue number here again :D) – Asepsis

Thanks! If I want to participate in resolving SI bugs, how I must start? – Conscription

If you really feel like you can do compiler hacking, just try debugging the issue, just as it were a bug in a project of yours, and post your results as comments to the thread. – Tergum

If, instead, you want to write a more helpful bug report, you can start by giving a complete stack trace, verifying if the bug is current on a current snapshot - or at least telling the authors that it was verified by somebody. Also, I feel like the information should be given in the bug report, not through a link to this site. Extract all the relevant information (e.g. it worked on Scala 2.8.1), and only that. See also: #240823 – Tergum

A final possibility is that you might also start using git bisect on this repo (github.com/scala/scala) to discover when the bug was introduced. But that's already quite some work. – Tergum