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
请先登录再写评论。
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.
Still the diagnostics could be better indeed.
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
Well, bugs like this reassure me in that our inspections are not useless:)
Eugene.
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
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"
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
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.
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
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"
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.
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".
Seems like a bug to me that should go to idea core...
Eugene,