wartremover/Lobby

Rob Cornell

@rcornell

To exclude a file or directory from all checks, use wartremoverExcluded in your build.sbt file:

wartremoverExcluded += baseDirectory.value / "src" / "main" / "scala" / "SomeFile.scala"
wartremoverExcluded += sourceManaged.value

@JohnReedLOL

Philipp Martini

@maphi

Hey, it looks like wartremover and better-monadic-for get in their way:

for {
  ...
  (a,b) = foo
} yield ()

this reports error: [wartremover:NonUnitStatements] Statements must return Unit

any suggestions? is there an order to specify for sbt scalac plugins?

Philipp Martini

@maphi

btw: using wartremover 2.3.7 and better-monadic-for 0.3.0-M4

Philipp Martini

@maphi

Problem solved by better-monadic-for maintainer: Fix is adding scalacOptions ++= Seq("-P:bm4:no-map-id:n", "-P:bm4:no-tupling:n"),

Nikolay Danshin

@nDanshin

hello, guys. I have sbt 0.13.6 and Scala version 2.12.4. And I try to add wartremover. Which version of it should I use?
addSbtPlugin("org.wartremover" % "sbt-wartremover" % "2.3.7") thats ok?

John-Michael Reed

@JohnReedLOL

@nDanshin - just copy-pasting whatever it says on the website/docs. If you don't know how to use sbt, read the sbt docs first.

Hey, I want to add WartRemover to an old multi-project Build.scala file. I am talking sbt version 13.5 old. How do I do that?

Victor Viale

@Koroeskohr

hi there ! I tried fiddling with the project today, and realised that the Var wart wasn't caught when a var is defined inside a trait, is there a reason why ? :)

Ólafur Páll Geirsson

@olafurpg

@Koroeskohr that could be because var inside traits desugar into private fields with a setter method

Nicolas Rinaudo

@nrinaudo

I'm hitting something that feels like a bug: with Scala 2.13, the StringPlusAny wart will trigger on string interpolation

is that working as intended?

Greg Pfeil

@sellout

@nrinaudo I feel like that is the correct behavior (unless you’re interpolating a String).

Nicolas Rinaudo

@nrinaudo

oh, it's been pointed out that there's actually a bug open for that: wartremover/wartremover#447

@sellout I think it's debatable. You might want to disallow string interpolation with non string members, but:

that seems harsh!
it's really odd that it'd trigger StringPlusAny

I think I understand the purpose of StringPlusAny, and that's not it

(but I might be wrong in that)

Greg Pfeil

@sellout

What is the purpose if not to avoid automatic conversion to String? Like, how is "some ${foo} string" different from "some " + foo + " string"?

Nicolas Rinaudo

@nrinaudo

well, because I'd assume it to be equivalent to "some " + foo.toString + " string", which I would have thought triggered ToString

Greg Pfeil

@sellout

In my own code bases, anything that resulted in a call to toString would be a bug, but I know that my use case is not everyone’s.

Nicolas Rinaudo

@nrinaudo

maybe I'm just not thinking about this right

oh, sure, that's not what I'm arguing. I'm saying that it feels like the wrong wart is triggered

Greg Pfeil

@sellout

Ah, I see.

So, there’s another wart to catch use of toString.

Nicolas Rinaudo

@nrinaudo

yeah. ToString

If that were triggered by string interpolation, I'd get it. But StringPlusAny feels confusing for newcomers - it's another of these failures where the root cause is hidden

and... does it mean that you basically do not use string interpolation, by the way?

Greg Pfeil

@sellout

Yeah, I don’t. Not for any good reason. But I wonder if there was a change in Scala 2.13 to have interpolation expand to + foo + instead of + foo.toString +? It seems like that would be a simplification that could prevent diverging semantics – i.e., it means that interpolation and concatenation both have the same conversion semantics, rather that having interpolation do its own string conversion, which could get out of sync with that for concatenation. Since both are currently defined to use .toString, it wouldn’t change behavior, but could change how it’s seen by WartRemover.

Nicolas Rinaudo

@nrinaudo

I believe that's the case, yes

@som-snytt @nrinaudo string interpolator converts to string + now.
If you didn't like string interpolation before, you won't ike string_+ either. It's all stringifications.

Greg Pfeil

@sellout

I think this is a case where those two warts should be a single thing like ImplicitStringConversion. Having each wart catch one low-level pattern makes these things a bit more fragile, where an “invisible” change becomes exposed.

I use Warts.AllBut(Any, Nothing) – but I guess most people probably want something more fine-grained than that 😆

Ghost

@ghost~54f4b69115522ed4b3dcb16d

In the spirit of TMI, they wanted to make s-interpolator more efficient, so instead of a loop calling stringbuilder.append, you get a "" + arg expression that the platform can optimize. Maybe StringBuilder.append(Object) is the missing wart.

Warts.andAll.

If you use Warts.andAll, your code still passes the build even if it's really ugly.

Nicolas Rinaudo

@nrinaudo

But I like string interpolation:(

Greg Pfeil

@sellout

@nrinaudo You can still use string interpolation – just "some ${foo.show} string".

Ghost

@ghost~54f4b69115522ed4b3dcb16d

Is it worth adding that you can have a show interpolation that takes implicits? You can call it s"" for show.

Greg Pfeil

@sellout

Oh, right! That’s a thing that exists already. I actually don’t use Show, either – just explicit functions that result in a String. But yeah, that’s definitely a useful thing to remember that would also silence the wart.

udalrich

@udalrich

It seems difficult to use MutableList with Warts.unsafe. val list:MutableList[Integer] = MutableList(); list += 4 fails to compile, as list += 4 does not return unit. I haven't tried, but I suspect var list = List[Integer](); list = list + 4 would fail the Var wart

ritschwumm

@ritschwumm

@udalrich Warts.unsafe and MutableList sound like a weird combination - like making absolutely sure there's not a single knife in the house to so the kids won't ever hurt themselves, and then buying them a chainsaw as a birthday present...

udalrich

@udalrich

It seemed like Wars.unsafe was a recommended/good if you can get there setting. My use case is this. I have a bunch of objects from a 3rd party library. I need to remember which ones I have done a particular action with, and I can't query the object to find out if I did it. So I have code like def doStuff(x: Thing) = { x.doThing(); list.add(x) } so that list holds the Things I have operated on. How would I write that with Warts.unsafe?

udalrich

@udalrich

I had code that did

if (list.isEmpty) {
  stuff(list.head, list.tail)
} else {
  otherStuff()
}

Warts.TraversibleOpts told me to use headOption instead. Warts.OptionPartial won't like

list.headOption.ifPresent(stuff(_, list.tail)).orElse(() => otherStuff()).get

but I don't see another way to do it. getOrElse(otherStuff()) is wrong, because calling otherStuff is wrong if the list is not empty.

I suspect the problem is that Option should have a getOrElse that takes a function to build the result, not just getOrElse(T). Is there another way to do this?

ritschwumm

@ritschwumm

@udalrich how about this?

list match {
  case Nil    => otherStuff()
  case h :: t => stuff(head, tail)
}

and btw getOrElse does take a function under the hood: the type of its parameter is =>T and not T, so the parameter will not be evaluated in the nonEmpty case

udalrich

@udalrich

That would work. I'm new enough to scala that writing getOrElse(otherStuff()) looks like it should always call otherStuff.

Where communities thrive

People

Repo info

Activity