Assertion error in dispatch when multi value types meet warnings

[radeusgd]

I encountered situations like this that were blocking my fixing of errors during the DB_Column part of #12994.

I tried to distill this into a minimal example and what I was able to find is following:

from Standard.Base import all
import Standard.Base.Errors.Illegal_State.Illegal_State

type Base_Column
    Value underlying

type In_Memory_Column
    Value vec

type My_Warning
    Warning msg

Base_Column.from (that:In_Memory_Column) =
    Base_Column.Value that

In_Memory_Column.from (that:Base_Column) =
    if that.underlying.is_a In_Memory_Column then that.underlying else
        Error.throw (Illegal_State.Error "In_Memory_Column.from: that is not an In_Memory_Column")

refine base:Base_Column =
    (base : Base_Column & In_Memory_Column)

new_column vec:Vector -> Base_Column =
    refine (In_Memory_Column.Value vec)

main =
    col = new_column [1,2,3]
    col_warn = Warning.attach (My_Warning.Warning "My warning") col
    col_as_in_mem = col_warn:In_Memory_Column
    col_as_base = col_as_in_mem:Base_Column
    col_as_both = col_as_base:(Base_Column & In_Memory_Column)
    col_back = col_as_both:In_Memory_Column
    col_back.to_text

Expected behaviour

Printing

col_warn = Base_Column & In_Memory_Column
 ! (My_Warning.Warning 'My warning')
col_as_in_mem = Base_Column & In_Memory_Column
 ! (My_Warning.Warning 'My warning')
col_as_base = Base_Column & In_Memory_Column
 ! (My_Warning.Warning 'My warning')
(In_Memory_Column.Value [1, 2, 3])

Actual behaviour

If running with -ea, this fails with assertion error:

Execution finished with an error: java.lang.AssertionError: Dispatch (MultiType{types=[Base_Column]}) and extra (MultiType{types=[Base_Column]}) should be disjoin!
        at <java> org.enso.runtime/org.enso.interpreter.runtime.data.EnsoMultiValue$NewNode.newValue(EnsoMultiValue.java:107)
        at <java> org.enso.runtime/org.enso.interpreter.runtime.data.EnsoMultiValue$CastToNode.findTypeOrNull(EnsoMultiValue.java:618)
        at <java> org.enso.runtime/org.enso.interpreter.node.typecheck.SingleTypeCheckNode.findDirectMatch(SingleTypeCheckNode.java:121)
        at <java> org.enso.runtime/org.enso.interpreter.node.typecheck.SingleTypeCheckNode.doCheckNoConversionNeeded(SingleTypeCheckNode.java:68)
        at <java> org.enso.runtime/org.enso.interpreter.node.typecheck.SingleTypeCheckNodeGen.executeCheckOrConversion(SingleTypeCheckNodeGen.java:100)
        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)
        at <java> org.enso.runtime/org.enso.interpreter.node.scope.AssignmentNodeGen.executeGeneric(AssignmentNodeGen.java:48)
        at <java> org.enso.runtime/org.enso.interpreter.node.callable.function.BlockNode.executeGeneric(BlockNode.java:70)
        at <java> org.enso.runtime/org.enso.interpreter.node.ClosureRootNode.execute(ClosureRootNode.java:85)
        at <enso> In_Memory_Column.from(Internal)
        at <enso> test-assert.main(test-assert.enso:32:16-26)
java.lang.AssertionError: Dispatch (MultiType{types=[Base_Column]}) and extra (MultiType{types=[Base_Column]}) should be disjoin!

[radeusgd]

While debugging this, I also added an assertion:

diff --git a/engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoMultiType.java b/engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoMultiType.java
--- a/engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoMultiType.java	(date 1747348486838)
+++ b/engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoMultiType.java	(revision 81cc031ab16f6ef7ac0310dbc7c6166582983ddd)
@@ -27,6 +27,7 @@
 
   private EnsoMultiType(Type[] types) {
     assert checkNonNull(types);
+    assert isUnique(types);
     this.types = types;
   }
 
@@ -94,6 +95,11 @@
     return "MultiType{" + "types=" + Arrays.toString(types) + '}';
   }
 
+  private static boolean isUnique(Type[] types) {
+    var set = new HashSet<>(Arrays.asList(types));
+    return set.size() == types.length;
+  }
+
   @CompilerDirectives.TruffleBoundary
   final boolean hasIntersectionWith(EnsoMultiType other) {
     var my = new HashSet<>(Arrays.asList(types));

As I think apart from the check that ensures that dispatch and extra types do not intersect, each also should not contain duplicates.

If this is added, then the example above fails even earlier on assert isUnique.

[radeusgd]

Interestingly running the above example without -ea succeeds. But the violations of the assertions seem concerning. I was also running into some null exceptions along the way. I hope that maybe fixing these assertion failures may fix these. If not, I will try to investigate further and report next bugs about the null issues (if they will be still occurring).

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2025-05-15):

Progress: .

• preparing Enso presentation
• demoing Enso to public It should be finished by 2025-05-20.

[JaroslavTulach]

The problem is that here we have an array of size two with twice the same type:

That later leads to the AssertionError. Somehow WithWarnings is involved, so this may be related to

• Attaching Warnings discards the 'hidden part' of an intersection type #12177

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..9a61a2596c 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 {
 
@@ -36,6 +40,13 @@ final class AllOfTypesCheckNode extends AbstractTypeCheckNode {
   @Override
   @ExplodeLoop
   Object executeCheckOrConversion(VirtualFrame frame, Object value, ExpressionNode expr) {
+    if (WarningsLibrary.getUncached().hasWarnings(value)) {
+      try {
+        value = WarningsLibrary.getUncached().removeWarnings(value);
+      } catch (UnsupportedMessageException ex) {
+        Logger.getLogger(AllOfTypesCheckNode.class.getName()).log(Level.SEVERE, null, ex);
+      }
+    }
     var values = new Object[checks.length];
     var valueTypes = new Type[checks.length];
     var at = 0;
@@ -60,7 +71,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);

Stripping off WithWarnings similarly as proposed at #12170 (comment) seems to help.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2025-05-16):

Progress: . It should be finished by 2025-05-20.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2025-05-16):

Progress: .

- analyzing multi-type & warning issues: https://github.com/enso-org/enso/issues/13108#issuecomment-2886738783
- GeeCON and chats with Ad It should be finished by 2025-05-20.