Import rewriter creates ambiguities

[paulp]

Rewriter takes an import of the form import Foo.{ Bar, _ } and rewrites it to import Foo._ on the theory that Bar is redundant. Usually it's not redundant, it's there because without it Bar will be ambiguous with some other Bar. Wildcard imports have a different precedence than named imports.

I tried to compile a good sized codebase after an import rewriting and now having reverted the rewrites in 10 files and not near the end I admit defeat for now.

[paulp]

Here's a concrete illustration.

[olafurpg]

Interesting, I was not aware of these semantics. Imports in Scala are definitely another beast than imports in Java, for example.

It seems that import groups ending with wildcards should never be expanded. Renames, unimports are covered in the current implementation but I thought Importee.Name was safe to move out.

I tried to compile a good sized codebase after an import rewriting and now having reverted the rewrites in 10 files and not near the end I admit defeat for now.

Thank you for taking the time to report back on your experience! I was aware that OrganizeImport still had some rough edged(s. I admit I should have documented this fact better in the release notes.

[dwijnand]

Here's the relevant section in the spec, courtesy of @tpolecat.

http://www.scala-lang.org/files/archive/spec/2.12/02-identifiers-names-and-scopes.html

[paulp]

It isn't just when they're grouped though. Any time an identifier is explicitly imported, it may or may not be redundant with a wildcard import which also imports the name. Usually of course it will be redundant, and those are exactly the ones one would hope to eliminate with a source rewriting tool. But it won't be much good unless it can distinguish these cases.

[olafurpg]

Named imports should no longer be subsumed by wildcard imports (see #94). Named imports are only removed if -Ywarn-unused-import complains about them.