drccrd opened a new pull request, #3965: URL: https://github.com/apache/incubator-kie-tools/pull/3965
Closes https://github.com/apache/incubator-kie-tools/issues/3712 ### Scope The issue lists six hover improvements. This PR delivers those, and **also** carries works-before-build Java type resolution, which the issue does not mention — calling that out up front rather than leaving it to be discovered in the diff. The two were developed together because the hover work needs the same member/constructor model that the source-backed type index feeds, and splitting them would have meant landing hover sections that only work after a Maven build. Happy to split if maintainers prefer it as two PRs. Three pre-existing defects found while testing this against real rule sources are fixed here too; each is described below and none is introduced by this PR. ### Hover (issue 3712) - **Dotted member chains** — `$o.total`, `Status.ACTIVE`, `$a.b.c` resolve segment by segment through the existing primitives, rendering the segment under the caret. An earlier segment that does not resolve yields no hover rather than mis-describing a fragment. Qualified type names and qualified enum constants fall out of the same walk. - **Qualified enum constants** — `Status.ACTIVE` renders the constant with its enum; since a constant is an instance of its enum, member access continues from the enum type. - **Accumulate functions** — `count`, `sum`, `collectList` render their result type. Detection is structural, from the parse tree, so an argument whose text equals the function name does not qualify and the same name outside an accumulate still shows a DRL function's doc comment. The result-type table is also completed: it carried 20 of the 24 functions the engine ships. - **Doc comments for `function`/`query`/`global`** — declared types already surfaced their preceding `/** … */`; these three kinds now do too. - **Member sections** — a Java type's members were one unlabelled list. They are now grouped as Constants / Fields / Getters / Constructors, empty sections omitted, so an author can see how to construct a fact and which members are bean properties rather than raw fields. - **Inherited members of a Java supertype** — a `declare` extending a Java class showed only its own fields. Two independent inheritance walks stopped at a parent the declared-type index cannot describe, so inherited members were missing from hover, from field completion, and from the type of a binding on one of them. Both now consult one host-installed seam. Deliberately *not* a new layer on the workspace type index: that index also feeds definition, references and rename, which would then receive synthetic types with no navigable source position. ### Java type resolution before a build On a fresh checkout the server knows no project types: the class index scans build output and dependency jars, and the member index reflects over compiled classes. Completion, hover, navigation and the unknown-type lint all wait for Maven. `.java` sources are now parsed into a source-backed type index that fills the gap, with **compiled classes always winning** once they exist — the fallback is consulted only when a class cannot be loaded, never to override a successful load. The parser is the ANTLR Java grammar already generated into the parser module, so this adds **no new dependency**. The server owns the index lifecycle, merges its names into the published class index and refreshes on `.java` watch events; two settings (`drools.lsp.java.sourcePaths`, `.packageFilters`) tune the roots and packages, and go-to-definition and type hierarchy fall back to a source position when no class file exists yet. Known limits, documented in the code: top-level types only, interface members name-first, generics and array dimensions erased to the raw simple name. One behavioural consequence worth a maintainer's opinion: merging source-derived names flips the unknown-type lint's single `classpathResolved` gate before dependency resolution finishes. Publishing now nudges the client to re-pull diagnostics so stale squiggles clear, but the structural fix is splitting that gate into "sources resolved" and "dependencies resolved", which is a behaviour decision rather than a mechanical one and is not attempted here. ### Pre-existing defects fixed - **A comment or literal could end a rule's condition.** Binding resolution finds the condition textually and it ends at the first bare `then` — including one inside `// … then …` or a constraint compared against `"then"`. Bindings past that point were invisible to hover and the inlay hints, and when the cut landed inside a pattern its parentheses no longer balanced, so the pattern was skipped whole and the bindings *before* the cut were lost too. Comments and string literals are now blanked before the scan, length-preservingly so every offset still indexes the original. - **A binding whose type has no class hovered as nothing.** `$size : size` on an `int` field resolved to `int`, but the step required a declared type or a loadable FQCN. It now names the binding and its type, as the chain walk already did. - **Completion offered operators where only members are legal.** After a dot the engine cannot see that the path is unfinished and predicted the constraint operators; that position is now answered from the type walk. Rule attributes are no longer offered at statement boundaries, where only the top-level statement keywords are legal. ### Verification `mvn clean package` in `packages/drools-lsp`: drools-parser 4, drools-completion 356, drools-lsp-server 50 — from a 333-test baseline on `main`, all green. The extension type-checks and passes `prettier --check`. Also exercised in the running extension against a real multi-file rule project. ### Note on #3718 https://github.com/apache/incubator-kie-tools/pull/3718 renames `DRLParserHelper` to `DRL10ParserHelper`. Three files here overlap with it — `DRLCompletionHelper`, `DroolsLspDocumentService` and `DRLDeclaredTypeParser` — all at import level only. Whichever lands second needs that rename applied; happy to rebase. The source-typing work parses `.java` via `org.drools.drl.parser.antlr4.JavaParser`, which is present in the `drools-drl-parser` artifact that #3718 switches to, and its grammar there is identical to the in-tree copy, so #3718 does not break it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
