Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 17:16
    som-snytt commented #12438
  • 15:24
    SethTisue edited #1501
  • 14:28
    SethTisue edited #795
  • 14:27
    SethTisue edited #795
  • 14:27
    SethTisue edited #795
  • 14:26
    SethTisue edited #795
  • 14:26
    SethTisue edited #795
  • 14:26
    SethTisue edited #795
  • 14:23
    SethTisue edited #1501
  • 14:22
    SethTisue labeled #1501
  • 14:22
    SethTisue assigned #1501
  • 14:22
    SethTisue opened #1501
  • 14:19
    SethTisue demilestoned #470
  • 14:19
    SethTisue milestoned #470
  • 12:34
    bishabosha commented #9791
  • 12:17
    bishabosha commented #9697
  • 12:08
    prolativ commented #9697
  • 09:42
    lrytz commented #9793
  • 09:39
    som-snytt commented #9794
  • 09:13
    som-snytt synchronize #9794
Bjorn Regnell
@bjornregnell
Aha!! Found even more minimal: util.Random.shuffle(???) which crashes the compiler with head of empty list. Is this a known bug?
Can someone else also get the compiler to crash by that?
Oron Port
@soronpo
@bjornregnell I'm getting:
 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
Bjorn Regnell
@bjornregnell
What version?
I'm getting the same crash in sbt consoleQuick using 3.1.0-RC2 as well as 3.0.2 and 3.0.1
But no crash in 2.13.6
Oron Port
@soronpo
I'm currently on a local somewhat close to a master branch
So it's a 3.1.1.RC-1 snapshot
Maybe you can try with a nightly
E.g. 3.1.1-RC1-bin-20211014-af9594d-NIGHTLY
Bjorn Regnell
@bjornregnell
Works with nightly! No crash then:
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>
Thanks @soronpo ! I'll close the issue.
Bjorn Regnell
@bjornregnell
@soronpo Does this mean that the release 3.1.0 will include the fix it or do we have to wait until 3.1.1?
Bjorn Regnell
@bjornregnell
As 3.1.0-RC3 also crashes, I'm unsure if I should leave the issue open or close it?
Oron Port
@soronpo
If it is a critical issue that can be backported, it may warrant RC4. But I have no idea what determines that.
Bjorn Regnell
@bjornregnell
OK I'll leave it open and the maintainers can decide if it should be closed or not.
som-snytt
@som-snytt
I noted that it duplicates an issue (which should also be closed) with shorter repro util.Random.shuffle.
Bjorn Regnell
@bjornregnell
ok thanks; so well be living with this until 3.1.1; but at least it only crashes due to erroneous code
TIL how tricky it can be to find a lean and mean reproduction :)
Oron Port
@soronpo
Anyone here familiar enough with compiler internals to let me know how can I get a tree.srcPos that also reflects the proper positioning if the tree was inlined?
tree.srcPos.startPos.nonInlined does not seem to bring me what I want.
It returns SourcePosition and not util.SrcPos, and I can deal with that, however it's not the proper position.
Macro meta-programming is very shallow rabbit hole compared to compiler plugins. Complete guess work here.
Ólafur Páll Geirsson
@olafurpg
Does tasty implement some kind of constant pool for string literals that appear repeatedly in the same tree?
I'm looking to change how the munit.Location macro 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
My concern is that embedding the file contents as a string literal for every munit.Location value 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
Ólafur Páll Geirsson
@olafurpg
A small experiment seems to validate that duplicating a large string literal in the same file does not increase the size of the emitted Tasty, which hints to me that Tasty does pool string literals
Guillaume Martres
@smarter
Constant strings go into the name table yes.
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)
Same for types, though a lot of types are hash-consed, so even if you create the same type multiple times it will usually only be stored once in memory and in tasty
Ólafur Páll Geirsson
@olafurpg
@smarter thank you for confirming! That's great news :)

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

The position of the string literal tree isn't important, it won't appear in stack traces or in diagnostics
Guillaume Martres
@smarter
well, the tree instance itself will be a Literal that points to the constant, so it's only a few bytes in tasty
Oron Port
@soronpo
Any suggestion how to work around this death-sentence to my codebase? Minimizing this will be hell, and I doubt it will be fixed quickly due to its nature. I need an escape route.
[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)
Guillaume Martres
@smarter
are you defining a macro and using it in the same project?
Oron Port
@soronpo
Yes, but this is not derived from a macro.
Guillaume Martres
@smarter
even so, you can run into issues: lampepfl/dotty#13532
what's the full stacktrace?
Oron Port
@soronpo
Saved by the Aux pattern!!!!
I've been walking a fine-line for a while here with the incremental compilation limitations. I'll save the codebase with the error for a later time when I have the mental capacity for minimization that will take at least a day.
Oron Port
@soronpo
My right hand for a Scala minimization script.
Oron Port
@soronpo
Another hidden error that I'm currently working around is:
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)
I have the feeling these two are related
rcano
@rcano
When using tasty inspector, the Quotes instance doesn't seem capable of returning any TypeRepr.of[], I tried types from scala, java, anything. I played with the settings to give it jars, a directory with classes, the classpath, anything I could think of. Is this the expected behavior?
Jaemin Hong
@Medowhill

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 BigInteger's mod throws an exception for a negative divisor, long's % always succeeds. For this reason, BigInt's mod throws an exception for a negative divisor in 2.13.5, while it succeeds in 2.13.6.

2.13.5:

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

2.13.6:

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?

Oron Port
@soronpo
To me this seems to be a bug in 2.13.6. The reason is simple. We cannot have the function behave differently once the number values go beyond 64bits.
Whether the behavior is specified or not is irrelevant when you are looking for consistency across all possible value entry for the function.