[dylan] Looking for some prior art ... compiler testing, extending the compiler
Bruce Mitchener <[email protected]>
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CA+esKjPzv+OpiXjwpksvCvkXfDoyw4yVsk_iLT4HHQ2O7iRo=A@mail.gmail.com> |
There are a few things that it would be nice to able to do with the
compiler.
- Test the optimizer and type inference in varying combinations.
- Record the current state of code generation so that various versions
of the compiler output can be diffed.
- Implement new optimizations.
- Implement new warnings.
- Implement static checkers.
For some of this, I've viewed the CFG and DFG as graphs that we could query
against, much like an xpath expression allows you to query an XML tree /
document.
This is similar to how tools in Java like PMD allow you to use xpath to
write static checkers:
http://pmd.sourceforge.net/pmd-5.0.1/xpathruletutorial.html
With an interface like that to our DFM, we could do things like pass some
code to the compiler and then check the DFM that was generated to ensure
that certain properties were true. Hannes would prefer that we be able to
compare the full DFM while I think that checking targeted properties is a
good compromise. I'd be happy to start out with being able to say "Given
the code "ABC", does X have type Y?" and so on.
That sort of interface could also be useful for simplifying writing
optimizations / warnings / static checkers. I think so anyway. I haven't
tried it, so I'm clearly just guessing. :)
The other thing that would be nice is being able to dump DFM in a more
readily diffable form for doing larger comparisons. If we change something
about dispatch or type inference, it'd be nice to compile a larger body of
work with 2 versions of the compiler and do a diff on the DFM to ensure
that we've had the impact that we expected. An example of this is "What
happens when we turn on the partial dispatch code?"
While we do have the DFM output from the compiler now (pass -dfm to
dylan-compiler), this is often lacking in detail, is rather terse, and
doesn't feel well suited to this.
One option might be to write DFM -> JSON (or s-expression) code. This could
be done via something like the dfmc/debug-back-end or through some other
means. (I have a serialization library that would work nicely here...) It
could be something that dumped DOOD to JSON, but that's probably overkill.
If we had a DFM -> JSON library, that might also be useful for the full
comparisons during tests that Hannes would like to do.
Anyone know of how other compilers or systems handle this? It seems like
many people must do this sort of thing ... one would hope. But in the past,
I've always verified that the compiler output generated the right results
instead of verifying that the output itself was correct. :)
- Bruce
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers