Firstly, its worth reiterating that we’d like people to move from
scalac -optimize to
scalac -opt:.... The new option requires an explicit opt-in to an inlining policy.
For backwards compatibility, we deprecated the old option with the following advice:
% scalac -deprecation -optimize sandbox/test.scala
warning: -optimise is deprecated: In 2.12, -optimise enables -opt:l:inline -opt-inline-from:**. Check -opt:help for using the Scala 2.12 optimizer.
Previous releases of 2.12 had a course grained way to select where to inline from. These are now also deprecated in favour of the new option.
l:project [deprecated, use -opt:l:inline, -opt-inline-from] Enable cross-method optimizations within the current project.
l:classpath [deprecated, use -opt:l:inline, -opt-inline-from] Enable cross-method optimizations across the entire classpath.
We no longer to express an inlining rule to mean “the sources in the current compile run”. We left the possibility open to add
-opt-inline-from:<sources> for this purpose, but we haven’t implemented it yet.
I think it is preferable to use a package based approach so that
scalac A.scala B.scala has the same end result as
scalac A.scala B.scala; scalac A.scala, as is common under incremental compilation. I suppose for use cases when you know you are performing a full build, the
<sources> option would be more convenient.