Spurious useless 'with' message

[yoogx]

Hi,

consider the following message

package test
public
    with SEI; -- Warning: with clause of public package section is not used

properties  

   SEI::Is_Partition => true;
end test;

1. OSATE reports a warning on the "with SEI;", yet the property is used in the properties part of the package
2. If you remove the "with", it reports no error, which is wrong
3. but good news, if the property does not exist, (e.g. change it to Is_Part), then it reports an error

[joeseibel]

This is actually a language bug and a problem with the standard. With statements are a part of the package section, not a part of the package. So, it is not obvious what the rule should be for package level properties. The naming rules in the standard are also incorrect and unclear. This is naming rule N6 of section 4.2:

The reference to a property other than predeclared properties must be an property name qualified with a property set name separated by a double colon (“::”). The property set name must be listed in the with declaration of the package with the reference. Predeclared properties may be, but are not required to be qualified by the property set name.

The statement in bold does not make sense because packages do not have with declarations; they are a part of the package section. This naming rule is probably trying to say something similar to naming rule N5:

_The reference to an item declared in another package must be an item name qualified with a package name separated by a double colon (“::”). The package name must be listed in the import_declaration (with) of the package with the reference, i.e., in the import_declaration of the public section, if the reference is in the public section, and in the importdeclaration of the public or private section if the reference is in the private section of the package. Only classifiers in the public package section can be referenced.

Even after taking N5 into consideration, the standard does not speak about package level properties and needed with declarations. Does the with declaration need to be in the public section or is it sufficient to be in the private section? It is also possible to interpret this as meaning that package level properties do not require with declarations because the properties are outside of any package section. This needs to be clarified in the standard.

[reteprelief]

Good point, Joe. I had not noticed that Jerome's example uses a package level property. The idea of with clauses is to have a record of cross package and cross property set dependencies through explicit declaration - same as for programming languages. The only exception is references to predeclared properties.

Here is the errata I am adding into the document. (N6) The reference to a property other than predeclared properties must be an property name qualified with a property set name separated by a double colon (“::”). The property set name must be listed in the with declaration of the package section _with the reference. _The property set name of a property reference in the properties section of package must be listed in the with declaration of the public section or in the private section if the package only contains a private section.

[yoogx]

Thanks for your analysis. It definitely makes sense for me. Not that I want to enter into a language lawyer discussion in OSATE bug report area, but: shouldn't we also consider the case where we "with" a package and use it only in an annex subclause applied at package level, e.g; annex library ?

[reteprelief]

Jerome, I do not like it when I have to record dependencies of annexes into the core model. I also do not like it that I have to wrap an annex library with a package. I should be able to have annex items separate from the core model, e.g., the way Dominique did the RDAL - he did it for both the library and the subclause. As an experiment I set up EMV2 such that you can keep both the library and the subclause in separate (*.emv2) files. Without too many changes it works like a charm. I want to see if we can update the standard for V3 for annexes to not limit them to being embedded in the core model and to add some guidance on what annex developers should do. A candidate for yet another annex, i.e., an annex about annexes :-)

[yoogx]

REAL annex libraries are also in separate file since the beginning, so I perfectly share your points. The trade-off is: use AADL mechanism to make it interoperable across tool, at the expense of polluting (to some extent) the core model; or define a notion of project to know which files to consider. We can defer it for our v3 discussions. I also have options to get rid of the annex subclauses, but one thing at a time ;-)

I think we may consider the ticket as closed with your errata. You may decide when and how to implement the errata fix and close it properly. Thanks

[joeseibel]

Here is another issue that I just thought about regarding package level properties. What if you have a package split across two files and properties in both files? For example, suppose that the file public_part.aadl contains the following:

package pkg
public
  with ps;
properties
  ps::author => "Joe";
end pkg;

Also suppose that the file private_part.aadl contains the following:

package pkg
private
  with ps;
properties
  ps::author => "Peter";
end pkg;

In this case, what is the value of ps::author on the package pkg? Do we interpret package level properties as being applied to the package (which can be split over multiple files) or are they applied to the package file?

[lwrage]

We'll implement the following in OSATE: If an AADL file contains package-level properties and a public section then use the 'with' from the public section for validation. If there is no public section then there must be a private section and we'll use its 'with' for validation. Reassigning to Ken for fixing the warning/error.

[klreamsei]

fixed in commit d7fdfae70e92d024a97fd6aadb338367ae9a5486