Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

On Friday, 5 February 2016 at 20:35:16 UTC, Chris Wright wrote:
> On Fri, 05 Feb 2016 10:04:01 -0800, H. S. Teoh via 
> Digitalmars-d wrote:
>
>> On Fri, Feb 05, 2016 at 07:31:34AM +0000, tsbockman via 
>> Digitalmars-d wrote:
>>> On Friday, 5 February 2016 at 07:05:06 UTC, H. S. Teoh wrote:
>> OK, probably I'm misunderstanding something here. :-P
>
> I think you're talking about maintaining an in-memory, 
> modifiable data structure, doing one insert per operation and 
> one point query per use. That's useful for incremental 
> compilation, but it's going to be pretty slow.
>
> tsbockman is thinking of a single pass at link time that checks 
> everything at once. You append an entry to a list for each 
> prototype and definition, then later sort all those lists 
> together by name. Error on duplicate names with mismatched 
> signatures.

Yes.

> This is faster for fresh builds than it is for incremental 
> compilation -- tsbockman mentioned a brief benchmark, and that 
> cost would crop up on every build, even if you'd only changed 
> one line of code. (Granted, that example was pretty huge.) But 
> this might typically be faster than a bunch of point queries 
> even with incremental compilation.
>
> Anyway, that's why I'm thinking most people who used such a 
> feature would turn it on in their continuous integration server 
> or as a presubmit step rather than every build.

It doesn't necessarily have to be slow when you only changed one 
line:

* The list from the previous compilation could be re-used to 
speed things up considerably, although retaining it would cost 
some disk space.

* If that's still too expensive, just don't cross-check files 
that aren't being recompiled. The check will be less useful on 
incremental builds, but not *useless*. The CI server can still do 
the full check (using the compiler), as you suggest.

>> The problem is, the linker knows nothing about the language.
>
> We're only talking about a linker because we need to run this 
> tool after compiling all your files, and it has to know what 
> input files you're putting into the linker.
>
> So this "linker" is really just a shell script that invokes our 
> checker and then calls the system linker.

Yes. (Or, it's the compiler with a special option set, which then 
calls the linker after it finishes its global pre-link tasks.)