Scala 2.10.2-RC1 is now available!

[James Iry]

We are very happy to announce the RC1 release of Scala 2.10.2-RC1  If no serious blocking issues are found this will become the final 2.10.2 version.

The Scala team and contributors fixed 89 issues since 2.10.1!

In total, 164 RC1 pull requests were opened on GitHub, of which 134 were merged after having been tested and reviewed.

Known Issues

Before reporting a bug, please have a look at these known issues.

Scala IDE for Eclipse

The Scala IDE with Scala 2.10.2-RC1 built right in is available through one of the following update-sites:

• for Eclipse 3.7 (Indigo)
• for Eclipse 3.8/4.2 (Juno) (Support for this version is experimental.)

Have a look at the getting started guide for more info.

[Jason Zaugg]

On Sat, May 25, 2013 at 2:54 AM, Rodrigo Cano <ioni...@gmail.com> wrote:

Ok, I managed to reduce the code to about 200 lines of code :). I attached a self contained sbt project with just two files (only dependency is "org.scalatest" %% "scalatest" % "2.0.M5b" % "test" so it should be ok).

In the src you will find the definitions, in the test you will find how the compiler "fails".

[moving to -internals]

Hi Rodrigo,

Thanks for providing the test case. I can confirm that I can reproduce the error. It does not appear to be a regression; it fails uniformly in 2.10.{0, 1, 2-RC1}.

The problem seems unrelated to implicit macros. The compiler has tries two approaches when applying implicit arguments.

First, it searches for implicit arguments, applies them, and type checks the result with the current expected type.

As a fallback, it retypechecks the tree that still requires implicit arguments *without* an expected type, and tries to adapt that by adding implicit arguments.

The problem comes from the "retypechecking" part, right here [1]

Your code nests two anonymous classes.

new Logic {

   new Runnable {

      // implicit search

   }

}

They both have the same name during typer, "$anon", but distinct symbols. The implicit search correctly returns an attributed reference to `"$anon#1".this.myImplicit`. (Attributed means the tree has a Symbol assigned). But in that diff, you see the call to `resetAllAttrs` in the fallback path, which means the tree is stripped of this symbolic reference, and retypechecked, at which point it binds to the closest enclosing "$anon".

Could you please see if you can reduce the test case a little further, to avoid an external dependency on Scalatest, and to avoid implicit macros? It will then be ready to lodge as a ticket.

-jason

[1] https://github.com/scala/scala/commit/d4c63b#L6R804

[Jason Zaugg]

On Sat, May 25, 2013 at 8:36 AM, Jason Zaugg <jza...@gmail.com> wrote:

On Sat, May 25, 2013 at 2:54 AM, Rodrigo Cano <ioni...@gmail.com> wrote:

Ok, I managed to reduce the code to about 200 lines of code :). I attached a self contained sbt project with just two files (only dependency is "org.scalatest" %% "scalatest" % "2.0.M5b" % "test" so it should be ok).

In the src you will find the definitions, in the test you will find how the compiler "fails".

[moving to -internals]

Hi Rodrigo,

Thanks for providing the test case. I can confirm that I can reproduce the error. It does not appear to be a regression; it fails uniformly in 2.10.{0, 1, 2-RC1}.

The problem seems unrelated to implicit macros. The compiler has tries two approaches when applying implicit arguments.

I think my analysis only explains the strange behaviour you noticed with nested anonymous classes. The failure in the last example to fallback to `genericInvalidResponse` might be a distinct issue.

-jason

[Jason Zaugg]

On Sat, May 25, 2013 at 8:53 AM, Jason Zaugg <jza...@gmail.com> wrote:

The problem seems unrelated to implicit macros. The compiler has tries two approaches when applying implicit arguments.

I think my analysis only explains the strange behaviour you noticed with nested anonymous classes. The failure in the last example to fallback to `genericInvalidResponse` might be a distinct issue.

I suspect that issue is caused by:

"the implicit arguments of implicit conversions do not guide type inference"

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

-jason

[Eugene Burmako]

The only question is how come that Rodrigo's scenario worked in 2.10.0 or 2.10.1 (it did, right?).

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jason Zaugg]

On Sat, May 25, 2013 at 9:52 AM, Eugene Burmako <eugene....@epfl.ch> wrote:

The only question is how come that Rodrigo's scenario worked in 2.10.0 or 2.10.1 (it did, right?).

Not for me. But I might have been misreading things.

-jason 

[Eugene Burmako]

Indeed, it fails with the same error in 2.10.1. It also doesn't compile in 2.10.0 because back then internal.SymbolTable didn't have normalizeAliases. Rodrigo, could you please elaborate?

[Rodrigo Cano]

Yes, sorry for the delay.

It did fail too under 2.10, and I attempted to report it back then, and Eugene tried to look into it, but the project was not opensource back then, and there were some dependency issues, so Eugene attempts failed (because of me), and I didn't find the time to reduce it, so it was kinda of assumed that it had to do with implicit macros.

When I saw that implicit macros had been fixed for this release, I tried again to see if it works, and that derived in this mail exchange.

Sorry for misleading you.

I'll try to reduce it further and come back to you later.

Thanks for your time.

[Rodrigo Cano]

> Indeed, it fails with the same error in 2.10.1. It also doesn't compile in 2.10.0 because back then internal.SymbolTable didn't have normalizeAliases. > Rodrigo, could you please elaborate?

With regard to this, that is just a "stringification" of the typelist, its not related to the problem, and as I understood types better (or worse) I've been improving that logic so that it dereferences aliases and stuff to the actual typelist defintion for pretty printing in the genericError implicit macro.

[Jason Zaugg]

On Sat, May 25, 2013 at 7:15 PM, Rodrigo Cano <ioni...@gmail.com> wrote:

Yes, sorry for the delay.

It did fail too under 2.10, and I attempted to report it back then, and Eugene tried to look into it, but the project was not opensource back then, and there were some dependency issues, so Eugene attempts failed (because of me), and I didn't find the time to reduce it, so it was kinda of assumed that it had to do with implicit macros.

When I saw that implicit macros had been fixed for this release, I tried again to see if it works, and that derived in this mail exchange.

Sorry for misleading you.

I'll try to reduce it further and come back to you later.

I've lodged the issue related to nested anonymous classes (or nested same-named classes) leading to spurious rewriting of 'This' trees.

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

I still suspect that your main problem it is unrelated to implicit macros and just to do with implicit views being a little behind the times when it comes to type inference (SI-3346). My advice would be to try to cut down the problem a little more so that others can more quickly take a look at it. There might be alternative ways to express things that sidestep that limitation.

-jason