Expr#show: Don't crash when the expression contains an unsupported type (like a SkolemType)

[smarter]

When the SkolemType appears as the prefix of a TypeRef, we avoid it by using qualifier which is defined in QuotesImpl to widen skolems, but skolems can appear in any position, and so before this change we would get a compiler crash in the added test case where the skolem appears as the prefix of a TermRef.

We fix this by adding fallback cases in the quotes pretty-printer, now for the test case we get:

Test.f.ho(((arg: <<SkolemType(693709097) does not have a corresponding extractor> does not have a source representation>.x.type) => arg))

Which isn't great, but better than a crash.

Maybe we should run Type#deskolemized on a type before trying to print it in SourceCode/Extractors, but currently these files are intentionally defined to not depend on compiler internals and do not have a Context so we cannot even call deskolemized on them.

Alternatively, maybe SkolemType should be a tasty-reflect constructor but that would also be a pretty big change.

[nicolasstucki]

This code was intentionally made to crash to ensure that users would report these issues. If we print them as a string, there is the danger that bugs will go unreported.

Maybe we should run Type#deskolemized on a type before trying to print it in SourceCode/Extractors

A more complete way to deal with these would be to descolemize all the types before they are given to the user as a Type or TypeRepr. This might be computationally expensive and fragile.

[smarter]

The problem with a crash is that it makes it hard to diagnose unrelated issues. It even breaks using -Xcheck-macros when it tries to print something

[jchyb]

Maybe reporting a warning with explicit instructions to report the issue in the fallback print case would be enough? Outside of this issue with printing/reporting, I'll try to figure something out for SkolemTypes specifically, maybe deskolemizing only if we need to will not be that bad

[smarter]

maybe deskolemizing only if we need to will not be that bad

The problem with deskolemizing in the error is that it can be actively misleading: it's possible my macro doesn't work just when skolems are involved, so if I try to print types for debugging and the compiler hides the skolem from me, then I'm going to be very confused and won't be able to find the root cause of my macro issues.

I think that fundamentally, trying to hide some types from the user just does not work: the abstraction is leaky, and it leads to unsolvable issues when the user cannot match what the compiler expects.

[jchyb]

Thank you for the explanation above and apologies for long wait.