Dyno resolve tuple 'this'

[riftEmber]

Resolve tuple this calls (with non-param index values) in Dyno.

This is implemented by wiring up Dyno's TupleType to ChapelTuple._tuple in the bundled modules. The module implementation of _tuple.size (called by this) is technically used but its param value is computed by dyno, since in production it is only set later during generic instantiation.

Depends on: #25007, #25102, #25231, #25315.

Resolves https://github.com/Cray/chapel-private/issues/6104.

[reviewer info placeholder]

Testing:

• dyno tests
• paratest
• reproducer from backing issue now resolves

[dlongnecke-cray]

That we can lookup methods just by hooking up the module _tuple ID is too cool!

[bradcray]

@riftEmber : I have a potentially naive question, with the caveat that I haven't been following this effort in any detail. When you say:

Resolve tuple this calls (with non-param index values) in Dyno.

Is this for homogeneous tuples only? I ask because when indexing a heterogeneous tuple with a non-param value, it seems like we wouldn't be able to get far since we wouldn't know what type it was. E.g.,

const tup = (1, 2.3, "four");
const idx = genRandInt(0..<tup.size);
f(tup(idx));  // can't determine argument type of f()

proc f(x: int) { … }
proc f(x: real) { … }
proc f(x: string) { … }

[riftEmber]

Is this for homogeneous tuples only?

Yes it is, I could have been more specific. For a heterogeneous tuple this with non-param would be a compiler error (https://github.com/chapel-lang/chapel/blob/4061919/modules/internal/ChapelTuple.chpl#L167-L168). I specified non-param since the param case is already handled in the compiler in dyno.