On Wed, 3 Apr 2024 23:15:43 GMT, Chen Liang <[email protected]> wrote:
>> Pavel Rappo has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 11 additional
>> commits since the last revision:
>>
>> - Merge branch 'master' into 8325088
>> - Remove registration phase
>>
>> Makes the code more robust and simple.
>> - Merge branch 'master' into 8325088
>> - Update copyright years
>>
>> Note: any commit hashes below might be outdated due to subsequent
>> history rewriting (e.g. git rebase).
>>
>> - revert
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.java
>> as spurious
>> - revert
>> test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
>> as spurious
>> - revert
>> test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java
>> as spurious
>> - revert
>> test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
>> as spurious
>> - revert
>> test/langtools/jdk/javadoc/doclet/testOrdering/TestOrdering.java as spurious
>> - revert
>> test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java
>> as spurious
>> - revert
>> test/langtools/jdk/javadoc/doclet/testPrivateClasses/TestPrivateClasses.java
>> as spurious
>> - revert test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java as
>> spurious
>> - revert
>> test/langtools/jdk/javadoc/doclet/testVisibleMembers/TestVisibleMembers.java
>> as spurious
>> - Use erased notation only when necessary
>>
>> Partially reverts 4f028269, which is the bulk of the previous solution,
>> then adds a centralised ID registry for executable elements.
>>
>> The centralised registry is an alternative solution, which is more
>> gentle and less disruptive to tests and composability (-link and
>> -linkoffline).
>> - Update copyright years
>>
>> Note: any commit hashes below might be outdated due to subsequent
>> history rewriting (e.g. git rebase).
>>
>> + update
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.java
>> due to 4f0282694fd
>> + update
>> test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
>> due to 4f0282694fd
>> + update
>> test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java
>> due to 4f0282694fd
>> + update
>> test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
>> due to 4f0282694...
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java
> line 562:
>
>> 560: && e.getKind() != ElementKind.METHOD)
>> 561: throw new
>> IllegalArgumentException(String.valueOf(e.getKind()));
>> 562: var vmt = configuration.getVisibleMemberTable((TypeElement)
>> e.getEnclosingElement());
>
> Will the vmt differ if we specify `-private`? And say if we have 2 methods
> like:
>
> private <T extends Runnable> void method(T arg) {}
> public <T extends Number> void method(T arg) {}
>
> Will the Number public method be consistently erased whether or not
> `-private` is set?
The answer to your latter question is no. The id that will be assigned to that
public method do depend on whether the private overload positioned before it is
documented. You cannot do much about it with the current design of
`VisibleMemberTable` without unduly complicating this PR. On the bright side, I
reckon such a case is extremely rare.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18519#discussion_r1551513544
