Fix "Go to Definition" for exported java_library targets#399
Fix "Go to Definition" for exported java_library targets#399Fabian Meumertzheim (fmeum) wants to merge 1 commit into
java_library targets#399Conversation
… library When a target's .jdeps references a jar produced by another imported target (e.g. one reached only through an out-of-scope library that re-exports it), the importer turned that jar into a synthetic sourceless library. Because the producing target is also imported as a source module, that library shadowed its sources, so go-to-definition resolved to the decompiled .class instead of the .java. Rework jdepsLibraries into jdepsDependencies: a jdeps jar produced by an imported target becomes a non-exported module dependency (new DependencyLabelKind.COMPILE_NON_EXPORTED) on that target instead of a sourceless library. Non-exported keeps the producer from leaking to the consumer's own dependents, so an undeclared use in a dependent stays unresolved and IntelliJ's "Add dependency on module" quick fix applies. Add a workspace-import approval test project (jdeps_library_shadows_module) with a //...:c:C demo of the dependent behaviour.
java_library targets
|
Lev Leontev (@gottagofaster236) This fixes an issue I'm frequently seeing while working on Bazel due to its use of |
|
Fabian Meumertzheim (@fmeum) looks similar to BAZEL-3316 |
|
NothingButYou (@Krystian20857) That link says "not found" |
|
made it public |
|
Yeah, that may be an additional root cause for a similar phenomenon (or one really explains the other). |
|
Generally I do not like the idea of substituting the non-imported target сщтеутеы (sources, dependencies, etc) with jdeps. This will break a lot of internal functionality, starting from WorkspaceSnapshot/TargetUtils and ending with masking such targets from the list of all targets. I would prefer the approach to create synthetic target which "shadows" the non-imported one. NothingButYou (@Krystian20857) let's discuss? |
|
This seems related to some aspects of #401 |
Problem
When a target's
.jdepsreferences a jar produced by another imported target — e.g. a target reached only through an out-of-scope library that re-exportsit — the importer turned that jar into a synthetic sourceless library. Because the producing target is also imported as a source module, the library shadowed its sources: go-to-definition on those symbols resolved to the decompiled.classinstead of the.java.Fix
jdepsLibraries→jdepsDependencies: each jdeps jar is mapped back to the imported target that produces it (via the per-target interface/binary jars). If it belongs to an imported target it becomes a module dependency on that target instead of a sourceless library, so it resolves to the target's source module.The edge uses a new
DependencyLabelKind.COMPILE_NON_EXPORTED: it resolves for the consumer but is not re-exported to the consumer's own dependents (DependencyBuilderforce-exports plainCOMPILEmodule deps for Bazel targets; the new kind opts out). So a dependent that uses the producer without declaring it stays unresolved, and IntelliJ's existing "Add dependency on module" quick fix (OrderEntryFix→BazelProjectModelModifier) applies and edits the BUILD file.Test
Adds a workspace-import approval test project
jdeps_library_shadows_module://…/a:A(source module) ←//…/mid:M(exportsA; an out-of-scope library atimport_depth: 0) ←//…/b:B. B compiles against A through M's export, so B's.jdepsreferences A's header jar while A is not on B's transitive module path — the leak scenario.//…/c:Cis a manual demo of the dependent behaviour: it uses A indirectly, so A is unresolved in C and the "Add dependency on module 'A'" quick fix applies. It deliberately does not compile (the workspace-model import does not compile it).The approval golden is generated locally (the suite is local-only); it should show modules A, B and C, B → A as a non-exported module dependency, and no sourceless library for A's header jar.
Draft: golden not yet generated.