Quick fixes for upcoming deprecations

[Simon Ochsenreither]

Hi everyone,

as it currently looks, there will be a few deprecations in Scala 2.11 which depend heavily on the help of the IDE to make the migration as painless as possible for users of the language.


Deprecation of view bounds:

For instance, given def foo[A <% B](a: A), the IDE should suggest replacing that with def foo(a: A)(implicit A => B).

Procedures:

For instance, class Foo { def bar } should offer class Foo { def bar: Unit } and def foo { println("") } should offer def foo: Unit = { println("") } as a replacement.


What's the best way to get this going? Should I file bugs? How can I help?

Thanks,

Simon

[Simon Schäfer]

Hi Simon,

because I'm currently working with scala-refactoring and looked into quick fixes as well, I can tell you something about that.

Implementing quick fixes should be easy most of the time, because they rely on tree analysis and transformation, which is very well supported by scala-refactoring. There can only be the problem that scala-refactoring doesn't yet provide everything needed for the refactoring either because of a bug or simply because of unimplemented behavior. Then it can be very time consuming to implement the quick fix (I had the "luck" to work on such a refactoring, thus I know what I'm speaking about ;)).

Filling tickets is always a good idea, maybe Mirko has some time to fix them. If you want we can meet each other in the next weeks and work on that together (but not before my presentation next month, I'll not have enough time).

Of course you can work on them by yourself, but then you need to solve potential setup (or startup) problems by yourself. ;)

Simon

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

[Mirco Dotta]

Hi Simon,

Thanks a lot for reaching out!

I'm wondering, won't Scala also provide the quick fix in its error message? If yes, maybe can simply parse the reported compiler error and have an ad-hoc quick fix for this.

-- Mirco

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

---------------

Mirco Dotta

PSE-D, 1015 Lausanne, Switzerland

Twitter: @mircodotta

Build reactive apps

[Simon Ochsenreither]

I'm wondering, won't Scala also provide the quick fix in its error message? If yes, maybe can simply parse the reported compiler error and have an ad-hoc quick fix for this.

Funny, I had that idea too. :-)
It might make sense to define a simple protocol so that the compiler can emit recommendations in an machine-readable format, so one doesn't have to search all strings for magic keywords.

The issue is that at least for view bounds that they get desugared extremely early, so I'm not sure if there is a reliable way to reverse-engineer implicit parameters to view bounds (or even tell desugared ones and user-defined ones apart), so maybe it is easier to fix at the IDE side.

For procedures, it should be a bit easier to fix regardless of the approach.

I'm mostly bringing this up because I know I'm not the person efficient at digging through those dozens of layers of indirection Eclipse seems to mandate, but without IDE support it is questionable whether I can get this into 2.11, meaning that we will be stuck with that language cruft for at least an additional two years.

So if there is a good soul who can handle the IDE specific parts of this migration or can give me some hints like Simon on how to do it in scala-refactoring properly, this would be extremely great!

Bye,

Simon

[Simon Schäfer]

On 08/21/2013 06:31 PM, Simon Ochsenreither wrote:

I'm wondering, won't Scala also provide the quick fix in its error message? If yes, maybe can simply parse the reported compiler error and have an ad-hoc quick fix for this.

Funny, I had that idea too. :-)
It might make sense to define a simple protocol so that the compiler can emit recommendations in an machine-readable format, so one doesn't have to search all strings for magic keywords.

Yes, that would be great. Just returning strings is silly for an IDE.

The issue is that at least for view bounds that they get desugared extremely early, so I'm not sure if there is a reliable way to reverse-engineer implicit parameters to view bounds (or even tell desugared ones and user-defined ones apart), so maybe it is easier to fix at the IDE side.

It is not possible to detect it for sure, but semantic highlighting works also only with a heuristic and no one reported a bug so far, thus it should be safe for a refactoring too. ;)

For procedures, it should be a bit easier to fix regardless of the approach.

I'm mostly bringing this up because I know I'm not the person efficient at digging through those dozens of layers of indirection Eclipse seems to mandate, but without IDE support it is questionable whether I can get this into 2.11, meaning that we will be stuck with that language cruft for at least an additional two years.

So if there is a good soul who can handle the IDE specific parts of this migration or can give me some hints like Simon on how to do it in scala-refactoring properly, this would be extremely great!

Just had a free our (ok I had not, but wanted to look into it ;) ), thus I implemented a first version: https://github.com/sschaef/scala-refactoring/commit/e975cb8654a8c4fcfc7b8e6e0c38bf8807a85f3a

It still has some bugs and it needs lots of more test cases, but it works (ok, that isn't true either, the position of the method is crap and I didn't find out why yet, thus the refactoring is aborted later).

If you want you can continue that, I'll not in the next days. But I think both refactorings shouldn't be very difficult in the end, the most difficult thing is probably the testing part. ;)

Bye,

Simon

[Simon Ochsenreither]

Wow, thanks a lot, Simon!

Now that I managed to make SBT work again, I'll fix my stuff which piled up for the last few days and then look into the refactoring code.

[Donny Nadolny]

I took a look at this too before I saw that you (Simon S) already did. As you found, there is no real way to determine if a type parameter was using a view bound in scala-refactoring. I didn't think of checking if the implicit evidence name matched the compiler generated naming scheme, so I gave up on using scala-refactoring. Instead I tried a different way: using scalariform's parser you can detect the view bounds perfectly and pull them out to a parameter list.

I've got a quick fix for this working (handles multiple view bounds in a type parameter list, appending to an existing implicit parameter list or adding a new one), but the code is messy and it'll be a day or two before I have a chance to clean it up. I'll put it on a branch when it's ready.

Is there a warning for this already? I tried out 2.11 M4 as well as the nightly from yesterday but I didn't get any warning when using view bounds. Right now I'm triggering the quickfix by causing a completely unrelated error.

On Wed, Aug 21, 2013 at 7:12 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Wow, thanks a lot, Simon!

Now that I managed to make SBT work again, I'll fix my stuff which piled up for the last few days and then look into the refactoring code.

--

[Simon Schäfer]

On Thursday, August 22, 2013 4:54:43 AM UTC+2, Donny Nadolny wrote:

I took a look at this too before I saw that you (Simon S) already did. As you found, there is no real way to determine if a type parameter was using a view bound in scala-refactoring.

What should be possible is to take a look into sources whenever a compiler generated implicit param list is found - then it would be sure.
 

I didn't think of checking if the implicit evidence name matched the compiler generated naming scheme, so I gave up on using scala-refactoring. Instead I tried a different way: using scalariform's parser you can detect the view bounds perfectly and pull them out to a parameter list.

Should be inefficient for large files when scalariform needs to parse the file again - on the other side tokenizing is really fast and happens multiple times on each keystroke. Thus, it is probably completely irrelevant. Having a working scala-refactoring solution would also mean that other tools can easily reuse the implementation. Another thing I just came up with is that with scalariform you can't detect name conflicts with the auto generated implicit param name.

I've got a quick fix for this working (handles multiple view bounds in a type parameter list, appending to an existing implicit parameter list or adding a new one), but the code is messy and it'll be a day or two before I have a chance to clean it up. I'll put it on a branch when it's ready.

Cool! When we have multiple implementations we could users let decide which one too choose - the option pane could look something like this:

  1. real refactoring based - just awesome, but has the potential to destroy your whole file if an undiscovered
      bug starts to do its work
  2. token based transforming - exists because IDE guys want to prove that they are cracks by doing the
      transformation without support of any tools. No chance that it kills your whole file but - instead it can
      permute the characters if the implementor as well as the reviewers were drunken.
  3. Shut up, I'm not a real computer scientist - I do the refactoring manually and crash the file by myself.

 

Is there a warning for this already? I tried out 2.11 M4 as well as the nightly from yesterday but I didn't get any warning when using view bounds. Right now I'm triggering the quickfix by causing a completely unrelated error.

I'm interested in how you did that. I remember working on the implementation of auto generated method stubs when deriving an abstract class but I can't remember why I didn't finish it. Maybe it was because the compiler just returned one big error message with all the missing methods which needs to be parsed too. A compiler that returns a full fledged error object would be really great.

[Simon Ochsenreither]

Is there a warning for this already? I tried out 2.11 M4 as well as the nightly from yesterday but I didn't get any warning when using view bounds. Right now I'm triggering the quickfix by causing a completely unrelated error.

No, not yet. The language change depends a bit on having decent IDE support.

[Donny Nadolny]

Here it is: https://github.com/dnadolny/scala-ide/commit/2a9f25f274601220466e8a1b8404a9d8c577faad

I've added the quickfix for the procedure to Unit change as well, since it's so easy. There are a few examples/test cases I tried out in a comment at the end of the two classes.

To trigger them, I'm piggybacking on the "value ... is not a member of ..." error. If you want to try it out, you need to write a method, and then on the line before that method you can put "".abc() and hit ctrl+1 on that line. Both quickfixes (view bounds to implicit evidence and procedure to unit) will be available.

On Thu, Aug 22, 2013 at 6:52 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Is there a warning for this already? I tried out 2.11 M4 as well as the nightly from yesterday but I didn't get any warning when using view bounds. Right now I'm triggering the quickfix by causing a completely unrelated error.

No, not yet. The language change depends a bit on having decent IDE support.

--

[Simon Ochsenreither]

Wow, this looks very nice! I'll look into adding the corresponding warnings to the compiler in the next few days.

[Simon Ochsenreither]

PR for view bounds: https://github.com/scala/scala/pull/2909

[Simon Schäfer]

solution based on scala-refactoring now also works for simple cases:
https://github.com/sschaef/scala-refactoring/commit/1a31f5c63e694b89ebc8b6dc2906e45068681114

Just missed some more test cases and because of lack of quasiquotes it
looks more ugly than Donnys code. ;)

On 09/05/2013 12:54 AM, Simon Ochsenreither wrote:
> PR for view bounds: https://github.com/scala/scala/pull/2909

[Simon Ochsenreither]

Hi Simon, hi Donny,

the changes to the compiler were merged¹, but with a minor change: The warning is only generated with -Xfuture for now, pending on decent IDE support for migrating the code².
This means, as soon as the IDE stuff works, the warning can be activated by default (and -Xfuture will fail compilation).

Let's do this! :-)

Thanks,

Simon

¹ https://github.com/scala/scala/commit/5a8cd09819f58adcb866722f48b00066d23e7a82
² https://github.com/scala/scala/pull/2909#issuecomment-25274572