Fix #21721: make case TypeBlock(_, _) not match non-type Block

[felher]

TypeBlocks are represented as normal Blocks in the Quotes API's implementation. The current TypeTest for TypeBlock is exactly the same as the TypeTest for Block, which means that case TypeBlock(_, _) "matches" every block.

The implementation of unapply on TypeBlockModule, however, gives back (List[TypeDef], TypeTree). It constructs the List[TypeDef] by mapping over every statement of the block, trying to turn it into a TypeDef by using a match with the pattern

  case alias: TypeDef => alias

This seems fine since TypeBlocks are supposed to be just a list of TypeDefs followed by a type as the last expression. Since the TypeTest matches any Block and not only Blocks that are TypeBlocks, the statements can be anything, not just TypeDefs, which lets the whole case TypeBlock(_, _) pattern die with a MatchError.

This commit fixes the problem by making the TypeTest check whether the Block is a type (which in turns checks whether the Blocks expression is a type)

This is my first PR, please let me know if I should change anything or am completely going about fixing this the wrong way, etc.

Also, I could not run the complete test suite on my machine, it died even without making any changes. But I could at least run the positive compilation tests.

Closes #21721

[felher]

I'm a bit unsure whether the failure of the CI has anything to do with the change proposed in this PR.

On my machine, scala3-bootstrapped/testOnly dotty.tools.dotc.CompilationTests runs through fine. No problem like

Error:  Test dotty.tools.dotc.CompilationTests.runAll failed: java.lang.AssertionError: Run test failed, but should not, reasons:
Error:  encountered 1 test failure(s):
Error:    - test 'tests\run\lambda-serialization-gc.scala' timed out, took 179.28 sec
Error:      at dotty.tools.vulpix.ParallelTesting$CompilationTest.checkPass(ParallelTesting.scala:1257)
Error:      at dotty.tools.vulpix.ParallelTesting$CompilationTest.checkRuns(ParallelTesting.scala:1221)
Error:      at dotty.tools.dotc.CompilationTests.runAll(CompilationTests.scala:168)
Error:      ...

I got:

[info] Test dotty.tools.dotc.CompilationTests.runAll started
[=======================================>] completed (1806/1806, 0 failed, 94s)

[hamzaremmal]

Hi @felher, the CI failure has nothing to do with the proposed change. I've restarted the failed job.

[jchyb]

Thank you for submitting this PR, the changes look good. The underlying isType checks if the Block result is a TypeTree, which is only supposed to happen for TypeBlocks, which makes this added guard sufficient.

Apologies for the very long wait - I must have missed this one initially. After some testing, we might also need to add an opposite check for regular Blocks, since now TypeBlocks can be matched into Blocks while containing different types, resulting in similar creashes, but all of this can be done separately.

[hamzaremmal]

FYI: I believe there is an issue with this PR. I've summarized the problem and shared it with @jchyb.

[jchyb]

The problem @hamzaremmal mentioned is that in the reflection api docs we specify that all of the statements of a TypeBlock are supposed to be TypeDefs, but we do not check that here…. I want to refute this point. As I mentioned in my review comment:

The underlying isType checks if the Block result is a TypeTree, which is only supposed to happen for TypeBlocks, which makes this added guard sufficient.

It is impossible in the reflection API to create a regular Block with a TypeTree expr field, so none of that would be matched against TypeBlock. TypeBlock apply however only allows using TypeDefs in place of statements (or, for TypeBlock, aliases). Looking at the types of both, the isType check (which internally actually checks if the expr field is a TypeTree) is sufficient, as it's impossible to create a tpd.Block with non-TypeDef statements and TypeTree result using the reflection API.

About TypeBlocks generated by the compiler (users cannot, and were never able to create them themselves by code)… I actually were not able to get any in a macro. Currently, I believe only parser can create those when parsing a quoted type pattern (like '[type B; List[B]), but by the time a transparent inline macro is expanded, those are already desugared into a different tree). We might want to think about deprecating the TypeBlock methods in the future.