BA and type management

[jjhugues]

In OSATE2.6.1, some AADLib models from https://github.com/openaadl/AADLib like robot_ba uses the following

data Alpha_Type extends Base_Types::Boolean end Alpha_Type;

but then, I get error messages like

type error for 'the execute condition', 'Boolean' expected, found 'Robot_BA::Alpha_Type'.

This is a regression from previous OSATE

[Etienne13]

Here are the results of my investigations.

I tried with the following AADL package:

package issue2155
public
    with Base_Types;

    data Boolean_alias extends Base_Types::Boolean
    end Boolean_alias;

    subprogram execute_condition_test
        features
            is_valid: in parameter Boolean_alias;
        annex behavior_specification {**
            states
                s0: initial final state;
            transitions
                t1: s0 -[is_valid ]-> s0;
        **};
    end execute_condition_test;
  end issue2155;

The problem appears when opening the model in my eclipse dev env where osate 2.6.1 is installed from the update site. But if I run a JUnit test that parses the model the issue does not appear.

With the product version of OSATE 2.6.1, the code above is parsed/resolved without errors (no issue). I have tried with OSATE 2.7.0-v20200107 and I was not able to reproduce the issue on this version either.

@jjhugues have you tried with the product version? If not, can you try and see if we should keep working on this issue or not?

[jjhugues]

I always use OSATE as a product, I never update a previous one. I tested with 2.6.1vfinal. I got (once) the case where the error message was absent, but appeared after a clean up

Could it be a cache issue then? If so, it is not worth investigating until 2.7 is released.

[Etienne13]

Ok, I see how to reproduce it now. Both in OSATE 2.6.1 and 2.7.0-v20200107. I will look for the root cause in the source code.

[Etienne13]

As far as I could see, the problem occurs in the following code of OSATE: getAllPropertyAssociations() returns an empty list whereas the extended type has property association. This seems to happen only when launching OSATE or after a clean of the project.

I think we should open another issue about this. Etienne.

[lwrage]

Could one of you add the steps to reproduce the problem, please?

I get the error with Etienne's example from above, but only after I close another project in the workspace. (The cause for the BA errors in this situation is that the reference to Base_Types::Boolean can no longer be resolved.) The errors go away after a clean build (Project -> Clean... -> check Clean all projects -> Clean).

Without the steps to reproduce I cannot tell if I see the same issue as you or a different one.

[Etienne13]

Here is what I do to reproduce the issue (not sure I follow the same steps as Jerome).

1. I only have one project open, it contains the example I provided.
2. clean the project --> the error seems to appear and disappear rapidly, which seems ok but the marker associated to the line becomes grey and the file remains marked as erroneous in the navigator.
3. close the file (clicking on the cross in the editor) and reopen it (double clicking on the file in the editor). --> The line appears marked with the error mentioned by Jerôme in the editor.

[lwrage]

Which version? OSATE 2.6.1, nightly build, or running from development environment? I tried running from development environment and cannot reproduce this.

[Etienne13]

I could reproduce it with OSATE 2.6.1 and osate2-2.7.0-v20200107-1612-linux.gtk.x86_64. I have not tried from the development environment.

As you can see in the file name above, I am on Linux. for the JVM, I use Java(TM) SE Runtime Environment (build 12.0.2+10).

Etienne.

[lwrage]

When you see the type error, is it the only error in the model or are there other errors, too? If yes, which ones?

[lwrage]

BTW, the recommended Java version for OSATE is Java 8. We do not test with any other version.

[lwrage]

The BA implementation assumes that all resolvable names can be resolved during the build, which is not true in an Xtext environment. Validations that require access to other files need to be executed after core AADL name resolution.

This issue should be fixed by calling annex resolution during core validation, which happens after all references are resolved.

[lwrage]

Note: The issue depends on the order in which files are loaded, which is somewhat unpredictable.