-
-
Notifications
You must be signed in to change notification settings - Fork 403
Limit literal specification regex pattern to improve matching behavior. #8068
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
base: dev/patch
Are you sure you want to change the base?
Conversation
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.
Looks good
if (allowUnparsedLiteral && containsObjectClass) | ||
//noinspection unchecked | ||
return (Expression<? extends T>) getUnparsedLiteral(log, error); |
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.
Hmm, does this need to be after the string literal check? My concern is that something like "%object/string%" wouldn't work right (it would always return an unparsed literal).
Maybe the string check needs to go in loop above instead?
Problem
Literal specification didn't work so well in function parameters:
func(red, black (color))
would fail to parse.Solution
Enforces stricter regex match rules (no {}()"' and so on in the literal, and only letters, numbers, and spaces in the codename).
Also ensures the two parseSingleExpr implementations are unified in behavior, as previously only one would attempt specified literals. Pulled duplicate code into a helper method.
Testing Completed
added to literal specification.sk
Supporting Information
Completes: none
Related: none