Re: compile server design document

[Per Bothner <pbothner at apple dot com>]

Joseph S. Myers wrote:
> In C90 you have implicit function declarations, so given a declaration of 
> x in an outer scope,
>
>   foo(x);
>
> redeclares x if foo is a typedef, but implicitly declares and calls a
> function foo if foo isn't declared.

The problem is if foo was implicitly declared when the fragment was
first parsed, but there is an explicit, possibly conflicting declaration
when the fragment is re-used.  Can the compile server detect this?

One option is to disallow implicit declarations (or at least emit
a warning) when using the compile server.  People will just have
clean up their code if they want to use the compile server.

Another option is that the fragment has a dependency on the implicitly
declared function.  When we decide whether we can re-use the fragment,
we note that there is a conflicting definition.

> (No doubt header files should not
> contain that sort of thing in inline functions, but I think compile-time
> performance optimisations ought to start from the basis of always being
> correct, even in corner cases, and then optimise particular cases where a
> dependency isn't needed when it can be shown this is correct in that
> particular case.)

That's very nice, but I think unrealistic.  You could say the same thing
about run-time performance improvements, but they go in, and we later
discover bugs.  We also sometimes check in changes that we *know*
cause regressions, because we think on the whole it improves things.

Note also the correctness is a matter of implementation matching
the specification.  We are perfectly free to document that "if
you use the compile server, don't do XXX.  You shouldn't do XXX anyway,
but the compile server may give unpredictable results".  This isn't
that different from strict aliasing, which is actually *much more*
likely to cause real hard-to-detect problems.

Finally, I am not proposing the compiler server will be the default,
at least not for the foreseeable future.  I'm proposing it as an
*option* that will work well with reasonably clean code, and
speed up compiling that. As a side benefit, it may catch some
consistency errors that we otherwise don't catch, or it may enable
whole-program optimizations, or it may have other benefits.
We will then *incrementally* add more consistency checks,

A "fully-correct" compile server, even if possible and desirable,
is something that will take a while.  It should not stand in the
way of a "normally-correct" compile server that people can try if
they wish to.
--
	--Per Bothner
per at bothner dot com   pbothner at apple dot com  http://www.bothner.com/per/