This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Need guidance on revamping @migration/-Xmigration

No replies
soc
Joined: 2010-02-07,
User offline. Last seen 34 weeks 5 days ago.

Hi,

I'm currently working on making @migration less targeted on the past 2.7
-> 2.8 move (as it is mentioned in the command line help) and make it
more useful for general usage.

My work started when I wondered how long @migration information should
stay on a method, considering that the method isn't going away as it
happens with @deprecated. After evaluating possible solutions, I came to
the conclusion, that it is better to make -Xmigration more "intelligent"
when working out if migration warnings should be shown or not and not
remove any @migration information from the source code.

Idea:

- Xmigration has threshold value for versions, which decides whether a
@migration annotation should be shown
- If -Xmigration is set without any version, a sane default is assumed

=> We don't clutter the compiler output with -Xmigration in Scala 2.10
with warnings from a move between 2.7 and 2.8
=> We don't loose/delete any information in the source

Things I've done:

- I migrated @migration's usage to the way @deprecated works
- @deprecated the old style for 2.10
- Adapted every usage of @migration in the std lib to the new style.
- Created a new VersionSetting to handle the versioning and the
correct comparison of version numbers and moved -Xmigration from
BooleanSetting to VersionSetting.
- The migration warning of the compiler now mentions the version where
the change occured.
- Adapted ScalaDoc to the new style.

I have attached a diff with the changes, because I don't want to commit
incomplete patches.

I would be very happy if someone could review my incomplete code. I
could need some assistance on how to implement the appropriate Setting,
which I haven't fully understood yet.

I could also need some advice on what todo with
scala.collection.mutable.Stack. ScalaDoc and @migration contradict each
other, claiming the opposite:

ScalaDoc: "The iterator issues elements in the reversed order they were
inserted into the stack (LIFO order)."
@migration: "`iterator` traverses in FIFO order."

Thanks and bye,

Simon

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland