osate / osate2

Open Source AADL2 Tool Environment
http://osate.org
Eclipse Public License 2.0
39 stars 8 forks source link

Behavior annex errors are not propagated to the user #891

Closed smithdtyler closed 5 years ago

smithdtyler commented 7 years ago

Errors reported by the behavior annex legality checker are generated but not reported to the user. For example, I (incorrectly) used a state transition with a timeout dispatch condition on a process behavior specification.

  process implementation processA.impl
    subcomponents
      tA: thread threadA;
    annex behavior_specification {**
    states
    s0: initial complete final state;
    s1: state;
    transitions
    s0 -[ on dispatch timeout ]-> s1;
    **};
  end processA.impl;

The OSATE workspace (I'm using the 2.2.3 testing build, but I've seen similar behavior on older versions) simply disables syntax highlighting for the annex code, reporting no useful information to the user.

screen shot 2017-08-27 at 2 18 33 pm

Debugging from source indicates that the AadlBaLegalityrulesChecker determined my usage of the timeout keyword was incorrect. However, this error message does not appear in a problem marker or other user facing interface:

From AadlBaLegalityRulesChecker~560

        // Error case : it must only be declared for timed thread.
        this.reportLegalityError(tc, "The dispatch relative timeout and" +
              " catch statement must only be declared for timed thread: " +
              "Behavior Annex D.4.(L1) legality rule failed") ;
      }
smithdtyler commented 7 years ago

Digging into this further, it appears that the behavior annex parser creates the appropriate error markers, but the markers are sometimes deleted by OSATE. Placing a breakpoint at org.osate.aadl2.modelsupport.errorreporting.MarkerParseErrorReporter:deleteMessagesImpl indicates that when an AADL file is saved, markers are created and deleted multiple times, often asynchronously.

lwrage commented 7 years ago

All this is a weird interaction between error reporting and AADL file expansion in the AADL navigator. It also leads to plenty of exceptions in the log file about missing markers, see #613.

Etienne13 commented 5 years ago

I reopen this issue since I could reproduce it in OSATE 2.5.0: with the example provided by Tyler, I see that OSATE error repporter is called from AadlBaLegalityRulesChecker~560. However the error is neither visible in the editor, nor in the problems view.

Etienne13 commented 5 years ago

@lwrage : do you have any idea how to solve this? After parsing of an erroneous BA subclause I can see that the error reporter has been filled in with error messages. But these errors are not reported to the user (neither in the editor view, nor in the Problem view).

Etienne13 commented 5 years ago

After investigating a bit more, I discovered this issue can be fixed by replacing the QueuingParseErrorReporter by a MarkerParseErrorReporter. I can provide the corresponding modificaiton in the AnnexParserAgent class but it seems strange that the QueuingParseErrorReporter does not work (it used to).

lwrage commented 5 years ago

Using a marker error reporter is likely a bad idea: Markers are an IDE concept and assume that a workspace exists. In standalone operation (without OSGI) and in tests this assumption is violated, so markers won't work. Do you know an OSATE version in which the queuing error reporter still works?

Etienne13 commented 5 years ago

I agree about the problem of markers. I think I did not have this problem because all I do (including tests) relies on OSGI. Unfortunately, I don't know in which version of OSATE the queueing error reporter still works: my regression tests use another reporting mechanism (a wrapper to print errors on the standard output). Sorry about that.

lwrage commented 5 years ago

The original issue 891 was, in fact, fixed.

The error markers don't show up now because about a year ago we switched to the queuing error reporter to support standalone operation. However, we forgot to convert the queued errors to markers when running with UI. Tracking now as #1884.