GRECLIPSE
  1. GRECLIPSE
  2. GRECLIPSE-1265

Incorrectly underlined call to valid method declared in super-type, from closure or inner-class

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.5.2.Release
    • Fix Version/s: None
    • Component/s: Inferencing Engine
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      From within a closure or an anonymous inner class, I have a call to an inherited public method. The call is underlined.

      I expected the call not to be underlined in the three cases below.

      class MySuper {
      	public void insuper(String msg) { println msg }
      }
      
      class MySub extends MySuper {
      	public static void main(String[] args) {
      		new MySub().foo()
      	}
      	public void foo() {
      		Runnable work = new Runnable() {
      			@Override public void run() {
      				// The lines below are underlined; expected them not to be
      				insuper("1")
      				MySub.this.insuper("2")
      			}
      		}
      		[1].each {
      			// same here: line below is underlined; expected it not to be
      			insuper("3")
      		}
      		work.run()
      	}
      }
      

      Executing the above writes out what you'd expect: 1, 2 and 3.

        Activity

        Hide
        Bob Tiernay added a comment -

        I may have duplicated this bug in GRECLIPSE-1266. Weird timing

        Show
        Bob Tiernay added a comment - I may have duplicated this bug in GRECLIPSE-1266 . Weird timing
        Hide
        Andrew Eisenberg added a comment -

        @Bob...yep, you were beaten to it.

        This is a good test case since we don't handle inner classes particularly well, either. The way we need to fix this is to add the concept of an outer type to the inferencing engine, and allow inferring to look at outer types if the current identifier cannot be resolved in the context of the inner type.

        Show
        Andrew Eisenberg added a comment - @Bob...yep, you were beaten to it. This is a good test case since we don't handle inner classes particularly well, either. The way we need to fix this is to add the concept of an outer type to the inferencing engine, and allow inferring to look at outer types if the current identifier cannot be resolved in the context of the inner type.
        Hide
        Andrew Eisenberg added a comment -

        Working better inferencing in closures. #3 will be working once I commit all the changes.

        Show
        Andrew Eisenberg added a comment - Working better inferencing in closures. #3 will be working once I commit all the changes.
        Hide
        Andrew Eisenberg added a comment -

        Just to be clear, #1 and #2 are still not handled.

        Show
        Andrew Eisenberg added a comment - Just to be clear, #1 and #2 are still not handled.

          People

          • Assignee:
            Unassigned
            Reporter:
            Aled Sage
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: