dotty.tools.dotc.transform.PatternMatcher.Translator
MatchTranslator
Related Doc:
package Translator
Make a TreeMaker that will result in an extractor call specified by extractor
the next TreeMaker (here, we don't know which it'll be) is chained after this one by flatMap'ing
a function with binder nextBinder over our extractor's result
the function's body is determined by the next TreeMaker
(furthermore, the interpretation of flatMap depends on the codegen instance we're using).
Make a TreeMaker that will result in an extractor call specified by extractor
the next TreeMaker (here, we don't know which it'll be) is chained after this one by flatMap'ing
a function with binder nextBinder over our extractor's result
the function's body is determined by the next TreeMaker
(furthermore, the interpretation of flatMap depends on the codegen instance we're using).
The values for the subpatterns, as computed by the extractor call in extractor,
are stored in local variables that re-use the symbols in subPatBinders.
This makes extractor patterns more debuggable (SI-5739).
Tree maker that captures sub pattern values during pattern match.
Tree maker that captures sub pattern values during pattern match.
An optimized version of ExtractorTreeMaker for Products.
An optimized version of ExtractorTreeMaker for Products. For now, this is hard-coded to case classes, and we simply extract the case class fields.
The values for the subpatterns, as specified by the case class fields at the time of extraction,
are stored in local variables that re-use the symbols in subPatBinders.
This makes extractor patterns more debuggable (SI-5739) as well as
avoiding mutation after the pattern has been matched (SI-5158, SI-6070)
TODO: make this user-definable as follows
When a companion object defines a method def unapply_1(x: T): U_1, but no def unapply or def unapplySeq,
the extractor is considered to match any non-null value of type T
the pattern is expected to have as many sub-patterns as there are def unapply_I(x: T): U_I methods,
and the type of the I'th sub-pattern is U_I.
The same exception for Seq patterns applies: if the last extractor is of type Seq[U_N],
the pattern must have at least N arguments (exactly N if the last argument is annotated with : _*).
The arguments starting at N (and beyond) are taken from the sequence returned by apply_N,
and it is checked that the sequence has enough elements to provide values for all expected sub-patterns.
For a case class C, the implementation is assumed to be def unapply_I(x: C) = x._I,
and the extractor call is inlined under that assumption.
In scalac for such block x match { case d => <body> }
In scalac for such block x match { case d => <body> }
d inside <body> was to be substitued by x.
In dotty, SubstOnlyTreeMakers instead generate normal ValDef, and does not create a new substitution.
This was done for several reasons: 1) it is a lot easyer to Y-check, as d type could be used in <body>. 2) it would simplify debugging of the generated code as this works also for nested patterns, and previously they used unreadable names 3) It showed better(~30%), performance, Rebuilding tree and propagating types was taking substantial time.
implements the run-time aspects of (§8.2) (typedPattern has already done the necessary type transformations)
implements the run-time aspects of (§8.2) (typedPattern has already done the necessary type transformations)
Type patterns consist of types, type variables, and wildcards. A type pattern T is of one of the following forms:
A conservative approximation of which patterns do not discern anything.
A conservative approximation of which patterns do not discern anything. They are discarded during the translation.
The translation of pat if guard => body has two aspects:
1) the substitution due to the variables bound by patterns
2) the combination of the extractor calls using flatMap.
The translation of pat if guard => body has two aspects:
1) the substitution due to the variables bound by patterns
2) the combination of the extractor calls using flatMap.
2) is easy -- it looks like: translatePattern_1.flatMap(translatePattern_2....flatMap(translatePattern_N.flatMap(translateGuard.flatMap((x_i) => success(Xbody(x_i)))))...)
this must be right-leaning tree, as can be seen intuitively by considering the scope of bound variables:
variables bound by pat_1 must be visible from the function inside the left-most flatMap right up to Xbody all the way on the right
1) is tricky because translatePattern_i determines the shape of translatePattern_i + 1:
zoom in on translatePattern_1.flatMap(translatePattern_2) for example -- it actually looks more like:
translatePattern_1(x_scrut).flatMap((x_1) => {y_i -> x_1._i}translatePattern_2)
x_1 references the result (inside the monad) of the extractor corresponding to pat_1,
this result holds the values for the constructor arguments, which translatePattern_1 has extracted
from the object pointed to by x_scrut. The y_i are the symbols bound by pat_1 (in order)
in the scope of the remainder of the pattern, and they must thus be replaced by:
x_1in the treemakers,
Thus, the result type of translatePattern_i's extractor must conform to M[(T_1,..., T_n)].
Operationally, phase 1) is a foldLeft, since we must consider the depth-first-flattening of the transformed patterns from left to right. For every pattern ast node, it produces a transformed ast and a function that will take care of binding and substitution of the next ast (to the right).
Implement a pattern match by turning its cases (including the implicit failure case)
into the corresponding (monadic) extractors, and combining them with the orElse combinator.
Implement a pattern match by turning its cases (including the implicit failure case)
into the corresponding (monadic) extractors, and combining them with the orElse combinator.
For scrutinee match { case1 ... caseN }, the resulting tree has the shape
runOrElse(scrutinee)(x => translateCase1(x).orElse(translateCase2(x)).....orElse(zero))
NOTE: the resulting tree is not type checked, nor are nested pattern matches transformed thus, you must typecheck the result (and that will in turn translate nested matches) this could probably be optimized... (but note that the matchStrategy must be solved for each nested patternmatch)