[java] Rewrite symbol table#2601
Conversation
TODO implement
Generated by 🚫 Danger |
adangel
left a comment
There was a problem hiding this comment.
Sorry that it took so long, will merge soon...
| package net.sourceforge.pmd.util; | ||
|
|
||
| /** Represents a boolean that may not be present. Use as a non-null type. */ | ||
| public enum OptionalBool { |
There was a problem hiding this comment.
Should this be public? It sounds like an implementation helper....
Hm... seems to be used in the shadow chain API. Any reason, why you didn't use Optional<Boolean> instead?
There was a problem hiding this comment.
Hm... seems to be used in the shadow chain API.
It's also used in some parts of the upcoming typeres API too. It's a common pattern I think, one that is sometimes replaced with a nullable boxed Boolean, which I think is... meh
Any reason, why you didn't use Optional instead?
All three values are known and there's no need to create a new optional every time
| * BSD-style license; for more info see http://pmd.sourceforge.net/license.html | ||
| */ | ||
|
|
||
| package net.sourceforge.pmd.lang.java.symbols.table.coreimpl; |
There was a problem hiding this comment.
the package name "coreimpl" sounds a bit unusual. That's the part, you made independent of pmd-java and could potentially be moved to core, right?
Maybe we should rename the sub-package with something like "shadow" or "nameshadow" or so... or maybe something with "hierarchy" in it?
There was a problem hiding this comment.
That's the part, you made independent of pmd-java and could potentially be moved to core, right?
Indeed, which is why the packaging is a bit awkward... Maybe chain would be a better name?
ShadowChain is a bit awkward, but I wanted to avoid the name clash with the current Scope classes we have. I think in a world where Scope doesn't exist, ShadowChain could be renamed to ScopeChain, and placed eg in the package nspmd.symbols.scopes?
|
@oowekyala I've merged (and pushed) pmd/7.0.x into java-grammar. There are the following failing tests: Are these related to the symbol table? I've run out of time for today.... |
|
Thanks for doing this! They're not directly related, they happen because JavaVisitorBase doesn't delegate |
Describe the PR
Rewrites the newer symbol table for maintainability and performance.
This extracts the following abstractions from the current symbol table implementation:
This also unifies the API to resolve method, type and variable names (previously resolveMethod returned a List, the others returned a ResolveResult). Now all may return a List. This handles name ambiguity and duplicate declarations for variables and type names, so it is more general than the previous mechanism. It also reuses more code.
In this new framework, JSymbolTable is retained as just a simple tuple of ShadowChains, for ease of use (but it's not a central concept anymore).
This also adds a "MostlySingularMultimap" type, a kind of multimap that is optimised for the case where there are actually only at most one value per key. So the implementation is optimised for the most common case.
Possibly, the ShadowChain API could be lifted up to pmd-core. I'm waiting for a use case before doing this, but I implemented it as if it was in another module, so it has no dependencies on pmd-java
That was the "rewrite" part. The PR also adds support for inherited member resolution and a lot of tests to cover corner cases (hiding of inherited declarations).
This is the last piece needed before we proceed to the type resolution revamp.
Ready?
./mvnw clean verifypasses (checked automatically by travis)