16 | util.Random.shuffle(???) [error] | ^ [error] |ambiguous implicit arguments: both getter buildFromString in object BuildFrom and getter bu ildFromWrappedString in object BuildFrom match type scala.collection.BuildFrom[(?1 : Nothing), T, C] of parameter bf of method shuffle in class Random
sbt> consoleQuick Welcome to Scala 3.1.1-RC1-bin-20211014-af9594d-NIGHTLY-git-af9594d (11.0.11, Java OpenJDK 64-Bit Server VM). Type in expressions for evaluation. Or try :help. scala> util.Random.shuffle(???) -- Error: ---------------------------------------------------------------------- 1 |util.Random.shuffle(???) | ^ |ambiguous implicit arguments: both getter buildFromString in object BuildFrom and method buildFromView in object BuildFrom match type scala.collection.BuildFrom[(?1 : Nothing), T, C] of parameter bf of method shuffle in class Random 1 error found scala>
tree.srcPos.startPos.nonInlineddoes not seem to bring me what I want.
util.SrcPos, and I can deal with that, however it's not the proper position.
munit.Locationmacro works by embedding the source file contents at compile time instead of reading the file contents from disk at runtime. The benefit of embedding the source at compile time is that 1) it works with Scala.js in the browser and 2) it works with remote build caching and distributed testing features that are available in build tools like Gradle and Bazel
munit.Locationvalue will explode the size of the compiled code (bytecode and tasty) but if the literal gets added to the constant pool then this concern is maybe unwarranted
If you create an arbitrary tree and use it in multiple places (without changing its position or type) then it will also only be pickled once in tasty (the other occurrences will just point to the first pickled one)
That's good to know, it might make sense to try to reuse the same tree instance for the string literal, although I'm not sure who to do that cleanly without a global cache
[error] dotty.tools.dotc.core.Denotations$StaleSymbol: stale symbol; type OutW#33717 in trait CompanionsDFBits$Token$Candidate, defined in Period(1..55, run = 2), is referred to in run Period(1..1, run = 3) [error] dotty.tools.dotc.core.Denotations$SingleDenotation.staleSymbolError(Denotations.scala:955) [error] dotty.tools.dotc.core.Denotations$SingleDenotation.bringForward(Denotations.scala:754) [error] dotty.tools.dotc.core.Denotations$SingleDenotation.toNewRun$1(Denotations.scala:803)
error] java.lang.AssertionError: assertion failed: completing method fromIntLiteral in wrong run 3, was created in 2 [error] scala.runtime.Scala3RunTime$.assertFailed(Scala3RunTime.scala:8) [error] dotty.tools.dotc.typer.Namer$Completer.complete(Namer.scala:776) [error] dotty.tools.dotc.core.SymDenotations$SymDenotation.completeFrom(SymDenotations.scala:168) [error] dotty.tools.dotc.core.Denotations$Denotation.completeInfo$1(Denotations.scala:188)
Hi. I found that the
mod method of the
BigInt class behaves differently in 2.13.5 and 2.13.6. Since 2.13.6,
BigInt has been using
Long, instead of Java
BigInteger, for small integers as optimization (scala/scala#9628). While
mod throws an exception for a negative divisor,
% always succeeds. For this reason,
mod throws an exception for a negative divisor in 2.13.5, while it succeeds in 2.13.6.
scala> BigInt(2) mod BigInt(-3) java.lang.ArithmeticException: BigInteger: modulus not positive at java.math.BigInteger.mod(BigInteger.java:2559) at scala.math.BigInt.mod(BigInt.scala:246) ... 38 elided
scala> BigInt(2) mod BigInt(-3) val res0: scala.math.BigInt = 2
I'm wondering whether it's an intended change. In the library documentation,
mod is defined as follows:
def mod(that: BigInt): BigInt Returns a BigInt whose value is (this mod that). This method differs from % in that it always returns a non-negative BigInt. that: A positive number
Does this mean that
mod throws an exception when
that is not positive? If so, 2.13.6's behavior might be considered buggy. Otherwise, does this mean that
mod's behavior is unspecified when
that is not positive so that it may change silently?