Make tuples be subtypes of empty interfaces (like Any).

[jemc]

After this commit, a tuple is considered a subtype of Any ${cap}
if all of the elements of the tuple are subcaps of the cap.

This is a principle of least surprise issue, as it is surprising
that a type param constraint of Any #any does not behave the same
as an unconstrained type param, with the latter accepting tuple
type args, and the latter not doing so.

Previously, there was no way to allow tuples of any cardinality
as a type argument, while restricting what caps were allowed to
be in those tuples (such as for the concerns of aliasing or
sendability). For example, class List[A] in the collections
package allowed tuples as type args, but class List[A: Any #share]
in the collections/persistent package did not. Now they both
allow tuple type args, and the Any #share constrains the type arg
so that all tuple elements must be shareable (val or tag).

Resolves #1767.

[jemc]

I've marked this as DO NOT MERGE because I still need to verify that the runtime will do the correct thing in boxing the tuple when it is assigned to an Any reference.

[Praetonus]

The crash in the tests is caused by the reachability map not being aware of the new subtyping relationship between tuples and empty interfaces. The code generator then believes that generating the __is function for some tuple isn't needed because it doesn't see the supertype needing it.

The add_types_to_trait and add_traits_to_type functions in reach.c should be updated to account for tuple/interface subtyping. We should be careful to not add any method to a tuple when doing that (i.e. add_methods_to_type should either not be called on a tuple or not have any method to add). Since tuples are subtypes of empty interfaces only, we should be fine either way.

[plietar]

This currently crashes when the tuple contains non-single types (eg union, intersection or tuple)

class C
class D
primitive P
  fun apply(x: (C val | D val, C ref)) =>
    let x': Any box = consume x

I think we can make (T1, T2) a subtype of Any cap by checking if both T1 and T2 are subtypes of Any cap, and it would take care of recursively checking through the types to check the capability

[plietar]

Instead of is_sub_cap_and_eph, I would make this is_x_sub_x(child, super, ...)

[jemc]

Good idea - makes sense.

[jemc]

I've made the fix that @plietar pointed out, but @Praetonus, I'm a little confused on your point, so I was hoping you could give some more guidance.

I looked at the source and call sites of the add_types_to_trait, add_traits_to_type, and it seems like they're already being called for tuple appropriately for tuples, and relying on is_subtype to determine if they should take action, so now that is_subtype is changed to support the subtype relationship, I'd expect it to work. Maybe I'm missing some more subtle point here, though.

[Praetonus]

@jemc You're right, that's not the problem.

I think that what's missing is a call to add_methods_to_type in the TK_TUPLETYPE case of add_types_to_trait.

[plietar]

The problem here I think is that an Any reference can now be a tuple, and thus in an identity comparison we need to generate a call to __is to compare contents.

However, since #1934, this method is generated only if it is reachable, and it will never be considered reachable for Any, hence the failed assertion.

Note that #1934 also had a bug which leads to a similar crash. In the following example, when marking the __is method on the top-level tuple type ((U8, U16) | None, U8) it
does not mark it on the inner type (U8, U16). When generating the former it will then fail to find the latter.

let x : (((U8, U16) | None, U8) | None) = None
let y : (((U8, U16) | None, U8) | None) = None
x is y

Unfortunately if we make tuples subtypes of Any, and we want identity of tuple to compare contents, then I think we need to generate a __is method for all tuple types, and allocate a vtable index for Any (and all thus for all types). The tests pass on this PR with #1934 reverted.

[Praetonus]

I think you're right @plietar, the identity reachability isn't recursive when it should indeed be. I'll make a fix.

[jemc]

@Praetonus - what about this part of @plietar's comment?

Unfortunately if we make tuples subtypes of Any, and we want identity of tuple to compare contents, then I think we need to generate a __is method for all tuple types, and allocate a vtable index for Any (and all thus for all types).

My takeaway from that comment is that if we make the change that this PR was opened to make, then we can't also have the optimization from #1934. So, if that's the case, we should likely just revert #1934, or come up with another solution for the tuple problem, instead of implementing tuple-sub-Any.

[Praetonus]

I think we can have both tuple-sub-Any and the reachability optimisation. It won't be as efficient as before since Any now has more subtypes, but people who want performance shouldn't be using Any anyway.

[Praetonus]

The bug should be fixed in #1947.

[SeanTAllen]

@Praetonus what's the performance impact on Any usage? We have to use Any in our code do to some various other bits of fun in the type system that is more involved than this comment. What do you imagine the performance impact of this will be?

[Praetonus]

There would only be an impact on is and digestof with Any operands, with an additional check to see whether the operand is a tuple. Based on the code, this should be a load, a bitwise operation and a conditional branching.

[jemc]

Once the other identity fixes get merged, I will bump the commit here so CI runs again, and merge this if it passes.

[Praetonus]

#1947 has been merged.

[jemc]

I've rebased this PR for running on latest master. We'll see how CI goes this time.

[jemc]

CI is good - I'm merging it.