![]() The variable name VARNAMEĬorresponds to the name of the meta-variable that was instantiated, and can be helpful in These are instantiations of the meta-variables in the specification. Errors may contain unification variables of the form ?FILENAME-VARNAME-NUM or ?VARNAME-NUM.Now we explain some more details of what we can see here: As these traces can get very long, they are truncated to five entries. Itself originated from one of the rules of resolveVar, which was applied in one of the rules of We see that the equality originated from a query, which Below that are several lines prefixed with > that show where At the top is the constraint that failed in > units/statics!defOk(#q.unit-s_mod_2-4, VarDef("e",VarRef(QDefRef(QModInModRef(…,…),"q"))), #q.unit-s_mod_2-4)Īs this looks daunting at first, we break it down. > units/name-resolution/interface!resolveVar(#q.unit-s_mod_2-4, QDefRef(QModInModRef(ModRef("P"),"B"),"q"),?q.unit-T-5) > query filter ((Label("units/name-resolution/interface!EXT"))* Label("units/name-resolution/default-impl!var")) and in #p.unit-s_mod_4-4 |-> Language files (not the project containing the specification!), and look as follows: The configuration settings are part of the metaborg.yaml file of the project containing the Recommended to set both settings to -1, because then every message will contain the full AST. Terms involved, without choking up Eclipse or the console with large error messages. The default is set to 3, which is usually enough to understand the Message-term-depth controls the depth up to which terms in messages are formatted. Mostly helpful for debugging when writing the spec and it slows down message formatting. The default is set to 0, as showing traces is Is still shown), -1 means the full trace. A value of 0 means no trace (if no custom message is provided, the failing constraint itself Message-trace-length controls whether a trace is included in the message, and how long it willīe. Two parameters control message formatting. Statix can be configured to contain a trace as part of the error messages for failing constraints, Java exceptions that can be included in a bug report. Check the Console and Error Log for reported Or on the project in the Package Explorer. ![]() This usually results in Analysis failed errors at the top of files Solve problems of this kind when your specification still has errors! All debugging techniques after the Basic Checklist are focused on finding andĭebugging problems in the definitions in your specification. Unexpected behavior when running Statix on files of your language.If that does not help out, pleaseįollow the steps in Getting Help and Reporting Issues. When these errorsĪre unexpected and not mentioned in Some Common Problems, follow the steps inīasic Checklist and Creating Minimal Examples. Modules or predicates, type errors, or problems with illegal scope extension. These may come from syntax errors, unresolved names for There are three main categories of problems you may encounter: Still exhibits your problem, and focus on those. Try to find the smallest example program and Statix specification that Possible! All the techniques you can use for debugging are more effective when the problem isĪs small as possible. The single most useful thing you can do when debugging is to make the problem as small as
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |