Dartdoc bracketed references don't work for inherited members #4114

Activity

1. gspencergoog

   added

   is bug

   on Aug 22, 2022
2. DanTup commented on Aug 23, 2022

   

   DanTup

   on Aug 23, 2022

   Member

   More actions

   I don't think it's specific to super-params, as this has the same behaviour:

   class A {
     final String myField = '';
   }
   
   class B extends A {
   }
   
   /// [A.myField] is clickable.
   /// [B.myField] is not clickable.
   int? a;
   

   @bwilkerson I think this doesn't currently work because in B.myField, myField does not have a staticElement (whereas in A.myField it does). I suspect that's because the comment resolver here only looks in the current class for members:

   https://github.com/dart-lang/sdk/blob/571f43b004cc32f50418b037af475c6565648c21/pkg/analyzer/lib/src/dart/resolver/comment_reference_resolver.dart#L71-L75

   Should this reference work? And if so, would the correct fix be to walk up prefixElement.allSupertypes to find the first match by name to assign its staticElement?
3. DanTup

   added

   in editorRelates to code editing or language featuresRelates to code editing or language features

   in lsp/analysis serverSomething to be fixed in the Dart analysis serverSomething to be fixed in the Dart analysis server

   on Aug 23, 2022
4. DanTup

   added this to the On Deck milestone on Aug 23, 2022
5. DanTup

   changed the title [-]Dartdoc bracketed references don't understand `super` parameters.[/-] [+]Dartdoc bracketed references don't work for inherited members[/+] on Aug 23, 2022
6. bwilkerson commented on Aug 23, 2022

   

   bwilkerson

   on Aug 23, 2022

   More actions

   Should this reference work?

   I don't know what dart doc does with that code, but the analyzer should match it as closely as possible, given the performance constraints it has to operate under.

   And if so, would the correct fix be to walk up prefixElement.allSupertypes to find the first match by name to assign its staticElement?

   I think we want to walk up the superclass chain first and only look in interfaces when we can't find a member from a supertype. I believe that that's the behavior we use in other features, and it would be good to be consistent. I also think that that's the behavior we'd get from using InheritanceManager3, which is probably the best way to implement such a lookup.
7. DanTup commented on Aug 23, 2022

   

   DanTup

   on Aug 23, 2022

   Member

   More actions

   I don't know what dart doc does with that code, but the analyzer should match it as closely as possible, given the performance constraints it has to operate under.

   I tested the example above, and it does appear to work:

   

   I also think that that's the behavior we'd get from using InheritanceManager3, which is probably the best way to implement such a lookup.

   I'll take a look, thanks!
8. copybara-service

   added a commit that references this issue on Aug 25, 2022

   [analyzer] Resolve comment references for inherited members

   ...

   857a0d2
9. DanTup

   modified the milestones: On Deck, v3.50.0 on Aug 25, 2022
10. DanTup commented on Aug 25, 2022

    

    DanTup

    on Aug 25, 2022

    Member

    More actions

    Fixed by dart-lang/sdk@857a0d2 (ships in the SDK, not a Dart extension update).
11. DanTup

    closed this as completedon Aug 25, 2022
12. DanTup

    added

    relies on sdk changesSomething that requires changes in the Dart/Flutter SDK to ship before it will become availableSomething that requires changes in the Dart/Flutter SDK to ship before it will become available

    on Sep 6, 2022