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 expression conversion #7165

Merged
merged 12 commits into from
Dec 30, 2024
Merged

Fix expression conversion #7165

merged 12 commits into from
Dec 30, 2024

Conversation

UnderscoreTud
Copy link
Member

Description

This PR fixes an issue where the parser wouldn't attempt to convert an expression if Expression#canReturn(Class) returns true. Causing issues when an expression could return a certain type but doesn't once evaluated. For instance, adding two unset variables, which can potentially return variety of types (such as a string), and using the expression in a pattern that expects strings (e.g., formatted ({_foo} + {_bar}) would result in a stack trace being thrown because the array returned from the arithmetic expression wasn't converted to a string array.


Target Minecraft Versions: any
Requirements: none
Related Issues: #7164

@UnderscoreTud UnderscoreTud added the bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. label Oct 27, 2024
Copy link
Member

@APickledWalrus APickledWalrus left a comment

Choose a reason for hiding this comment

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

Will review in depth soon. tud and I discussed some potential issues/edge cases that still need fixed

UnderscoreTud and others added 7 commits November 8, 2024 16:47
We need to use conversion whenever there are multiple return types. If the expression does not accept our supertype, then we can attempt to convert it, which will already handle safety checks for multiple return types
This fixes SimpleExpression not converting  possible return types that are not contained in the desired types array. For example, if an expression can return a Number or a String, and we want an Expression that is a Number or an World, it will now include converters for String->Number and String->World
@Moderocky Moderocky added the don't merge me !! For pull requests that should not be merged due to some outstanding dispute, conflict or dependency. label Dec 26, 2024
@APickledWalrus
Copy link
Member

I've gone ahead and moved the logic out of SimpleExpression and into ConvertedExpression. This is to preserve the behavior of expressions overriding the method AND that the logic/handling for this is consistent across Skript. The canReturn logic has been moved out of SkriptParser, as its usage there is an incorrect assertion (an object that might be Expression<A> or Expression<B> is NOT the same as Expression<A>, so we cannot return it as one). It has to be handled by ConvertedExpression so that we can ensure arrays are typed correctly (the root problem).

@APickledWalrus APickledWalrus removed the don't merge me !! For pull requests that should not be merged due to some outstanding dispute, conflict or dependency. label Dec 30, 2024
@APickledWalrus APickledWalrus dismissed their stale review December 30, 2024 01:17

i am now a contributor

@Moderocky Moderocky merged commit cca446d into dev/patch Dec 30, 2024
7 checks passed
@Moderocky Moderocky deleted the patch/expression-conversion branch December 30, 2024 06:24
Moderocky added a commit that referenced this pull request Dec 30, 2024
* Fix the REMOVE changer of variables (#7163)

* Fix the REMOVE changer of variables

* Fix wording

* Fix tests

* Update Variable.java

---------

Co-authored-by: sovdee <[email protected]>

* Fix Improperly Typed Array in ExprXOf (#7268)

* Add boat data check to prevent error. (#7301)

* Fix BlockIgniteEvent  (#7252)

Update BukkitEventValues.java

Co-authored-by: Moderocky <[email protected]>

* Fix expression conversion (#7165)

* Fix expression conversion

* Extract duplicate code into a separate helper method

* improve conversion strategy

* Add .sk to test file

* Simplify conversion usage

We need to use conversion whenever there are multiple return types. If the expression does not accept our supertype, then we can attempt to convert it, which will already handle safety checks for multiple return types

* SimpleExpression: fix possible return type conversion

This fixes SimpleExpression not converting  possible return types that are not contained in the desired types array. For example, if an expression can return a Number or a String, and we want an Expression that is a Number or an World, it will now include converters for String->Number and String->World

* Use safety checks of ConvertedExpression

* Remove incorrect converter remake

* Move logic from SimpleExpression to ConvertedExpression

---------

Co-authored-by: APickledWalrus <[email protected]>
Co-authored-by: Efnilite <[email protected]>
Co-authored-by: Moderocky <[email protected]>

---------

Co-authored-by: _tud <[email protected]>
Co-authored-by: sovdee <[email protected]>
Co-authored-by: Patrick Miller <[email protected]>
Co-authored-by: kyoshuske <[email protected]>
Co-authored-by: Efnilite <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An issue that needs to be fixed. Alternatively, a PR fixing an issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants