StackOverFlow when indexing Jars with self-referencing Class-Path:

[faizk]

Discovered when using ScalaMetals (v0.9.1):
https://gist.github.com/faizk/df7cde49b2c581df9971ea5f58c8eec4

On closer examination, I found at least one third-party JAR
(my build.sbt is basically a bunch of unmanagedJars in Compile : = .. , etc) that is self-referential:

Given a jar file MyJar.jar:

Manifest-Version: 1.0
Class-Path: MyJar.jar
Created-By: 1.7.0_06 (Oracle Corporation)

I'm not sure that Jars such as these are even valid, but they do break tools, so perhaps handling such situations
is a good idea (either silently skip but warn about it, or throw an exception describing the problematic input).

I can't imagine there would be a specification that says that the Class-Path: attr can never resolve to the name of the original jar file - that doesn't make sense, so I think protecting against just a situation is called for,

Likely -
https://github.com/scalameta/scalameta/blob/master/semanticdb/metacp/src/main/scala/scala/meta/internal/classpath/ClasspathIndex.scala#L134-L165

I just tried a quick fix on the lines of

     if (abspath.isFile || abspath.isDirectory) {
       if (abspath != jarpath) 
          expandEntry(abspath)
     }

Which fixes the issue for me, so I can send a PR (to stop recursing and maybe log a warning) - unless I find after some more research on this that there's a better way.

[olafurpg]

Thank you for reporting and tracking down the root cause of the issue!

Which fixes the issue for me, so I can send a PR (to stop recursing and maybe log a warning) - unless I find after some more research on this that there's a better way.

A PR would be appreciated 👍 Your change looks good to me. We can also maintain a set of "visited paths" to avoid infinite recursion if the cyclic reference is not direct.