Error in one model makes all other models fail

[karinh@…]

Create the model:

model DoubleDeclarationComps
  Real x = 1.0;
  Real x = 2.0;
end DoubleDeclarationComps;

Try to validate that model.->Fails, as expected.
Try to validate any other correct model ->Also fails. With the same error message as the first model. This is a bug since correct models should not fail.

This is a blocker for the compliance test suite, and is confusing for the users.

[Adrian Pop]

The problem with this is that the check is right after the parsing

public function parse "Parse a mo-file"
  input String filename;
  input String encoding;
  output Absyn.Program outProgram;
algorithm
  outProgram := parsebuiltin(filename,encoding);
  /* Check that the program is not totally off the charts */
  _ := SCodeUtil.translateAbsyn2SCode(outProgram);
end parse;

and it means that parsing will fail.

We somehow need conditional errors i.e. only fail and display the error if the class is used, not when is parsed.

[Martin Sjölund]

Adrian, note that this model parses correctly:

$ cat c.mos && omc c.mos
loadFile("c.mo");getErrorString();
list();getErrorString();
instantiateModel(M);getErrorString();
true
""
"model DoubleDeclarationComps
  Real x = 1.0;
  Real x = 2.0;
end DoubleDeclarationComps;

model M
end M;"
""
""
"[/home/martin/tmp/c.mo:3:3-3:15:writable] Error: An element with name x is already declared in this scope.
Error: Error occurred while flattening model M
"

[Adrian Pop]

True. The issue is not in parsing then and SCodeUtil.translateAbsyn2SCode always translates from full Absyn and will always display the error when transforming SCode->Absyn, even if the class is not used.
However, the ticket said that we fail for all other models that are not affected, which sound strange. Maybe the dependency analysis fails because it considers the entire SCode program.

[Per Östlund]

Replying to adrpo:

Maybe the dependency analysis fails because it considers the entire SCode program.

Yes, the dependency analysis doesn't work if the loaded classes have structural errors in them, since it's not possible to e.g. have two elements with the same name in the environment. I will see if it's possible to just ignore such errors, since it shouldn't really matter if the dependency analysis fails to analyse erroneous models.

[Per Östlund]

Fixed in r22798, at least so that models in the compliance test suit can be compiled without errors from other models.