On Mon, 6 Mar 2023 19:48:48 GMT, Pavel Rappo <[email protected]> wrote:
> Please review this explorative refactoring for VisibleMemberTable (VMT). > > This is the first round of refactoring for VMT. This round is about *method > members*: declared (overriding and not) and inherited. > > During this work I gained some insight into internal workings of VMT, fixed > what was feasible and left TODOs and FIXMEs for everything else. Leaving > those comments might look untidy, but leaving them out is wasteful: they > clearly mark issues that should be revisited in upcoming rounds of > refactoring. > > As I see it today, the main issue with VMT is that implements complex and > error-prone computations from Java Language Specification (JLS) by hand. For > example, VMT interprets JLS rules for relations such as _inherits_, > _overrides_ and _hides_. As one would imagine, sometimes VMT does it > incorrectly. It would be better to eventually re-implement VMT using > `javax.lang.model` as much as possible. Unlike that of `jdk.javadoc`, the day > job of `javax.lang.model` is to provide JLS services. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 1031: > 1029: // TODO: this computation should be eventually delegated to > VisibleMemberTable > 1030: Set<TypeElement> alreadySeen = null; > 1031: assert (alreadySeen = new HashSet<>()) != null; // create set > conditionally I think this use of `assert` (here and lower down) is a step too far. It's one thing to use asserts to verify invariants; it's too much to use them to conditionally compute state like this. ------------- PR: https://git.openjdk.org/jdk/pull/12887
