|ensuring full semantic checker coverage? firstname.lastname@example.org (Ross Bencina) (2003-03-22)|
|Re: ensuring full semantic checker coverage? email@example.com (David Chase) (2003-03-23)|
|Re: ensuring full semantic checker coverage? firstname.lastname@example.org (Quinn Tyler Jackson) (2003-03-24)|
|Re: ensuring full semantic checker coverage? email@example.com (Ross Bencina) (2003-03-30)|
|From:||David Chase <firstname.lastname@example.org>|
|Date:||23 Mar 2003 22:27:44 -0500|
|Organization:||Little or none|
|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
>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
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.
Return to the
Search the comp.compilers archives again.