-
Notifications
You must be signed in to change notification settings - Fork 11
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
evaluate static string matches in TypedExprNormalization #1262
Conversation
] | ||
): Option[Expr] = | ||
arg match { | ||
case Literal(Lit.Str(s)) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could extend this very easily to any Literal which is probably all we need to handle here.
That said, maybe this code should really be pushed into TypedExprNormalization since applying these optimizations could open other normalizations.
import org.scalacheck.Prop.forAll | ||
import org.scalacheck.Gen | ||
|
||
class StrPartTest extends munit.ScalaCheckSuite { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this test actually also tests that all the matching algorithms agree. It seems we have something like 4 of them:
- StrPart
- SeqPattern + matcher
- NamedSeqPattern + matcher
- java regex
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think StrPart is the fastest, but I haven't carefully benchmarked it, but they should all agree, and the speed only matters for the MatchlessToValue runtime, in normalization, it doesn't matter I don't think.
I noticed we are generating code for static string matches that could be done in advance.
This refactors to use the existing string matching code statically.