Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    ritschwumm
    @ritschwumm
    @dmitrybugakov with the latest version i just have sth like this in my build.sbt: inThisBuild(Seq(wartremoverErrors ++= Seq( ... )))
    Dmitry Bugakov
    @dmitrybugakov
    @ritschwumm thank you)
    PsyfireX
    @PsyfireX
    Does wart remover support flagging discarded values out of the box, or would I have to write a custom rule for that?
    Bijan Chokoufe Nejad
    @bijancn
    @PsyfireX there is a compiler warning for that (which you can turn into an error): "-Ywarn-value-discard"
    PsyfireX
    @PsyfireX
    There's an unfortunate side-effect that -Xfatal-warnings is an "all or nothing" flag, converting every warning into a compiler error.
    There are workarounds, but I'm trying to consider all options which is why I'm also looking at wartremover
    Bijan Chokoufe Nejad
    @bijancn
    yeah I had some success with https://github.com/ghik/silencer for the cases that don't allow any other work arounds
    PsyfireX
    @PsyfireX
    That does seem to be the quickest solution.
    Rob Cornell
    @rcornell
    Hey all, with Maven, is there a way to pass the equivalent of this argument: wartremoverErrors ++= Warts.allBut(Wart.NonUnitStatements)
    Rob Cornell
    @rcornell
    @PsyfireX Any idea about the maven implementation above?
    John-Michael Reed
    @JohnReedLOL
    I am working on a horrible codebase and if I run WartRemover on it, the thing will blow up with thousands of warnings and errors. Is there a way for me to run WartRemover just on a single file in the codebase so that I can ignore all the issues from all the other files? The file consists of a single Scala object or class.
    Rob Cornell
    @rcornell
    You could potentially set it to warnings only: "-P:wartremover:only-warn-traverser:org.wartremover.warts.Unsafe"
    Could also build up exclusions to packages other thanthe one you're focused on:

    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
    Screenshot 2018-12-07 at 10.25.36.png
    @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.