AGREE enum issue #81
AGREE enum issue #81
Comments
Duplicated in develop branch hash 2af6b96. The problem lies in the relatively new implementation of the sanity check for the existence of an annex for all identifiers. The problem is that there is some mismatch as enumerations are lifted to Lustre global types and in some circumstances enumerator expression ids are not. There are two possible work-arounds which will likely be effective:
and then use the constants rather than the enumerators. That's ugly, I know, but it gives an opportunity for a comment to fix the code once AGREE gets fixed. |
Fixed in pull request 82. |
When trying to use AGREE enum type in the AGREE contracts, I found the following things:
enum type can only be defined in an AGREE annex associated with an AADL packages, not with an AADL system.
When I placed the following enum definition in the AGREE annex for an AADL package named "Constants:
annex agree{**
enum Status_Type = {DOES_NOT_EXIST, BUILDING, COMPLETE};
**};
Then add the following AGREE contracts in an AGREE annex for an AADL system named "A_Sys" in another package:
eq status: Constants.Status_Type;
eq transition: bool = (status = Constants.COMPLETE);
Trying to run realizability analysis on the above AADL system returned the following error:
Variable 'Constants.COMPLETE' appears in an assertion, lemma or equation statement in component 'A_Sys_wrapper_Instance' but subcomponent 'Constants' does not contain an AGREE annex
The text was updated successfully, but these errors were encountered: