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

Keep EnsoMultiValue as self when dispatching Any instance methods #12170

Merged
merged 13 commits into from
Jan 29, 2025

Conversation

JaroslavTulach
Copy link
Member

@JaroslavTulach JaroslavTulach commented Jan 28, 2025

Pull Request Description

Fixes #12143.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • All code follows the
    Scala,
    Java,
  • Unit tests have been written where possible.

Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

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

Great to see that fixed.

I'd appreciate also enabling relevant tests in Multi_Value_As_Type_Refinement_Spec.

When writing the tests in Multi_Value_As_Type_Refinement_Spec, I kind of assumed that the fix for that would also fix the issue with attaching Warnings to multi value. Does/can that fix address that also, or do we need to create a separate issue for the Warning.attach test?

@JaroslavTulach
Copy link
Member Author

When writing the tests in Multi_Value_As_Type_Refinement_Spec, I kind of assumed that the fix for that would also fix the issue with attaching Warnings to multi value. Does/can that fix address that also, or do we need to create a separate issue for the Warning.attach test?

When I enable one of the "warnings tests" I get assertion:

Execution finished with an error: java.lang.AssertionError: Dispatch (MultiType{types=[A, A]} and extra MultiType{types=[]} should be disjoin!
        at <java> org.enso.runtime/org.enso.interpreter.runtime.data.EnsoMultiValue$NewNode.newValue(EnsoMultiValue.java:98)
        at <java> org.enso.runtime/org.enso.interpreter.node.typecheck.AllOfTypesCheckNode.executeCheckOrConversion(AllOfTypesCheckNode.java:99)
        at <java> org.enso.runtime/org.enso.interpreter.node.typecheck.TypeCheckValueNode.handleCheckOrConversion(TypeCheckValueNode.java:56)
        at <java> org.enso.runtime/org.enso.interpreter.node.typecheck.TypeCheckExpressionNode.executeGeneric(TypeCheckExpressionNode.java:23)

I tried to fix it with following change:

diff --git engine/runtime/src/main/java/org/enso/interpreter/node/typecheck/AllOfTypesCheckNode.java engine/runtime/src/main/java/org/enso/interpreter/node/typecheck/AllOfTypesCheckNode.java
index 759637c1dc..18f9664be4 100644
--- engine/runtime/src/main/java/org/enso/interpreter/node/typecheck/AllOfTypesCheckNode.java
+++ engine/runtime/src/main/java/org/enso/interpreter/node/typecheck/AllOfTypesCheckNode.java
@@ -2,14 +2,18 @@ package org.enso.interpreter.node.typecheck;
 
 import com.oracle.truffle.api.CompilerDirectives;
 import com.oracle.truffle.api.frame.VirtualFrame;
+import com.oracle.truffle.api.interop.UnsupportedMessageException;
 import com.oracle.truffle.api.nodes.ExplodeLoop;
 import java.util.Arrays;
+import java.util.logging.Level;
+import java.util.logging.Logger;
 import java.util.stream.Collectors;
 import org.enso.interpreter.node.ExpressionNode;
 import org.enso.interpreter.runtime.EnsoContext;
 import org.enso.interpreter.runtime.data.EnsoMultiValue;
 import org.enso.interpreter.runtime.data.Type;
 import org.enso.interpreter.runtime.library.dispatch.TypeOfNode;
+import org.enso.interpreter.runtime.warning.WarningsLibrary;
 
 final class AllOfTypesCheckNode extends AbstractTypeCheckNode {
 
@@ -60,7 +64,17 @@ final class AllOfTypesCheckNode extends AbstractTypeCheckNode {
         }
       }
       valueTypes[at] = t;
-      if (result instanceof EnsoMultiValue emv) {
+
+      Object r = result;
+      if (WarningsLibrary.getUncached().hasWarnings(result)) {
+          try {
+              r = WarningsLibrary.getUncached().removeWarnings(result);
+          } catch (UnsupportedMessageException ex) {
+              Logger.getLogger(AllOfTypesCheckNode.class.getName()).log(Level.SEVERE, null, ex);
+          }
+      }
+
+      if (r instanceof EnsoMultiValue emv) {
         result =
             EnsoMultiValue.CastToNode.getUncached()
                 .findTypeOrNull(valueTypes[at], emv, false, true);
diff --git test/Base_Tests/src/Semantic/Multi_Value_As_Type_Refinement_Spec.enso test/Base_Tests/src/Semantic/Multi_Value_As_Type_Refinement_Spec.enso
index 8f97e10864..a3e356a71d 100644
--- test/Base_Tests/src/Semantic/Multi_Value_As_Type_Refinement_Spec.enso
+++ test/Base_Tests/src/Semantic/Multi_Value_As_Type_Refinement_Spec.enso
@@ -165,7 +165,7 @@ add_specs suite_builder =
             (c:A&B&C).b_method . should_equal "B method"
             (c:A&B&C).c_method . should_equal "C method"
 
-        group_builder.specify "default to_text should delegate to one of values" pending="TODO: https://github.com/enso-org/enso/issues/11827" <|
+        group_builder.specify "default to_text should delegate to one of values" <|
             ab = make_a_and_b
             ab.to_text . should_equal "(A_Ctor 1)"
 
@@ -192,7 +192,7 @@ add_specs suite_builder =
                 _ -> "structural matching of B.B_Ctor failed"
             r.should_equal "matched: (A_Ctor 1)"
 
-        dispatch_pending="TODO: https://github.com/enso-org/enso/issues/12143"
+        dispatch_pending=Nothing
         group_builder.specify "calling a method on one of the types should not lose the intersection type" pending=dispatch_pending <|
             ab = make_a_and_b

but it is going to be more complicated. Moreover it is independent on the problem this PR is solving. Please report it as another "warnings issue". Thank you.

@radeusgd
Copy link
Member

but it is going to be more complicated. Moreover it is independent on the problem this PR is solving. Please report it as another "warnings issue". Thank you.

OK, reported as #12177

@JaroslavTulach JaroslavTulach added the CI: Ready to merge This PR is eligible for automatic merge label Jan 29, 2025
@mergify mergify bot merged commit caec1e6 into develop Jan 29, 2025
50 checks passed
@mergify mergify bot deleted the wip/jtulach/MultiSelfOnAny12143 branch January 29, 2025 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Calling a method that returns 'itself' on a multi-value should not lose multi-value structure?
3 participants