remember the error then, but I tend to go blind to 'known errors' in my pursuit of the main issue I am working on,
tunnel vision. I'll see how Travis likes the formatting of my current PR (whose content passes all the other automated checks). Never a dull moment.
'crash & burn' test of the current scalafmt 2.4.2 (the one you now have in your PR). The error disappeared. I also got
no differences from git (puzzling, given what you say in the PR).
So, sounds like I should skip this error until after your PR is merged. Good, I am looking for a reason to be happy!
(and have plenty of other work to do).
issue seems to not kill Travis, I would rate this one at the annoying & perfection-marring tiny end. Certainly it is not
important enough for me to get over my fear of even reading, no less touching, nscplugin, coward that I am.
I've never tried scalafix with SN because I never got it to work with JVM. Probably lack of investment of time (or lack of mother wit) on my part.
Please let the community know what you discover. Thanks,
Hope I can finish the update and merge/release it :)
Question for the SN team: Is it possible/doable to have literals and compile time conversions to unsigned integer types? I gave a look to scala-native/scala-native#519 and I tried modifying the various generator files Tag.scala.gyb but it's very inconvenient to work with unsigned integer at the moment. For example you can't pattern match:
unsigned match {
case 1.toUInt =>
}Is it possible to automatically consider integer literals unsigned when the value is positive?
CSize to ULong was making changes uglier and uglier. I see where it gets and I share then on scala-native/scala-native#519.I prefer to use signed directly (even in extern objects) in my personal code for this reason.
@lolgab Thank you for taking a run at Issue #519. If a true fix causes so much shrapnel, perhaps an minimal but effective fix is to comment the file with something which says CSize is like ancient C, signed, that unsigned was considered but is infeasible. CSize should only be used for immediate interop layer, then converted to proper Unsigned above that.
Perhaps there is some transformation method we could supply?
Obviously, this will not fix the pothole, but will provide some clue to folks, like me, who fall into it ;-) Perhaps "sorry, you are hosed! but for a good reason".
I continue to be concerned with the signed/unsigned impedence mismatch, but it seems to not be low hanging fruit and
developer time is precious.
Hi @LeeTibbert, If we use the notation with apply and unapply, working with unsigned integers maybe is not that bad. I found some interesting gotchas playing with them. For example:
println(-1.toULong) // 4294967295
println(-1L.toULong) // 18446744073709551615I know why it happens, but, is it what we want?
@lolgab Great work, as is your want/usual. Thank you.
Re: -1.toULong That is certainly two or more orders of magnitude better than what we have now. I concur that it
violates the principle of "least astonishment". I think there is a strong argument that it is arguably correct albeit likely to harm the unwary. For a first round, Iwould certainly live with that gotcha.
Bikeshedding:
I have a dim memory of .toUlong being actual SN scala code, even for int primitives. I think all of us probably would want primitive int and object Integer to act the same way, even if it is 'astonishing'. Is there a way that does not hurt performance to give a warning in the integer negative case? Of course, that leads to requests to suppress/skip the warning.
Or there could be a ULong.toUlong() method for those of us who are willing to use something that 'just works as expected'.
Your thoughts? (Stay safe, stay healthy).
It's the first time I touch the internals of Scala Native :)
PR here: scala-native/scala-native#1744