Type safety could prevent nuclear war

[Chris Wright via Digitalmars-d]

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:
>> >On Fri, Feb 05, 2016 at 04:02:41AM +0000, tsbockman via Digitalmars-d
>> >wrote:
>> >>On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote:
>> >>>On Fri, 05 Feb 2016 01:10:53 +0000, tsbockman wrote:
>> >>What information, specifically, is the compiler missing?
>> >>
>> >>The compiler already computes the name and type signature of each
>> >>function. As far as I can see, all that is necessary is to:
>> >>
>> >>1) Insert that information (together with what file and line number
>> >>it came from) into a big list in a temporary file.
>> >>2) After all modules have been compiled, go back and sort the list by
>> >>function name.
>> >
>> >This would make compilation of large projects excruciatingly slow.
>> 
>> It's a small fraction of the total data being handled by the compiler
>> (smaller than the source code), and the list could probably be directly
>> generated in a partially sorted state. Little-to-no random access to
>> the list is required at any point in the process. It does not ever need
>> to all be in RAM at the same time.
>> 
>> I can see it may cost more than it's actually worth, but where does the
>> "excruciatingly slow" part come from?
> 
> 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.

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.

> 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.