Possible bug with macros in Scala 2.12.0-RC2

[Alexandru Nedelcu]

Hi all,

I have a possible problem in Scala 2.12.0-RC2 that doesn't happen with
Scala 2.11.8 or with Scala 2.10.6.

My sample unfortunately isn't minimal, due to time constraints. However
I have a Gist with the code producing it, with the macro expansion that
happens and with the problem, if you care to take a look:
https://gist.github.com/alexandru/26400bfc6209d4884d9cc916ad48d196

What happens is that I have code like this:

new MyInterface {
val scheduler = s
}

Which translates into a node like this (since vals in scala are just
private vars with a public def):

ValDef(Modifiers(PRIVATE | LOCAL), TermName("scheduler ") ...

Which in Scala 2.12 all of a sudden is rewritten like this due to my
macro:

ValDef(Modifiers(), TermName("scheduler ") ...

So the `private[this]` part of that definition is gone, with the
compiler then generating an error message because all of a sudden this
is in conflict with its own generated `DefDef`. It's very confusing why
this happens as in my code I see nowhere the possibility for this and as
I said, Scala 2.11 and 2.10 work just fine with my macro.

I must mention that I'm using as dependencies:

- "org.typelevel" %%% "macro-compat" % "1.1.1"
- "org.scalamacros" % "paradise" % "2.1.0" cross CrossVersion.full

Cheers,

--
Alexandru Nedelcu
alexn.org

[Alexandru Nedelcu]

I have managed to minify the sample, it can now be included in a ticket
I think:
https://gist.github.com/alexandru/26400bfc6209d4884d9cc916ad48d196

Basically it's the fault of `untypecheck`, a behavior that wasn't
happening in 2.11.

--
Alexandru Nedelcu
alexn.org

> --
> 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/d/optout.

[Jasper-M]

I'm guessing this has something to do with it: https://github.com/scala/scala/pull/5141

Op dinsdag 25 oktober 2016 15:17:49 UTC+2 schreef Alexandru Nedelcu:

[Adriaan Moors]

Yep, #5141 changed the internal representation of fields in many cases, but I'm not sure this is one of them. 

For many ValDefs we defer creating the field symbol until the fields phase (after uncurry), and until then they carry the getter's symbol (as was already the case for e.g. deferred vals). 

To minimize the change in the internal representation, we still introduce (and use) a field symbol for a concrete non-lazy val defined in a non-trait class.

Sounds like there is indeed something weird with untypecheck. Happy to help, but I'm not very familiar with the macro libraries you're using.

cheers

adriaan

[Miles Sabin]

On Wed, Oct 26, 2016 at 1:31 AM, Adriaan Moors <adr...@lightbend.com> wrote:
> Sounds like there is indeed something weird with untypecheck. Happy to help,
> but I'm not very familiar with the macro libraries you're using.

macrocompat should be effectively a NOP on 2.11.x or greater. I think
that Alexandru has a reproduction which doesn't require either
macrocompat or paradise.

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
http://milessabin.com/blog
http://twitter.com/milessabin

[Alexandru Nedelcu]

What Miles is saying is true, I minified the example and now it no
longer requires paradise or macro-compat.

You can just copy-paste the example in a Scala REPL and see the output:
https://gist.github.com/alexandru/26400bfc6209d4884d9cc916ad48d196

I would appreciate confirmation that it isn't my fault :-)

Thanks,

--
Alexandru Nedelcu
alexn.org

[Adriaan Moors]

Thanks! I'll take another look today.

[Adriaan Moors]

Ok, yeah, this is a regression due to #5141. Before, derived trees for valdefs would be rewritten to have their modifiers reflect that the underlying field is private[this]. After the fields rewrite, this is only done for the modifiers tracked by the tree's symbol. When you call untypecheck, the tree's symbol is dropped and thus it forgets that it's supposed to be private[this].

Logged a ticket to be fixed for 2.12.1: https://issues.scala-lang.org/browse/SI-10009

[Alexandru Nedelcu]

Hey, thanks for checking it and filling that issue.

Now I have a problem in supporting Scala 2.12.0, because if I give up on `untypecheck` I end up with another problem due to an interaction with another macro and partial functions - a problem that is harder to reproduce. Basically without `untypecheck` this simple macro is unsafe for being exposed to users. Which means that if I want to support Scala 2.12.0, I have to give up on these macros entirely.

Cheers,

--

Alexandru Nedelcu

alexn.org

[Adriaan Moors]

Yes, I regret not being able to ship this fix (and a few others) with 2.12.0, but we'll do our best to have 2.12.1 out within a month after 2.12.0. We'd rather not do another RC3 because it represents a lot of work for many project maintainers. Once we ship 2.12.0, we can start adding projects for each minor release, instead of starting from scratch with each RC.