GRECLIPSE

If a field has an initializer with a known static type, should use that type as the field's type

Details

  • Number of attachments :
    0

Description

In this case:

class Foo {
  def x = 9
}

We should infer that the type of Foo.x is int.

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. GRECLIPSE-1139 Content assist for closure arguments

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • 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 -

I have something working locally that appears to be a good fix. I need to write up some more tests before I can close this issue.

Show
Andrew Eisenberg added a comment - I have something working locally that appears to be a good fix. I need to write up some more tests before I can close this issue.
Hide
Permalink
Andrew Eisenberg added a comment -

Unfortunately, this fix only works when referring to a field defined in the current file. When referring to an external field, the initializer is not available, so this mechanism will not work directly.

We are considering altering the schema of external ClassNodes so that they will contain field initializers (when they are constants) just so we can get this working.

Show
Andrew Eisenberg added a comment - Unfortunately, this fix only works when referring to a field defined in the current file. When referring to an external field, the initializer is not available, so this mechanism will not work directly. We are considering altering the schema of external ClassNodes so that they will contain field initializers (when they are constants) just so we can get this working.
Hide
Permalink
Andrew Eisenberg added a comment -

I accepted a patch from Andy Clement (up until recently, the SVN repo was closed for commits). It does make the initializer available in the field, but there is another problem that this uncovered.

When the field is a property (ie- it has no modifiers), then the field is created twice: once during the parse, and then once again because of the property. This is wrong. It looks like JDTClassNode.createPropertyNodeForMethodNode is being called on the getter method for that field and accidentally creating a second field with the same name.

I think I know how to fix now.

Show
Andrew Eisenberg added a comment - I accepted a patch from Andy Clement (up until recently, the SVN repo was closed for commits). It does make the initializer available in the field, but there is another problem that this uncovered. When the field is a property (ie- it has no modifiers), then the field is created twice: once during the parse, and then once again because of the property. This is wrong. It looks like JDTClassNode.createPropertyNodeForMethodNode is being called on the getter method for that field and accidentally creating a second field with the same name. I think I know how to fix now.
Hide
Permalink
Andrew Eisenberg added a comment -

Fix appears to be working. Now, the JDTClassNode.createPropertyNodeForMethodNode method tries to use an existing field, and if it can't find any, then it creates one.

I will write up some tests for this.

The only problem that I can think of is that what if the field is actually declared in a super class? Not sure if this is a problem we need to deal with.

Show
Andrew Eisenberg added a comment - Fix appears to be working. Now, the JDTClassNode.createPropertyNodeForMethodNode method tries to use an existing field, and if it can't find any, then it creates one. I will write up some tests for this. The only problem that I can think of is that what if the field is actually declared in a super class? Not sure if this is a problem we need to deal with.
Hide
Permalink
Andrew Eisenberg added a comment -

The new tests are passing fine.

It looks like if the field is declared in a super type, then the property is added to the super type (ie- there is no problem with the scenario described in the previous question).

Show
Andrew Eisenberg added a comment - The new tests are passing fine. It looks like if the field is declared in a super type, then the property is added to the super type (ie- there is no problem with the scenario described in the previous question).
Hide
Permalink
Andrew Eisenberg added a comment -

Code is committed with regression tests.

Show
Andrew Eisenberg added a comment - Code is committed with regression tests.

People

  • Assignee:
    Andrew Eisenberg
    Reporter:
    Andrew Eisenberg
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: