Construct ClassIndex based on the CompilationInfo, to correctly reflect the available modules/classes.

[lahodaj]

Looking at Jaroslav's report:
https://lists.apache.org/thread/f5st2t0wspbdmjt6v5ojobzqpl7cjk9n

There's a general problem with ClassIndex - it is based on ClasspathInfo only, and only on boot, compile and source path. This means the ClassIndex does not see things on the module path, and module classpath(*). ComputeImports has a hack to workaround this, but code completion does not.

I think it is time to bite the bullet, at least partially, and try to fix this more conceptually.

The proposal herein is that we'll take ClassIndex from CompilationInfos, not ClasspathInfos, wherever possible, and that this ClassIndex will be configured based on the actual modules in the compilation.

(*) I am not quite certain we need module classpath (basically, classpath, but when modules are enabled). I think it would make more sense to only have classpath, but lets not dive into that too deep in this PR.

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

LLMs, Commit messages and PR description:

• Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.
• LLM assisted commits should be attributed with an Assisted-by: MODEL_NAME MODEL_VERSION line appended to the commit message.
  • Please mention coding assistance in the PR description too (eg. by adding the same Assisted-by line from above)
  • Please describe the changes in your own words - we'd like to know you understand the changes being made!

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[jtulach]

I am trying the changes in this PR on my project and it does work sometimes, but mostly it is broken.

When I am lucky, I see Code Completion for JUnit:

But when I dismiss the code completion, type something like @Tes and try completion again, it shows nothing:

Also the JUnit code completion doesn't appear on first invocation. Only on subsequent request.

FYI: There are possibly related compilation issues in OtherInteropType & co. the missing classes were brought in via <scope>provided</scope>

Is CC & co. in my project working for you properly?

[jtulach]

Maybe add an assert to avoid calling this when the status isn't in the right phase?

[lahodaj]

There's an assert in CompilationInfoImpl.

[jtulach]

FYI: There are possibly related compilation issues in OtherInteropType & co. the missing classes were brought in via <scope>provided</scope>

Is CC & co. in [my project](https://github.com/jtulach/graalvm-native-libs/commit/411b0e986ed1795e62d70e0ce4aa50ec1bdd68b5) working for you properly?

This problem is present in Apache NetBeans 30 as well - e.g. it is not a regression caused by this PR:

It is again the package not visible because module does not read it. Clearly javac in NetBeans doesn't get it right. Isn't there a way to turn this error into a warning for my project?

[lahodaj]

I made some progress in improving the state for the index search.

For the support for the provided dependency, given the shenanigans with unpacking the dependencies into the compile-target directory, that's particularly tricky to support.