Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0alpha
    • Fix Version/s: 2.0.0RC1
    • Component/s: Inferencing Engine
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Currently, source locations for java doc are not included in IJavaElements generated from the Groovy compiler. This is because java doc locations are ignored by the parser. The problem is that this is preventing source hovers from displayingthe JavaDoc contents of the item being hovered on.

      I can see several possible ways of adding Javadoc:

      1. Enhance the groovy parser with a new grammar and new AST elements that represent the JavaDoc.

      2. After a reconcile do a second walk of the file and determine the start and end points of all JavaDoc comments.

      #1 is a much better solution, but would require a fairly significant patch to the compiler. There has been some talk of doing this on the mailing list, but I do not think any progress has been made (certainly, there are no JIRAs for it). #2 would work for the plugin. However, I am a little concerned about the extra time it might take during a reconcile.

        Issue Links

          Activity

          Andrew Eisenberg made changes -
          Field Original Value New Value
          Link This issue supercedes GRECLIPSE-126 [ GRECLIPSE-126 ]
          Andrew Eisenberg made changes -
          Link This issue supercedes GRECLIPSE-191 [ GRECLIPSE-191 ]
          Hide
          Andrew Eisenberg added a comment -

          Did a little bit of investigating here.

          All elements in the JDT Compiler AST that can have doc comments attached to them have a javadoc field. This field is a fully structured doc comment with source locations and children for all tags in it.

          Going into that much detail is not necessary. I believe, all that we need is sourceStart and sourceEnd. Once these get filled in, I think that the IJavaElement hierarchy will just pick them up.

          Show
          Andrew Eisenberg added a comment - Did a little bit of investigating here. All elements in the JDT Compiler AST that can have doc comments attached to them have a javadoc field. This field is a fully structured doc comment with source locations and children for all tags in it. Going into that much detail is not necessary. I believe, all that we need is sourceStart and sourceEnd. Once these get filled in, I think that the IJavaElement hierarchy will just pick them up.
          Andy Clement made changes -
          Assignee James E. Ervin [ jervin ] Andy Clement [ aclement ]
          Hide
          Andy Clement added a comment -

          The comments are now persisted as part of the parse - however, slapping them in the javadoc field is not sufficient as there is a lot of post analysis done to make sure they are OK and it relies on positional information being extremely accurate for the types/members involved. Just the basic support for type/method/field/ctor needs changes to the positional settings to allow for proceeding javadoc - without these positions being correct any comments in the javadoc field are ignored. This is too much change for M2 but possible for RC1. We must be careful the information we allow to flow downstream from the compiler is robust because components outside of our control (jdt ui) are going to play with it - if it has problems these may manifest as nasty NPEs or AIOOBEs.

          Show
          Andy Clement added a comment - The comments are now persisted as part of the parse - however, slapping them in the javadoc field is not sufficient as there is a lot of post analysis done to make sure they are OK and it relies on positional information being extremely accurate for the types/members involved. Just the basic support for type/method/field/ctor needs changes to the positional settings to allow for proceeding javadoc - without these positions being correct any comments in the javadoc field are ignored. This is too much change for M2 but possible for RC1. We must be careful the information we allow to flow downstream from the compiler is robust because components outside of our control (jdt ui) are going to play with it - if it has problems these may manifest as nasty NPEs or AIOOBEs.
          Andy Clement made changes -
          Fix Version/s 2.0.0RC1 [ 15956 ]
          Hide
          Andy Clement added a comment -

          done what I plan to do. Will be a little glitchy I expect as there are so many places that can be doc'd - fix those as they come up

          Show
          Andy Clement added a comment - done what I plan to do. Will be a little glitchy I expect as there are so many places that can be doc'd - fix those as they come up
          Andy Clement made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          Andrew Eisenberg added a comment -

          Nice. Works for types, fields and methods for me. Links (in the javadoc view) are working too.

          Show
          Andrew Eisenberg added a comment - Nice. Works for types, fields and methods for me. Links (in the javadoc view) are working too.
          Andrew Eisenberg made changes -
          Component/s Inferencing Engine [ 14687 ]
          Component/s Code Browsing [ 13143 ]

            People

            • Assignee:
              Andy Clement
              Reporter:
              Andrew Eisenberg
            • Votes:
              8 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: