wartremover/Lobby

Ó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 😆

som-snytt

@som-snytt

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".

som-snytt

@som-snytt

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.

Stefan E. Mayer

@stefanerwinmayer

Hello, Is there a way to make wartremover work with bloop?

David Roon

@adridadou

hi everyone! I have a question. I’m trying to use the rule NonUnitStatement but I have an issue with parboiled rules

it seems that it sees every rule as a NonUnitStatement

is there a way how to solve that ?

David Roon

@adridadou

looks like the issue is that because parboiled is using macros, the code seems wrong but isn’t

David Roon

@adridadou

I have now another issue that I find interesting. It seems like in Scala 2.13, Seq[T] extends JavaSerializable so it triggers the javaSerializable error

works fine in scala 2.12

Andrey Ivanov

@a-nigredo

Hi all, is it possible for SuppresWarning with custom wart?

I'm using last version of wartremover

nigredo-tori

@nigredo-tori

@a-nigredo, the warts handle SuppressWarnings themselves. So your wart has to support that.

Andrey Ivanov

@a-nigredo

@nigredo-tori thanks

Dmitrii Kostianoi

@DStranger

Hi guys, I have a question, although it might be more of an sbt-in-general type of question, but anyway.
I have a multi-project build for which I'd like to enable wartremover in one place.
I'd like to use something like the following, but it doesn't seem to work.

ThisBuild / Compile / wartremoverErrors := Warts.all
ThisBuild / Test / wartremoverErrors := Seq.empty

I can use the common settings approach, but there must be a better solution.

nigredo-tori

@nigredo-tori

@DStranger, please run inspect foo/Compile/wartremoverErrors in your SBT console (replacing foo with your project identifier), and post the result here.

Where communities thrive

People

Repo info

Activity