Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Rob Norris
    @tpolecat
    I don't think we're doing anything fancy.
    Russell Cohen
    @rcoh
    cool, thanks
    Rob Norris
    @tpolecat
    np
    Shane Delmore
    @ShaneDelmore
    @rcoh I can’t remember the setting but when I have seen people have wartremover not working in the past it was due to someone overwriting settings in build.sbt instead of appending to them, which caused settings from the wartremover plugin to get overwritten. The fix was just to track down the offending := and replace it with += to append settings without overwriting.
    Russell Cohen
    @rcoh
    I got it working by copying the @tpolecat's config
    Next issue is that it flags usages of asnyc/await as return and NonUnitStatement. Is there a way to get it to run before the async-await macro?
    amarkhel
    @amarkhel
    Hi, I have maven project and want disable some checks. I see it is possible for sbt project, but how to disable check for maven project? Thanks
    František Kocun
    @fokot
    Hi, is it possible to disable checks for one particular method (I call it about 400x in the project so @SuppressWarnings everywhere does not seem like a good idea)? Or does anyone know how to make it working? Calling this https://github.com/sangria-graphql/sangria/blob/master/src/main/scala/sangria/schema/Schema.scala#L346 fails on [wartremover:Any] Inferred type containing Any
    Cam
    @cjtenny
    Hi all, I'm trying to fork wartremover and have a version that disables the -Xfatal-warnings flag (=> global.settings.fatalWarnings), but I can't seem to make a dent - anywhere I try to set it seems to have no effect. Does anybody know where I could effectively change this setting from within the plugin?
    Cam
    @cjtenny
    (moved to scala/contributors)
    Claire Neveu
    @ClaireNeveu
    @/all Would anybody like to become a maintainer for Wartremover? I don't have time to maintain the project anymore.
    If you are a contributor and you would like to become a maintainer, send me your Sonatype account and I'll give you publish rights for the org.wartremover namespace on Maven Central.
    lysium
    @lysium
    Greetings! I'm new to wartremover and love it! I was wondering how you handle situations where the caller of a function provides illegal arguments, eg. calls toMyClass on a string that does not represent MyClass.
    Wartremover correctly dislikes using throw, so let's say I rewrite toMyClass to return an Either. But then what is the caller supposed to do? Call System.exit(1) if toMyClass returnsLeft? I'd like the program to crash (with a stack trace, if possible). Generally, I'd like to know how you handle situations where you used to throw IllegalArgumentException.
    ritschwumm
    @ritschwumm
    ideally they wouldn't compile, right?
    lysium
    @lysium
    Thanks for the insight, @ritschwumm! I think yes and no.
    Yes, because if I'd like it to crash with a stack trace, I wish it did not happen in the first place.
    No, because you cannot control everything: say you read a serialization from a db and that is corrupted for some awful reason. You don't want to continue the program because clearly something is terribly wrong. You don't want your program to not compile, either, though, because usually it is supposed to work.
    Using Wartremover, I cannot throw (which is a good thing!), but what do you do instead?
    ritschwumm
    @ritschwumm
    @lysium it depends - for programming errors i indeed use exceptions. but for every other error conditions i use Either/EitherT/MonadError or something like that.
    lysium
    @lysium
    @ritschwumm So you supress the warning to wartremover in the case of programming errors?
    Rob Norris
    @tpolecat
    If you really do need to throw just suppress the warning. That's completely valid.
    lysium
    @lysium
    I see, thank you.
    Rob Norris
    @tpolecat
    Really there should also be a warning on catch … that's the problematic one.
    lysium
    @lysium
    Good point; there should probably be only a warning on catch, now that I think about it... :-)
    Rob Norris
    @tpolecat
    Yeah from a theoretic point of view throw introduces nontermination, which is fine in the sense that :shrug: there's nothing we can do about it; and catch is a problem because it lets you observe nontermination.
    But in practice you probably don't want to be throwing. ;-)
    lysium
    @lysium
    Yes, I'd like to avoid throwing, too, but how do I do that eg., in the case of programming errors where a function is called with invalid arguments or the serialization in the DB is corrupted?
    Rob Norris
    @tpolecat
    That's when you want to throw. Your program can't continue and should crash.
    Although note that the invalid argument problem can often be prevented by using more precise types.
    lysium
    @lysium
    :thumbsup:
    Edmund Noble
    @edmundnoble
    I have a null pointer exception in ForbidInference.scala:30 in wart remover. Is there any way I can stop this file from being called into?
    I have no idea what's causing this but this is just another compiler crash in a series of compiler stupidities and I just want it all to stop.
    Here's what doesn't work:
      wartremoverExcluded += baseDirectory.value,
      wartremoverErrors in (Compile, compile) := Seq.empty
    lysium
    @lysium
    The comma after .value looks suspicious...
    @edmundnoble ^
    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
    Seems to be the correct syntax?
    Edmund Noble
    @edmundnoble
    No, this is in my settings
    I don't use the bare DslEntry stuff
    Philippe Derome
    @phderome
    is there an easy way to exclude some warts in scope test but using Maven rather than sbt as being recently discussed? I am using Maven compilerPlugin wartremover_2.11
    Some warts such as NonUnitStatements get flagged all the time with Scalatest Matchers.
    Philippe Derome
    @phderome
    I can simply put some disabling annotation at the top of each test class while I use Maven. It does the job.
    Sanjiv Sahayam
    @ssanj
    I'm seeing some false positive inferred type containing Nothing errors even when the Scala compiler can infer the correct types. Anyone seen this before? I logged an Issue: wartremover/wartremover#418
    Dmitry Polienko
    @nigredo-tori
    @ssanj, are you positive the compiler infers the types at constructor calls here? As I understand it, it leaves Right[Nothing, Int] and Left[String, Nothing] (you wrote this much yourself), and then calculates a meet at the level of the if expression, without propagating this back to the calls themselves. And in that case the wart does work as intended.
    However the whole thing is too ephemeral, so it's hard to reason about it without some more data. You could try using -X:typerto see what exactly happens in your toy example - that's described in wartremover Readme.
    Sanjiv Sahayam
    @ssanj
    I guess the question I have at the moment is whether to fix the errors outlined by the wart, because even though at the definition point Right and Left infer Nothing, when actually returned through the function in which they are defined in, the types are correct. So any code using the function would get the correct types. But I will have a look with the typer to see what's going on.
    Greg Pfeil
    @sellout
    wartremover/wartremover#263
    Dmitry Polienko
    @nigredo-tori
    @ssanj, here it is. Works as expected.
        def withTypes(value: Int): Either[String,Int] = if (value.>(10))
          scala.`package`.Right.apply[Nothing, Int](value)
        else
          scala.`package`.Left.apply[String, Nothing](scala.StringContext.apply("less than 10: ", "").s(value))
    Greg Pfeil
    @sellout
    @ssanj Ah, couldn’t figure out your handle via the iOS app. But that issue number is for you.
    Sanjiv Sahayam
    @ssanj
    @sellout Thanks! :)
    Sanjiv Sahayam
    @ssanj
    @nigredo-tori Your sample does work as expected, but the version I presented earlier doesn't. I wonder why?
    Dmitry Polienko
    @nigredo-tori
    @ssanj, I probably was not clear enough. The sample I gave is what the typer produces, and it's what wartremover sees. So as expected it sees Nothing and complains.
    However if you feed this fully typed code to the compiler from the start, the typer does not mark the Nothing node as an inferred type, so wartremover assumes it was provided by the user, and does not raise any warnings.
    Sanjiv Sahayam
    @ssanj

    @nigredo-tori oh right. Cool. Yeah, I'm trying to avoid giving the compiler the full definition of Right and Left. If I do I can give it the correct types from the start as you mentioned. I don't have to because the compiler infers the correct types to return from withTypes which is how the callers of this method see it and nothing within the withTypes method uses the incorrectly inferred types. Not sure if that makes sense? So I guess what I'm saying is that even if the compiler infers Nothing for a Left or Right, if that expression has an explicit Either type defined (either via a type ascription or return type) that doesn't have Nothing in it, then wartremover can relax because the expected type will be chosen.

    example:

    val l: Either[String, Int] = Left("error") 
    //I don't expect WR to complain because the type ascription sets the correct type for all intents and purposes for the use of l.