RFR: 8325088: Overloads that differ in type parameters may be lost [v3]

[Pavel Rappo]

On Wed, 3 Apr 2024 23:15:43 GMT, Chen Liang <liach at openjdk.org> 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