GRECLIPSE

Source locations for java doc

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

supercedes

New Feature - A new feature of the product, which has yet to be developed. GRECLIPSE-126 javadoc does not display in javadoc window and also not as popup during code completion when editing a .groovy file

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

New Feature - A new feature of the product, which has yet to be developed. GRECLIPSE-191 Reuse javadoc from properties for code completion comments ( tooltips )

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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.
Hide
Permalink
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.
Hide
Permalink
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
Hide
Permalink
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.

People

  • Assignee:
    Andy Clement
    Reporter:
    Andrew Eisenberg
Vote (8)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: