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

[Pavel Rappo]

On Wed, 3 Apr 2024 23:19:29 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/ConstructorWriter.java line 195:
> 
>> 193:         HtmlId erasureAnchor = htmlIds.forErasure(constructor);
>> 194:         if (erasureAnchor != null
>> 195:                 && !erasureAnchor.name().equals(memberAnchor.name())) {
> 
> Is this redundant now that the erasure handling is encapsulated within forMember?

No, it's not redundant. `forMember` returns either the simple id or the erased id. `forErasure` always returns the erased id. Therefore, if `forMember` returns the erased id, there will be a duplicating id, which is a no-no.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18519#discussion_r1551518754