Skip to content
This repository has been archived by the owner on Jun 4, 2019. It is now read-only.

Use of AADL types for equations and constants in AGREE annex #12

Closed
mwwhalen opened this issue Mar 7, 2014 · 2 comments
Closed

Use of AADL types for equations and constants in AGREE annex #12

mwwhalen opened this issue Mar 7, 2014 · 2 comments
Assignees

Comments

@mwwhalen
Copy link
Contributor

mwwhalen commented Mar 7, 2014

AGREE can use AADL types from outside the AGREE annex clause, but you can't write them as types within the AGREE subclause for equations and constants.

system Mode_Control
features
start: in data port Base_Types::Boolean;
clear: in data port Base_Types::Boolean;
cooking_mode: out data port Base_Types::Integer;

annex agree {** 
           -- syntax error here.
    eq is_cooking : Base_Types::Boolean = defs.is_cooking(cooking_mode); 
@kfhoech kfhoech added the AGREE label Feb 21, 2018
@kfhoech kfhoech added the bug label Mar 30, 2018
@kfhoech
Copy link
Contributor

kfhoech commented Mar 30, 2018

If we concur that the mapping from AADL types to AGREE types is sufficiently well understood, then this makes sense. We already do the mapping implicitly for elements of aggregates; there are already plenty of implicit mappings occurring already.

The core of this issue is not that AADL Base Types are not allowed. The validator would allow them, but for some reason items in Base_Types are not resolved by the linker. Accordingly, the validator does not know what they are and posts a validation error.

Why resolving these types fails in unknown. It isn't because they're data types or because they're in a different package. Creating a data type that extends the base type and placing it in the same or another package works correctly.

This problem appears to be deep in the innards of how Xtext scoping and linking works, and interacts with OSATE and the AGREE annexes as delegated from OSATE.

@kfhoech
Copy link
Contributor

kfhoech commented Apr 6, 2018

Resolved by Pull Request.

@kfhoech kfhoech closed this as completed Apr 6, 2018
@kfhoech kfhoech added the v2.3.3 label Jul 11, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants