Type analysis using SemanticDB

[hugo-vrijswijk]

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:

• What happens if the to-mutate statement is on a different type? Scala has a lot of options for this: super-types, implicit classes, etc. Not sure how we would search/check for those.
• 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
• Sbt provides integrated semanticdb generation for source code. Maven does not. Will this also work with Maven?
• The PoC is fairly buggy. There are some problems:
  • Performance: it seems slow. Would loading SemanticDB info for every dependency and the whole project actually be faster than compile rollback?
  • Doesn't work on JDK11 (I think? Investigation needed)
  • Doesn't (seem to) work with the latest Scalameta/SemanticDB versions
  • Doesn't (always?) seem to work on Linux
  • Gathering SemanticDB info for dependencies like it's done in the PoC seems hacky/error prone to me. This should probably be done in a different way

Input very welcome :)

[MercurieVV]

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.

[MercurieVV]

I was wrong. I used outdated SemanticDB

[hugo-vrijswijk]

@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?

[MercurieVV]

Ok. I tested version 4.3.9 My findings are following.

• Regarding performance.
  I parsed jre+scala+3 scala file
  SBT task to compile+generate DB run (after cleaning) took about 17 seconds.
  Simpliest test run about 20 seconds on my laptop.
  I suppose its not much for mutation testing. As I understand - it create/load db only once per run.
• Regarding JDK 11. I run it on JDK11 and it was ok.
• I see that SDB provide information for intermediate statements.
• I run it on windows and had no issues

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.

[MercurieVV]

• Inheritance/Hierarchy is presented
• I checked typeclass method execution. I see that DB reflects typeclass Trait and used implementation in point of call.