End to end flow instance is not created if subprogram access connections are involved

[reteprelief]

See the end to end flow and the remote subprogram call from t2 to t1.
Examples.txt

[lwrage]

Maybe caused by #676. E2e flow instantiation assumes there are only unidirectional connections in the instance model.

[lwrage]

Likely duplicate of #643.

[AaronGreenhouse]

Tried instantiating Example19.impl. The end to end flow is created, and seems to be correct. However, actually 2 end to end flows are created, and one of them seems spurious.

I'm investigating the second end to end flow (Speed_E_E_2) now. Not sure what it is created, or if it even has anything to do with the original problem of subprogram access connections.

[AaronGreenhouse]

The second end to end flow comes about because when looking for the connection instances that come out of flow Flow_Sub that match the connections list [ac2], we end up with two connection instances. This occurs as follows:

1. In processFlowStep(ComponentInstance, EndToEndFlowInstance, Element, FlowImplementation, FlowIterator) the method collectionConnectionInstances() is called. The connections field contains one Connection, "ac2", which is the connection that immediately follows MyT1.Flow_Sub in flow path Flow2.
2. Method collectionConnectionInstances() tests all the available connection instances using testConnection().
3. The instance model has a semantic connection "MyT1.CompAvg -> MyT2.ext_sub" corresponding the connections ac1 and ac2.
4. This connection matches in testConnection() because

• The first part of the method is designed to match any connection instance where that has connections as a sublist of the connection references. [ac2] is a sublist of [ac1, ac2].
• The directions of the flow and connection match
• The final part of the method is designed to check that the end points of the connection instance and flow match, but only if the endpoint is a feature. As the end point of "MyT1.CompAvg -> MyT2.ext_sub" is a subprogram subcomponent, these check does nothing.

So I'm a bit confused why testConnections() operates the way it does.

• Why does it check for a sublist? I would think you would want to check if the lists are identical.
• Why are only feature endpoints checked? Is this an oversight, or there a reason for this?

It still seems to me that we do not want this second end to end flow. The matching of this second connection instance doesn't make a lot of sense.

[lwrage]

The connection instantiation is messed up. The ext_sub - shared_sub connection instances shouldn't be there and there should be an additional connection instance ext_sub -> CompAvg.

If I remove the subprogram the connections and flows are instantiated as expected.

[lwrage]

We need a better test case for this issue with calls and connections via call parameters.

[AaronGreenhouse]

Created a new issue for the connections problem and made this issue depend on it (Issue #2032)

[AaronGreenhouse]

This seems to be fixed by #2032. The bad "ext_sub - shared_sub" connection is gone, and the missing "ext_sub -> CompAvg" connection is now present. There is one end to end flow instance created.

[lwrage]

Fixed together with #2032