#9268 Port genMatch from scala-js/GenJSCode (WIP, do not merge)

[devkat]

This is a copy of the genMatch method and its dependencies from GenJSCode with minor modifications to make it compile.

Some remarks / open issues:

• There is an issue with comparing boxed chars in alternatives (see Pattern matching with alternatives is compiled to "throw null" with Scala.js #9268).
• The genMatchEnd method (https://github.com/devkat/dotty/blob/scalajs-tests/compiler/src/dotty/tools/backend/sjs/JSCodeGen.scala#L3559) used to take a LabelDef which has params. I have no idea how to handle this with Labeled (see FIXME on line 3572).
• Some of the code can probably be removed or simplified, particularly the code which was required due to issues with the 2.x compiler.
• I didn't remove any warts (var etc.) since I'm not familiar enough with the coding guidelines yet and I don't know how much optimization already went into the code.

[dottybot]

Hello, and thank you for opening this PR! 🎉

All contributors have signed the CLA, thank you! ❤️

Commit Messages

We want to keep history, but for that to actually be useful we have
some rules on how to format our commit messages (relevant xkcd).

Please stick to these guidelines for commit messages:

1. Separate subject from body with a blank line
2. When fixing an issue, start your commit message with Fix #<ISSUE-NBR>:
3. Limit the subject line to 72 characters
4. Capitalize the subject line
5. Do not end the subject line with a period
6. Use the imperative mood in the subject line ("Add" instead of "Added")
7. Wrap the body at 80 characters
8. Use the body to explain what and why vs. how

adapted from https://chris.beams.io/posts/git-commit

Have an awesome day! ☀️

[sjrd]

As I said on the issue. You can scrap everything that takes care of Labeled things. In scalac we have to reverse-engineer LabelDef definitions and jumps to them, but not in Dotty, because the Labeled blocks are correctly compiled to the Scala.js IR once and for all in case Labeled(bind, expr) =>.

[devkat]

Thanks for the explanation, but I'm still too much of a newbie to understand what exactly I can remove. Is there any documentation about this?

Can I remove the whole defaultLabelSym value? What shall I do where it is used, e.g.

        case app @ Apply(_, Nil) if app.symbol == defaultLabelSym =>
          genJumpToElseClause

[sjrd]

Yes, you can remove it. Basically you can consider that defaultLabelSym is always NoSymbol. That means that if app.symbol == defaultLabelSym is basically if false, and that consequently you can remove that case entirely.

From there, you'll figure that genJumpToElseClause is dead code, and hence optElseClauseLabel will never be assigned to a Some. You can therefore replace it by None and remove dead code from there as well.

The domino effect of this strategy will cause a lot of code to be removed.

[sjrd]

This is what would cause a === to be emitted instead of the correct Int_==. The === case should be used only when we are switching on Strings (including null values). In scalac, patmat makes sure that only primitive Ints or java.lang.Strings can be left in Match and leave the back-end. That test therefore uses === only for strings in scalac. Apparently in dotty other kinds of numeric types survive here, like Chars. Either the back-end should convert them to ints, or PatMat should convert them to Ints.

In any case, here we should end up using === only for Strings and null. Everything should use Int_==.

[sjrd]

It turns out the issues raised by this PR come from the fact that the pattern matcher does not force switch matches to operate on Ints. Instead it can leave (a mix of) Chars, Bytes, Shorts and Ints. scalac does force switch matches coming out of the PatMat phase to operate on Ints, potentially adapting the scrutinee and alternatives to Int.

I have submitted an alternative PR #9411 that deals with this problem.

[smarter]

Closing since #9411 got merged.