Re: compile server design document

[Per Bothner <pbothner at apple dot com>]

Devang Patel wrote:
> - "This assumes that (normally) a header file consists mainly of 
> declarations (including macro definitions), and the "meaning" of these 
> declarations does not chnge across compilations."
>
> In C++ headers, inline function definitions are everywhere. But even 
> <stdio.h> brings in this little jewel
>
> static __inline int __sputc(int _c, FILE *_p) {
>         if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
>                 return (*_p->_p++ = _c);
>         else
>                 return (__swbuf(_c, _p));
> }

A definition is also a declaration.  I don't off-hand see a problem
with this, beyond the general dependency-tracking issues.  There is
one complication in that gcc mushes seclaration (including forward
declarations) and a definition into a single tree.  We may need to
un-mush them, in case some other compilation unit just defines a
declaration.  This is similar to the issue of declarations vs
definiions of struct tags, and can I think be handled the same
way (abstractly):  When we see a combined declaration/definition,
treat as a separate declaration followed by a definition.  This
allows a separate compilation to re-use the declaration without
the definition.

> - Do you have any info/data/rough estimate about fragments per header 
> for popular headers like stdio.h, iostream and Carbon.h ?

Not really.  The systems ones will probably have more conditionals and
other magic than typical headers.

> - "Depending on lack of a macro bindings" issue. In C++, namespaces also 
> creates similar problem.

Yes, the presence or absence of using declarations and directives
may also complicate things.

> - "Types defined in multiple locations". Do you plan to detect and 
> report violation of extended single one-definition rule?

I think that would be desirable, as a warning at least.  I don't
think it would automatically fall out of the compile server work,
but the compile server at least makes it easier to make these
more global checks.  It shouldn't be hard or expensive to add.

> - And last question is a implementation detail. Any idea how client will 
> know if server went in infinite loop or an ICE?

No.  If the server dies, hopefully there is some way the client
will receive an error report when waiting for the reponse, but
I don't know enough of it.  Infinite loops are trickier.  But
then how does make know when gcc does into an infinite loop>
--
	--Per Bothner
per at bothner dot com   pbothner at apple dot com  http://www.bothner.com/per/