ErrorType instead of throwing in match type "no cases" #18016
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sjrd
reviewed
Jun 20, 2023
dwijnand
force-pushed
the
mt/reduce-to-ErrorType
branch
from
a53253a to
1db8a3f
Compare
sjrd
requested changes
Jun 23, 2023
| @@ -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 | |||
There was a problem hiding this comment.
Suggested change
| val hadErroneus = result.tpe.isErroneous | |
| val hadErroneous = result.tpe.isErroneous |
There was a problem hiding this comment.
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.
dwijnand
force-pushed
the
mt/reduce-to-ErrorType
branch
from
1db8a3f to
167c88d
Compare
sjrd
approved these changes
Jun 23, 2023
dwijnand
force-pushed
the
mt/reduce-to-ErrorType
branch
from
167c88d to
6b41901
Compare
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
force-pushed
the
mt/reduce-to-ErrorType
branch
from
6b41901 to
9ae1598
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.