Ólafur Páll Geirsson

I won't be able to look at this issue until earliest next week.

I was able to reproduce this issue in https://github.com/scalameta/scalameta/compare/master...olafurpg:self-type-occurrence?expand=1 The problem is that the `Ident` trees for `Map`, `Int` and `String` in `this: Map[String, Int]` have `null` types and `NoSymbol`....

@kpbochenek nice investigation! Yes, I believe this issue should be raised in scala/bug

For context, I believe SemanticDB used to handle this case before when we hijacked the typechecker with runtime reflection in order to instrument typechecking and attach information when occurrences like...

We removed this hijacking step because it made it difficult to upgrade to new Scala versions and it didn't play nicely with other integrations like Hydra

A workaround is to manually hardcode a `SymbolInformation` for `==` ```scala symtab.info("java/lang/Object#`==`().").map(_.copy(displayName == "==")) ```

It sounds like OSGi might be able to help us for this problem but after reading up on OSGi for 30 minutes I still have no clue how to use...

FWIW, the scala-compiler OSGi MANIFEST.MF declares an optional `Import-Package` on `jline.*` and ant ``` Import-Package: jline;resolution:=optional, jline.console;resolution:=optional, jline.console.completer;resolution:=optional, jline.console.histor y;resolution:=optional, org.apache.tools.ant;resolution:=optional, org.ap ache.tools.ant.taskdefs;resolution:=optional, org.apache.tools.ant.types ;resolution:=optional, org.apache.tools.ant.util;resolution:=optional, ``` These are the...

Actually, the `Import-Package` listing in `MANIFEST.MF` might be sufficient information to know that `jline.console` is a package symbol. From there we might only need to know `--assume-java jline`.

Encountered another problematic jar, `org.scalatest:scalatest`. The classfiles seem to depend on junit/mockito/easymock/jmock/ant even if the scalatest maven module does not depend on those. The JVM loads classes lazily so there...