Mechanism to test DSLDs

Currently, there is no easy way to create automated tests for DSLD scripts. I've been playing around with some ideas and here is what I have implemented so far:

• A way to invoke the inferencing engine for an entire project
• All unknown references are marked
• Also, there is special syntax for denoting a type check. If the type check fails, then this location is also marked.
• There is a way to invoke the inferencing engine from the command line (through an Eclipse Application extension point).
• All marked locations are sent to sysout.

The special syntax for a type check is something like this:

assert true || someExpr == "java.util.List<java.lang.Integer>"

someExpr is any expression whose type should be checked. The RHS of the == is a string representation of the expected type. The true is required so that if this assertion statement is executed at runtime, it will never fail. Since the static checker looks at the AST, the format above is strict. Assertion statements that do conform to the syntax above will not be checked.

This can be executed from the command line like so (where myProject is the name of a project already in the workspace):

eclipse -application org.codehaus.groovy.eclipse.dsl.staticCheck myProject

What I have now works, but is a little crude. Here are the current problems:

1. Too many false positives. There needs to be a way to mark certain expressions as ignored even though they may have unknown types.
2. It would be nice to be able to specify extra dsld files on the command line to apply to the project.
3. It would be nice if the project was not necessarily already installed in the workspace (eg- instead of a project name, a full path could be given). The project would be imported, checked and then removed from the workspace on shutdown.
4. It would be even better if the files checked didn't have to be in a project (as long as they were in a source folder or something).
5. Lastly, it would be good to move away from the awkward assertion statement syntax and move towards using comments to direct the type checking.