Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

custom nonEmpty mutated to isEmpty that doesn't exist #188

Closed
jozic opened this issue Apr 8, 2019 · 3 comments · Fixed by #946
Closed

custom nonEmpty mutated to isEmpty that doesn't exist #188

jozic opened this issue Apr 8, 2019 · 3 comments · Fixed by #946
Labels
bug Something isn't working

Comments

@jozic
Copy link
Contributor

jozic commented Apr 8, 2019

Summary

I have an object with method named nonEmpty, like

object QueryParams {
  def nonEmpty: QueryParams = ???
}

and call QueryParams.nonEmpty is mutated to QueryParams.isEmpty
which of course doesn't compile

Stryker4s config

default

Stryker4s environment

stryker4s 0.3.3

Your Environment

software version(s)
Scala version 2.12
Build tool & version maven
Operating System linux mint 18 (ubuntu 16.04)
@hugo-vrijswijk
Copy link
Member

Thank you for your issue report! Unfortunately, this is a known problem. The issue is that currently there is no way to distinguish if a mutation is possible, other than based on syntax. And if something goes wrong, we have no rollback process implemented (#14). As a temporary fix, you could always ignore the file to be mutated with the following stryker4s.conf:

stryker4s {
  mutate: [ "**/main/scala/**/*.scala", "!**/QueryParams.scala" ]
}

@jozic
Copy link
Contributor Author

jozic commented Apr 8, 2019

@hugo-vrijswijk
So my understanding is that nonEmty/isEmpty is aimed at collections, is that right?
If so, then can we also check the type before applying this mutation? Not sure how easy that is, but sounds possible, wdyt?

@hugo-vrijswijk
Copy link
Member

It should be possible, yes! Likely either by using SemanticDB or through an experiment with TASTY. I tried a little experiment with SemanticDB a while back, but didn't get as far as I would've liked.

Ideally, we'd do both (type check and compile rollback), but that is likely a little further down the line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants