compiler option for fine-grained control over bytecode sources for inlining

[lrytz]

the current opt:l:none / default / method / project / classpath and -opt:inline-project / inline-global are too coarse-grained:

• l:none / l:default / l:method are probably ok
• l:method could include inlining of nested methods
• l:project / inline-project is the main problem, it has very limited practical use
  • it basically means "inline from compilation units only", which can be surprising under incremental compilation
  • "project" basically assumes a project is compiled in one single module
• l:classpath is ok to have; it should probably be renamed l:global
• what we really need is a way to specify what classpath elements to inline from
  • only within the same source file
  • any source file - not recommended, as this changes with incremental compilation
  • specific classpath elements (folders, jars)

for specifying folders / jars, we could implement some matching, e.g., *akka-actor*.jar, or *target/scala-*/classes.

we'd need to provide some sbt examples how to pass output directories (own module, other modules) and dependency jars to this new option.

[lrytz]

@scala/team-core-scala comments / ideas welcome

[szeiger]

Instead of files that are safe for inlining we could use packages, like in Java 9 modules.

[lrytz]

Yes, using packages is probably more sane than talking about jars. It would certainly be simpler to implement.

[adriaanm]

Maybe we could start with an option to opt-in to inlining from a package (and its subpackages). E.g., "scala".

[lrytz]

Possibly an include and an exclude list, also look at https://git-scm.com/docs/gitignore for inspiration

[szeiger]

My gitignore implementation in Scala: https://github.com/szeiger/ornate/blob/master/core/src/main/scala/com/novocode/ornate/FileMatcher.scala

[dwijnand]

Also look at https://github.com/sjl/friendly-find/blob/v1.0.1/ffind#L167-L216 for an inspiring rant about gitignore :P