Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ErrorType instead of throwing in match type "no cases" #18016

Merged
merged 1 commit into from
Jun 24, 2023

Conversation

dwijnand
Copy link
Member

Instead of throwing MatchTypeReductionError, return
ErrorType(MatchTypeNoCases), which is a proper message as well.

This avoids having to catch and ignore it as an exception. But it does
require discovering it from type simplification and reporting it then -
which replaces its reliance on catching TypeErrors.

It also required handling scrutinees that are error types, which
previously would always match the first case, due to FlexType semantics.

shared-applies.scala Outdated Show resolved Hide resolved
@dwijnand dwijnand marked this pull request as ready for review June 21, 2023 09:56
@dwijnand dwijnand requested a review from sjrd June 21, 2023 09:56
Copy link
Member

@sjrd sjrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good. I have one minor comment.

@@ -3115,7 +3115,11 @@ class Typer(@constructorOnly nestingLevel: Int = 0) extends Namer
case xtree: untpd.NameTree => typedNamed(xtree, pt)
case xtree => typedUnnamed(xtree)

val hadErroneus = result.tpe.isErroneous
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
val hadErroneus = result.tpe.isErroneous
val hadErroneous = result.tpe.isErroneous

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isErroneous look like it performs a type traversal, so it seems expensive for no reason in the happy path.

Consider storing val unsimplifiedType = result.tpe instead, and only check unsimplifiedType.isErroneous later, in the guard of case e: ErrorType. This way, we avoid the traversal in the happy path where we don't get an ErrorType.

@sjrd sjrd assigned dwijnand and unassigned sjrd Jun 23, 2023
Instead of throwing MatchTypeReductionError, return
ErrorType(MatchTypeNoCases), which is a proper message as well.

This avoids having to catch and ignore it as an exception.  But it does
require discovering it from type simplification and reporting it then -
which replaces its reliance on catching TypeErrors.

It also required handling scrutinees that are error types, which
previously would always match the first case, due to FlexType semantics.
@dwijnand dwijnand merged commit be42772 into scala:main Jun 24, 2023
@dwijnand dwijnand deleted the mt/reduce-to-ErrorType branch June 24, 2023 14:21
@Kordyjan Kordyjan added this to the 3.4.0 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants