Related articles |
---|
ensuring full semantic checker coverage? rossb@audiomulch.com (Ross Bencina) (2003-03-22) |
Re: ensuring full semantic checker coverage? chase@theworld.com (David Chase) (2003-03-23) |
Re: ensuring full semantic checker coverage? qjackson@shaw.ca (Quinn Tyler Jackson) (2003-03-24) |
Re: ensuring full semantic checker coverage? rossb@audiomulch.com (Ross Bencina) (2003-03-30) |
From: | David Chase <chase@theworld.com> |
Newsgroups: | comp.compilers |
Date: | 23 Mar 2003 22:27:44 -0500 |
Organization: | Little or none |
References: | 03-03-138 |
Keywords: | testing |
Posted-Date: | 23 Mar 2003 22:27:43 EST |
Ross Bencina wrote:
>To some degree the checks will be dispersed in the source
>code, as I may need/want to implement the checks in multiple passes.
I might use an attribute grammar to get rid of the
thinking-about-multiple-passes problem, but that's not necessarily an
answer to your question.
>My current plan is to build a database (some sort of tagged textfile)
>with separate items for each assertion that the checker must test,
>give each of these assertions an ID, then embed these IDs in comments
>with the source code that implements each check. That way I can write
>a script that crossreferences every required check to the code that
>performs it. Perhaps the error message text for each check might also
>form part of this approach.
I would go beyond comments, and put the tags into executable code, so
that you might (with the setting of a switch) record which checks were
applied and how they were resolved, perhaps including which line they
were applied at. This is a little bit of infrastructure in the
beginning, but it lets you write a set of tests that are supposed to
exercise checks, verify that the tests exercise what they claim to
test, and verify that they continue to do so after a code change.
Depending upon your audience, it might or might not hurt to
cross-reference error messages to the relevant line in the standards
documentation.
>Another approach I can think of is to somehow organise the code so
>that it follows the order of the sections in the specification, and
>annotate each check in the code with the relevent specification
>section numbers.
I'm less enthusiastic about this, mostly because you say "somehow"
(which means you're not sure, and I'm not sure myself) and because I
can see that actually tracing the rules that you execute will give you
something more valuable.
David Chase
Return to the
comp.compilers page.
Search the
comp.compilers archives again.