GSOC Linker project

[Steven Schveighoffer]

On Fri, 04 May 2012 15:07:43 -0400, Andrej Mitrovic  
<andrej.mitrovich at gmail.com> wrote:

> On 5/4/12, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
>> Current tools:  read .di files and extract API
>> new tools: read .dobj files and extract API.
>>
>> I'm not really seeing the difficulty here...
>
> I thought he meant libraries that are only distributed in binary form.
> So no .di files anywhere. Maybe I misunderstood..

No reason for .di files if the object file already serves as the interface  
file.

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

-Steve