Open hugo-vrijswijk opened 5 years ago
I think SemanticDB doesn't provide information on 'intermediate' statements. E.g.: list.filterNot(f).head will give info on list and the type returned by .head, not .filterNot, which we are also interested in
I checked this situation in debugger. Looks like intermediate data is returned, but seems there is another possible problem - SDB have information only about our sources. So, for example if it know that we calling "filter()" from TraversableLike
, it dont know is TraversableLike
have .filterNot()
method or any other, as it dont have its sources.
I was wrong. I used outdated SemanticDB
@MercurieVV Thanks for looking into it! Last time I had a look I found the same. Back then I thought maybe compiling any dependencies to semanticdb would be the solution, but that would be a very large performance hit. Can you share your findings?
Ok. I tested version 4.3.9 My findings are following.
I had error if I delete db files manually (leaving class files untouched) and run sbt task again. I expected that it should create DB files again, but it doesnt. Dont think its big problem.
We could do type analysis before we mutate code using SemanticDB. Using type analysis, we can be sure a mutation is actually possible. Example: only mutate a
.filter
if the statement's type also has a.filterNot
. This way we will get a lot less compile errors (also see #188).I've made some sort of proof of concept in a separate repo that checks if a
.filter
has a.filterNot
.Some notes:
list.filterNot(f).head
will give info onlist
and the type returned by.head
, not.filterNot
, which we are also interested inInput very welcome :)