Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

On Friday, 5 February 2016 at 06:05:49 UTC, Chris Wright wrote:
> It doesn't know what targets I'm ultimately creating, and it 
> doesn't know what files have been modified that I'm about to 
> compile (but haven't compiled yet).
>
> Example 1:
>
> I compile one .c file referencing a function:
> void foo(int);
>
> That's going to end up in libfoo.so.
>
> I compile another .c file in the same directory defining a 
> function:
> void foo(float);
>
> That's going to end up in libbar.so.
>
> No bug here. (The linker should tell us if someone depends on 
> foo from libbar and foo from libfoo in the same executable.)
>
> How does your putative compiler plugin handle it? Either I have 
> to define a build rule for every source file to specify where 
> to put this symbol cache (and you need to add parameters for 
> the plugin to look for multiple caches, because libfoo and 
> libbar share a lot of source files), or the plugin gives me 
> false positives.
>
> Example 2:
>
> I compile a.c:
> int foo(int i) { return i + 1; }
>
> In the course of refactoring, I delete that function from a.c 
> and add it
> to b.c with modifications:
> int foo(int i, int increment) { return i + increment; }
>
> My build script recompiles b.c before it recompiles a.c. Your 
> compiler plugin produces a build error, halting my build. I 
> have to make clean && make in order to proceed -- and that's 
> assuming I know your tool doesn't work well with incremental 
> compilation.
>
> The first problem might be uncommon, but the second would crop 
> up constantly. They have the same fix: collect the information 
> when you compile, evaluate it when you link.

No spurious error is generated by my proposal in your example 2, 
because I specifically stated that the extra pass must be done 
once, after *all* modules have been compiled.

I see, however, that this would require one of:

1) Modifying build scripts to pass the complete list of .c files 
to the compiler in a single command, or
2) Modifying build scripts to run the compiler one extra time 
after processing all the .c files, or
3) Run the final check at link-time.

For a C tool chain with a clean-sheet design, any of those would 
handle example 2 fine. (1) or (3) could also handle example 1 
without issue.

However, as you say, only (3) is backwards compatible with 
existing make files and what-not. (This is not a limitation of 
the C language or ABI, though.)