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

Fix splice type variable pattern detection #17048

Merged
merged 1 commit into from
Mar 21, 2023

Conversation

nicolasstucki
Copy link
Contributor

Fixes #17039

@nicolasstucki nicolasstucki self-assigned this Mar 6, 2023
@nicolasstucki nicolasstucki marked this pull request as ready for review March 6, 2023 11:12
@nicolasstucki nicolasstucki removed their assignment Mar 6, 2023
@@ -249,7 +249,7 @@ trait QuotesAndSplices {
val pat1 = if (patType eq patType1) pat else pat.withType(patType1)
patBuf += pat1
}
case Select(pat, _) if tree.symbol.isTypeSplice =>
case Select(pat: Bind, _) if tree.symbol.isTypeSplice =>
Copy link
Member

Choose a reason for hiding this comment

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

  • How are Select where the prefix is not a Bind handled?
  • There are other cases which involve pat like case Apply(fn, pat :: Nil), should those be pat: Bind too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How are Select where the prefix is not a Bind handled?

Those just get the default super.transform(tree). The splitter only needs to extract the bindings of the pattern. For types, these are the type variable inline definitions. If there is a t.Underlying that is not a pattern we assume that it is an explicit splice into the pattern. In case, t is not identified as a type variable because t is part of the path of the type.

There are other cases which involve pat like case Apply(fn, pat :: Nil), should those be pat: Bind too?

These are expression splices ${...} in the pattern. There we can have an arbitrary pattern such as ${x} or ${Expr(x)}. Unlike with types, we do not have a notation or notion of inserting an expression is a quoted pattern.

Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

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

Do we have a spec of quoted pattern matching in the doc? I'm a bit surprised I can write t.Underlying and have t match a definition outside the pattern, I thought you'd need to use backquotes `t`.Underlying like when pattern matching on terms.

@nicolasstucki nicolasstucki merged commit 09a73dc into scala:main Mar 21, 2023
@nicolasstucki nicolasstucki deleted the fix-17039 branch March 21, 2023 13:21
@Kordyjan Kordyjan added this to the 3.3.1 milestone Aug 1, 2023
This pull request was closed.
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.

Crash when matching on Underlying type of a Type
3 participants