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

Bidirectional access connections are not instantiated correctly #1977

Closed
AaronGreenhouse opened this issue Aug 30, 2019 · 3 comments
Closed

Bidirectional access connections are not instantiated correctly #1977

AaronGreenhouse opened this issue Aug 30, 2019 · 3 comments
Assignees
Milestone

Comments

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Aug 30, 2019

Bidirectional access connections are not always instantiated in both directions.

Consider

package test_access_connections
public
    abstract aType
        features
            da: requires data access;
    end aType;

    system s
    end s;

    system implementation s.i
        subcomponents
            d1: data;
            a1: abstract aType;
            
            d2: data;
            a2: abstract aType;
            
            d3: data;
            a3: abstract aType;
            
            d4: data;
            a4: abstract aType;
            
            d5: data;
            a5: abstract aType;
        connections
            -- We connect both ways -- Should not be merged anymore
            conn1a: data access d1 -> a1.da;
            conn1b: data access a1.da -> d1;

            -- Bidirectional, should have 2 connection instances
            conn2: data access d2 <-> a2.da;
            
            -- Bidirectional, should have 2 connection instances
            conn3: data access a3.da <-> d3;
            
            conn4: data access d4 -> a4.da;
            
            conn5: data access a5.da -> d5;            
    end s.i;
end test_access_connections;

There should be two connection instances generated from conn2, and two generated from conn3. For conn2 we only get a connection instance for "d2 -> a2.da". Strangely, conn3 gives both connection instances.

The equivalent example using ports instead of data access creates the expected connections in all cases:

package test_regular_connections
public
    abstract aType
        features
            f1: in out event port;
    end aType;
        
    system s        
    end s;

    system implementation s.i
        subcomponents
            s1a: abstract aType;
            s1b: abstract aType;
            
            s2a: abstract aType;
            s2b: abstract aType;
            
            s3a: abstract aType;
            s3b: abstract aType;
            
            s4a: abstract aType;
            s4b: abstract aType;
            
            s5a: abstract aType;
            s5b: abstract aType;
        connections
            -- connect both ways. should not be merged, should have 2 connection instances
            conn1a: feature s1a.f1 -> s1b.f1;
            conn1b: feature s1b.f1 -> s1a.f1;
            
            -- bidirectional, should have two connection instances
            conn2: feature s2a.f1 <-> s2b.f1;
            
            -- bidirectional, should have two connection instances
            conn3: feature s3b.f1 <-> s3a.f1;
            
            conn4: feature s4a.f1 -> s4b.f1;
            
            conn5: feature s5b.f1 -> s5a.f1;
    end s.i;
end test_regular_connections;
@lwrage
Copy link
Contributor

@lwrage lwrage commented Aug 30, 2019

Bug is in CreateConnectionsSwitch.filterOutgoingConnections. It doesn't find features on the destination end of a bidirectional connection.

@lwrage
Copy link
Contributor

@lwrage lwrage commented Aug 30, 2019

The bug was introduced in the fix for #1830

@lwrage lwrage self-assigned this Aug 30, 2019
lwrage added a commit that referenced this issue Sep 6, 2019
lwrage added a commit that referenced this issue Sep 6, 2019
lwrage added a commit that referenced this issue Sep 10, 2019
lwrage added a commit that referenced this issue Sep 10, 2019
@lwrage
Copy link
Contributor

@lwrage lwrage commented Sep 10, 2019

Fixed

@lwrage lwrage closed this Sep 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants