feature request: warn when type becomes unknown after refactoring

Types can either be known (declared or inferred) or unknown, in which case IDEA marks them underlined. That is great!

Some refactorings like renaming and such can lead to the situation that a reference with formerly known type now becomes to be of unknown type. This is most often (but not always) an unwanted effect. It would be great if JetGroovy would raise a warning in such a case.

Additionally on my christmas whishlist would be a shortcut (F2?) to quickly cycle through all references of unknown type in the current file - to check whether there are any that should actually be known but are unknown because of typos.

keep up the great work
Dierk

7 comments
Comment actions Permalink

Some refactorings like renaming and such can lead to the situation that a reference with formerly known type now becomes to be of unknown type. This is most often (but not always) an unwanted effect. It would be great if JetGroovy would raise a warning in such a case.

Could you give examples of such refactorings?


Additionally on my christmas whishlist would be a shortcut (F2?) to quickly cycle through all references of unknown type in the current file - to check whether there are any that should actually be known but are unknown because of typos.

Please file a JIRA request for this

0
Comment actions Permalink

Dierk,
Could you please elaborate on when the type becomes unknown as a result of rename refactoring?
This sounds a bug to me.

0
Comment actions Permalink

I should have been clearer that I mean "refactoring" in the broader sense, i.e. not only the automated ones. An example that leads to unknown type:

class A {
int foo() { 1 }
int bar() { foo() } // foo is of known type here
}

class B {}

Refactoring: move method foo (which is not yet automated, so no "bug" in IDEA)

class B {
int foo() { 1 }
}
class A {
int bar() { foo() } // is now marked as being of unknown type (no error marker)
}

This is of course an error in the manual refactoring but issuing a warning here would help avoiding it.

Dierk

0
Comment actions Permalink

So basically you want a highlighting of references that lost their types upon pasting code? Seems reasonable, though the usability of this feature is still to be decided. A request please?

0
Comment actions Permalink

A better-usability feature and easier to implement would be to highlight all references in a pasted fragment with unknown type.

0
Comment actions Permalink

A better-usability feature and easier to implement would be to highlight all references in a pasted fragment with unknown type.


This would nicely combine highlighting and navigation and if it is easier to implement - that's an additional benefit for everybody
(since the feature may then be available earlier ;))

However, it it is only part of the story. The change in "reference quality" (static/inferrerable/dynamic) may appear not only in
the pasted code (although this may be the common case) but in any statement in class A and B (A: a method has gone and
references now become dynamic; B: formerly dynamic references may become static).
Well, not that I would suggest it, but in principle we would also need to consider all classes that reference either A or B,
including subclasses...

0

Please sign in to leave a comment.