-
-
Notifications
You must be signed in to change notification settings - Fork 368
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
Improve UnparsedLiteral Handling #6360
Conversation
Significantly improves the conversion of UnparsedLiterals and return type resolution
I've updated this PR to now include some Arithmetic-specific changes to hopefully improve some of the incorrect parsing/false errors that have been reported. Specifically, Arithmetic attempts to convert UnparsedLiterals to more specific types (from what information it can gather). Return type resolution has also been improved to avoid Object if possible |
src/main/java/ch/njol/skript/expressions/arithmetic/ExprArithmetic.java
Outdated
Show resolved
Hide resolved
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.
src/main/java/ch/njol/skript/expressions/arithmetic/ExprArithmetic.java
Outdated
Show resolved
Hide resolved
Co-authored-by: sovdee <[email protected]>
Description
This is an experimental fix for some issues with UnparsedLiterals that have gotten more exposure due to the changes in Arithmetic parsing. One now problematic expression is the following:
index of event-slot - 9
This would typically be interpreted (and expected to be interpreted as)
(index of event-slot) - (9)
. Skript is correctly identifying this as ExprArithmetic, but the left and right expressions are wrong. Skript will move from left to right trying to determine what group of characters makes up the expression. When Skript gets to the following, things go wrong:(index of event)-(slot - 9)
Skript gets to this point and TypePatternElement does not continue asindex of event
andslot - 9
are both valid UnparsedLiterals. ExprArithmetic then fails due to encountering UnparsedLiterals it cannot convert.This PR addresses this issue by having TypePatternElement continue matching in the event it gets a MatchResult containing UnparsedLiterals that cannot be converted by regular means (classinfo parsing). It saves a backup of the first valid MatchResult and falls back to that if further searching yields nothing valid.
This solution may need tweaking if further issues arise.
Target Minecraft Versions: any
Requirements: none
Related Issues: