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.
