Open KisaragiEffective opened 9 months ago
It seems like you're reporting two issues:
The current (2.13.12) compiler implementation does not consider that the
match
is exhaustive [even though] it has_
arm.
match
expression takes about 3 or 4 minutes to compile.Update: I've edited the description and moved most of the text into "Notes" section.
I'll double-check when I get back to this, but isn't the match analysis skipped if you annotate: (h: @unchecked) match { ... }
? I might still see if we can do better, but I'd say it's arguably acceptable to require that annotation when you have a family of 1866 children..
Yes, it is!
Would it make sense to short circuit exhaustiveness check when there is a plain wildcard as case? It might speed up compilation for lots of code with large-ish ADT.
That's the split off exhaustivity issue, and yes, it should. But for reachability it's not enough.
The current (2.13.12) compiler implementation takes too long time to find unreachable case
Ah, I see. Thanks for the clarification.
We can skip (or, at least use lite algorithm) for finding unreachables if all of following conditions are met:
final
(always hold for Java ones and object
whose super type is sealed trait
types)case VariantX => /* ... */
would be reported as a unreachable)Edit: attached some examples
I changed the title to be more accurately.
@dwijnand should we leave you assigned, do you intend to return to this?
I'm happy to stay assigned to it, but I'm not actively working on this.
Reproduction steps
Problems
There are two issues.
match
expression adds a few minutes (originally reported as "3 or 4 minutes") to compilation time, which is non-negligible.Notes
This is a performance problem: there is a case in real world.
One of them is in "Bukkit", a minecraft server, is providing API for plugging into Minecraft. It provides a class called
Material
, which corresponds in-game item or block per one-by-one. As of today, there are 1866 entries.Upon profiling we saw that
scala.tools.nsc.transform.patmat.PatternMatching$OptimizeMatchTranslator.exhaustive
occupies ~85% of the CPU time (unreachableCase
also does ~15%, that's another story).A work-around is to simply avoid
match
on those enums (ours is avoided by https://github.com/GiganticMinecraft/SeichiAssist/commit/1ad23ea5d778192470c10a95e7049f0920adad42, but preferred to usematch
).The above also applies to Scala 2's "pseudo" enum (
sealed trait
+object
). Some how its shorter (on my machine, its about half) than Java's one (but still slow).If the match has only wildcard arm (or annotate scrutinee with
@unchecked
, thank you @dwijnand) , it will not blow up.