Re: Compiler error messages

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

Robert A Duff <robertduff@world.std.com> wrote in article
<EnAqpo.2oJ@world.std.com>...
> I'm currently using a 500 MHz Alpha workstation with 128 MB of RAM.  I
> didn't say *minimum* rebuild, by which I assume you mean I've changed
> one file that nothing else depends on.  I don't see how you can be
> surprised at 15 minute builds when I didn't tell you how much source
> code I have, nor how much of it was changed.  Surely you will agree that
> *some* rebuilds on *some* projects take 15 minutes or more even on a
> modern fast workstation?
> 
> (By the way, my case is somewhat special: I work on a compiler written
> in its own language, and it's important from time to time to bootstrap
> the compiler -- compile it with itself, then use the resulting
> executable to compile it again, and then check that the executables are
> identical.  Sometimes three recompiles are necessary.  So this means
> that I'm doing a fair number of recompiles from scratch, as opposed to
> making a single change and recompiling just one file.)

How much source code do you have?  On a machine like that -- and I'm going
to regret saying this I just know it -- you must have a godawful compiler
to take 15 minutes, even if it is doing a full rebuild three times.  Does
yours do ultra-heavy optimization?  Phew!

> >is an issue which goes far beyond error messages, to programmer
> >productivity in general.  One of the things that slows down compilers is
> >trying to be ultra-clever about errors.  Which would you prefer:
compiler
> >(a) which takes 10 minutes to compile but stops at the first error (and
> >costs less, and is more reliable); or compiler (b) which takes 15
minutes
> >and has recovery?
> 
> I prefer (a).  Of course, the real bottleneck is often the linker, not
> the compiler.  Either way, I won't be satisfied until I can make various
> changes to a large body of code, and rebuild it in less than about 0.2
> second.

I agree about the linker.  Happiness is a linker hand-coded in assembly.

> In any case, I don't think error recovery is a substantial portion of
> compile time.  In many cases it's possible to design the compiler so
> that most of the error recovery work happens only when there actually is
> an error, in which case it doesn't matter so much.

This kind of design is even more complicated.  Trust your uncle Nicky, he's
been there, seen the film, read the book, bought the customised coffee mug,
_and_ the special edition set of figurines.  True, it's a neat trick if you
can do it!

> >I would be really surprised if a compiler giving a "name not visible"
> >didn't list all the candidates (the entities in the dictionary whose
names
> >could include the offending name).  You mean to say some compilers don't
do
> >this?  Now busy testing...
> 
> Sure, compilers do something along those lines, but there are various
> choices of what to print out, and not all compilers do an equally good
> job.  You say "the dictionary", as if it were one monolithic thing.  In
> Ada, there are all kinds of complicated scope rules.  If I declare X in
> a private part, and refer to X from outside, should the compiler point
> out that perhaps I meant to declare it in the visible part?  What if X
> is in the body (in which case the compiler won't normally be looking at
> that file at all, during this particular run)?

I've always thought that all compilers (written in conventional langauges)
have only one dictionary, with flags and things to distinguish the nitty
gritty.  Am I wrong?

> Here's an interesting example: Suppose I have a generic package
> List_Generic, which has a Push procedure in it.  And I instantiate that
> generic 17 times, for 17 different element types.  (The reason I'm
> talking about generics is that they cause heavy overloading.)  And I try
> to call Push on a list-of-integers, but I forgot to have a use_clause
> for the list-of-integers package.  An Ada compiler might try to point
> out missing use_clauses, but in this case, I believe most will not be
> smart enough to tell me which package -- it's obvious which package I
> meant, by looking at the types of the arguments to Push, but that's not
> easy to teach the compiler, especially in the presence of overloaded
> arguments.  Instead, I suspect most compilers will give me a list of 17
> Pushes I might have meant, or else will just point at the generic itself
> and let me track down the instances myself.  I believe I even remember a
> compiler that would print 17 references to the generic itself.

I was thinking along the lines of listing all the entities in the
dictionary of whose full name the offending name could be a part.  So, in
the above example, you would get all 17 instantiations of the Push
procedure, and you may well get other Pushes too.  With each full name
would go an indication of the kind of entity, e.g.

   Name "Push" not visible, candidates are as follows:
   - MyCom.ATCS.Airobject_Count_Stacking.Push procedure (in
Airobject_Count)
   - MyCom.ATCS.Tracker_Count_Stacking.Push procedure (in Tracker_Count)
   - MyCom.ATCS.Acquiror_Count_Stacking.Push procedure (in Acquiror_Count)
   <and so on>
   - MyCom.ATCS.Front_Panel.Buttons.Push type tagged record

This would have the obvious problem of verbosity.  But what, really, is the
sensible alternative?  Not to print nothing at all, surely.  To select
entities (e.g. only procedures, in this case)?  Dangerous, surely (could be
wrong).  I think everything has to be listed!  I have to say, I also think
that in most cases, in practice, there wouldn't be so many candidates.

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Always game for a verbal joust (usually as the turkey) ***