GSOC Linker project

[Alex Rønne Petersen]

On Friday 04 May 2012 11:17 PM, H. S. Teoh wrote:
> On Fri, May 04, 2012 at 03:13:21PM -0400, Steven Schveighoffer wrote:
> [...]
>> I think he meant that object (and library) binary files would be
>> augmented by API segments that provide what di files provide now --
>> an interface-only version of the code.  It doesn't have to be text,
>> it can be binary (maybe even partially compiled).
>>
>> The really nice thing you get from this is, the compiler now would
>> use this object file instead of .d files for importing.  So not only
>> do you eliminate errors from having two possibly separately
>> maintained files, but the compiler can build *extra* details into
>> the .dobj file.  For example, it could put in metadata that would
>> allow for full escape analysis.  Or tag that a function is implied
>> pure (without actually having to tag the function with the pure
>> attribute).
> [...]
>
> +1. It's about time we moved on from 30+ year old outdated linker
> technology, to something more powerful. Full escape analysis, compiler
> deduced function attributes like pureness, all the stuff that's
> impractical to implement in the current system, can all be done in a
> reasonable way if we stuck this information into the object files. The
> linker doesn't have to care what's in those extra sections; the compiler
> reads the info and does what it needs to do. The linker can omit the
> extra info from the final executable. (Or make use of it, if we
> implement a smarter linker. Like do cross-module string optimization, or
> something.)
>
>
> T
>

Purity inference won't happen either way. Purity is part of your API and 
also meant to help you reason about your code. If the compiler just 
infers purity in a function and you later change the implementation so 
it's no longer pure, you break your users' code. Also, purity would no 
longer help you reason about your code if it's not explicit.

-- 
- Alex