Incorrect "Cannot assign '...' to '...'" Diagnostic

JetGroovy is giving an incorrect "Cannot assign 'User' to 'Task'" error in one of my domain class methods:

Task.
    */

    Task    \
    clone()
    {
        Task                        newTask                 = new Task()

        newTask.name            =   name
        newTask.notes           =   notes
        newTask.action          =   action
        newTask.valid           =   valid
        newTask.personal        =   personal
        newTask.givens          =   (byte[]) givens.clone()
        newTask.givensMode      =   givensMode
        newTask.task            =   (byte[]) task.clone()
        newTask.taskMode        =   taskMode
        newTask.owner           =   owner
//      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Cannot assign 'User' to 'Task'"
    }
]]>



Randall Schulz

13 comments
Comment actions Permalink

Hehe, everything is correct. You are not returning newTask from clone(), thus an implicit return of the last expression is done which is of type User.

Eugene.

0
Comment actions Permalink

Still the diagnostics could be better indeed.

0
Comment actions Permalink

When will I ever stop using copy-and-modify...

I took a clone() method from another somewhat similar domain class but forgot the return statement...


RRS

0
Comment actions Permalink

Well, bugs like this reassure me in that our inspections are not useless:)

Eugene.

0
Comment actions Permalink

To be sure.

But please keep in mind the point I've made a couple of times previously, that a huge number of "cannot determine type statically" diagnostics create so much "noise" that people tend to miss the hepful ones.


Randall Schulz

0
Comment actions Permalink

But this are not even warnings! Are you confused by the fact those are included in F2 navigation? As for underlining, you can change visual presentation to whatever you like in "Colors and Fonts/Groovy"

0
Comment actions Permalink

I don't think I'm confused at all. Are you missing my point?

A lot of repeated warnings about things that are ordinary, everyday, inevitable state of affairs in a Groovy-based language like GSP are counterproductive. Their mere presence and the fact that they tell me nothing useful while producing a flurry of tool-tips as I move the mouse over my code makes them a 100% detriment to productivity.


Randall Schulz

0
Comment actions Permalink

No, I see your point, hope you see mine. These are not warnings, these are just visual clues to where you should be more cautious, cause we are unable to validate it. If you think tooltips are getting in your way, well, we may try turning them off. But I don't think the feature as a whole must be removed, even in GSP.

Eugene.

0
Comment actions Permalink

I'm certainly not asking for things to be permanently removed or "turned off," but rather that much more refinement in the analysis is needed. This seems to me to be entirely consistent with the IDEA philosophy. It's just that Groovy and Grails rely far more on dynamic typing and this necessarily demands a more sophisticated approach to generating heuristic diagnostics.

Randall Schulz

0
Comment actions Permalink

I have a similar problem.
I have code such as

def foo =
{
println "bar"
}

The editor will highlight the closure with a warning of "Cannot assign 'groovy.lang.Closure' to 'java.lang.Object'"

Also I cannot create a field of type Closure. Even after the import of groovy.lang.Closure, the editor marks it as an error saying that it "cannot resolve symbol Closure"

0
Comment actions Permalink

This appears to have been a hedge case related to Idea's module management.

One module had mistakenly included the same content root as the second module. When working in the second module, even though it had its dependencies correctly set up, it was using the dependencies from the first module, and ignoring the Groovy imports, or something like that.

Sorry for the turbulence.

0
Comment actions Permalink

Eugene,

Are you referring to the "Untyped member access" setting in Groovy Colors&Fonts?

It looks like this setting allows control over the behavior, however the ("informational") error stripe is always drawn, even when not enabled for "Untyped member access".

0
Comment actions Permalink

Seems like a bug to me that should go to idea core...

Eugene,

0

Please sign in to leave a comment.