GSOC Linker project

[H. S. Teoh]

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

-- 
Кто везде - тот нигде.