Related articles |
---|
Semantic error recovery whatis@gni.ai.mit.edu (1993-11-02) |
Re: Semantic error recovery isckbk@leonis.nus.sg (1993-11-10) |
Re: Semantic error recovery mauney@adm.csc.ncsu.edu (1993-11-10) |
Re: Semantic error recovery wjw@eb.ele.tue.nl (1993-11-11) |
Re: Semantic error recovery sasghm@unx.sas.com (1993-11-11) |
Re: Semantic error recovery strohm@mksol.dseg.ti.com (1993-11-12) |
Re: Semantic error recovery olsen@verdix.com (1993-11-12) |
Re: Semantic error recovery enedervo@adobe.com (1993-11-12) |
Re: Semantic error recovery kanze@us-es.sel.de (James Kanze) (1993-11-15) |
Re: Semantic error recovery kanze@us-es.sel.de (James Kanze) (1993-11-15) |
Re: Semantic error recovery delano@snake.CS.Berkeley.EDU (1993-11-17) |
Re: Semantic error recovery bill@amber.csd.harris.com (1993-11-17) |
[6 later articles] |
Newsgroups: | comp.compilers |
From: | strohm@mksol.dseg.ti.com (john r strohm) |
Keywords: | parse, errors, comment |
Organization: | Texas Instruments, Inc |
References: | 93-11-023 93-11-061 |
Date: | Fri, 12 Nov 1993 16:04:26 GMT |
Steve Boswell (whatis@gni.ai.mit.edu) wrote:
: Are there compilers that recover from semantic errors without a cascade of
: meaningless error messages? How do they do it?
isckbk@leonis.nus.sg (Kiong Beng Kee) writes:
>A Model Implementation of Standard Pascal (Welsh) describes a scheme of
>using dummy values in place of undeclared identifiers ..etc so that
>such errors are merely reported once.
Kiong Beng Kee writes:
>This fixes the repeated 'undeclared identifier' error, but what about an
>undeclared function/procedure. You'll get tons fo mismatched parameter
>errors. (At least my current PASCAL frontend would really give you a few
>pages :-))
This should not be that hard to handle.
Consider the fragment
identifier (
in the context of executable code (as opposed to declarations).
In Pascal or C or most languages out there, this just about has to be a
function or procedure call. If the identifier is undeclared, start by
setting the "suppress code gen" flag and mark the error, then start
building an undeclared function/procedure table entry. Parameter list
signature is initially unknown; parameter types can be inferred from the
types of the individual parameter expressions. When the corresponding
right parenthesis is scanned, you have in your hot little hands a complete
signature for the undeclared procedure, which can be used to validate
further calls. (Pathological case: if an undeclared identifier is used as
a parameter, the corresponding parameter type remains marked "unknown"
until such time as either another call to the procedure with a declared
identifier "fills in the blank" or some other usage of the undeclared
identifier provides a clue to its type. This is of course propagation of
knowledge through a knowledge base, for the AI weenies out there. Also
note: a really clever programmer may make some really clever mistakes with
undeclared identifiers, and this leads the compiler astray about the types
of things.)
It gets a little messier if the language of interest is Ada or FORTRAN:
the parentheses are overloaded for arrays and procedure calls. One can
still build a signature, and one need not worry about the difference
between an array and a procedure call at this point, because the fact that
the procedure or array name was undeclared will have suppressed code
generation anyway.
On the gripping hand, it may be that this isn't worth worrying about
anyway; if the source code file is small, there won't be that many errors
to begin with.
[How many people find it useful for a compiler to chug through and try to
parse and diagnose an entire file in the presence of errors? I'm just as
happy with one that finds a few errors and gives up so I can go fix them.
-John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.