As Modelica programmer, I can use an LSP client to check a class in a Modelica-Project for errors, so I can identify bugs quickly and without switching tools #19
[ ] Error reports should contain the file in which the error occurred, the line number, an indication at which stage the error occurred (compile, instantiate, check), and a human-readable error message, so bugs can be located precisely.
[ ] By default, Mo|E checks as many errors as possible, so that the user does not need multiple commands to find errors but also does not see meaningless errors. It may be wise to add a flag to switch between this mode of operation and a "minimal check" policy, that only performs the compilation step, in order to maintain performance requirements.
[x] Compile errors that occur during loadModel() are reported for all models. If compile errors occur in different models in the package than the one that was requested to compile, they are still reported. Here also a flag would be nice to request that only errors within the current model are reported, so that clients can choose whether they want to present full information to the user or rather remove clutter an focus only on the model that is currently being worked at.
[ ] Instantiation errors that occur during instantiateModel() are only reported for models that can be instantiated. For example, partial models and packages cannot be instantiated.
[ ] For model checking errors during checkModel(), the same restrictions hold as for instantiateModel(). Currently I cannot characterize which, if any, errors are only picked up by checkModel() but not by instantiateModel().
[ ] Errors that are masked by the OMC are still reported correctly. For example: loadModel(A.B.C) will only try to load A and not fail if A exists but A.B.C does not. In such cases, Mo|E needs to generate its own error messages.
[ ] Mo|E has to distinguish between checking a Modelica file for errors, which is equivalent to checking the toplevel class defined in that file, and checking a certain class within a file. Sometimes, users will just want to see whether there are any errors within the file they are working on, but if this file is a package with multiple classes, the user may actually want to only check the single class they are currently working on. This is especially relevant with regard to the "level" of error checking. While packages can only be checked for compile errors, the currently "active" class at the cursor position might allow more detailed checks. At the very least, users should be able to manually trigger deep checks for classes within a multi-class file.
loadModel()are reported for all models. If compile errors occur in different models in the package than the one that was requested to compile, they are still reported. Here also a flag would be nice to request that only errors within the current model are reported, so that clients can choose whether they want to present full information to the user or rather remove clutter an focus only on the model that is currently being worked at.instantiateModel()are only reported for models that can be instantiated. For example,partialmodels and packages cannot be instantiated.checkModel(), the same restrictions hold as forinstantiateModel(). Currently I cannot characterize which, if any, errors are only picked up bycheckModel()but not byinstantiateModel().loadModel(A.B.C)will only try to loadAand not fail ifAexists butA.B.Cdoes not. In such cases, Mo|E needs to generate its own error messages.