GSOC Linker project

[foobar]

On Friday, 4 May 2012 at 19:21:02 UTC, Andrew Wiley wrote:
> On Fri, May 4, 2012 at 1:46 PM, foobar <foo at bar.com> wrote:
>
>> On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
>>
>>> On 5/4/12, foobar <foo at bar.com> wrote:
>>>
>>>> The di files are mostly meant to be machine read (e.g. the
>>>> compiler) and this belongs as part of the library file in 
>>>> order
>>>> to provide ease of use and maintain the relationship between 
>>>> the
>>>> binary code and it's interface.
>>>>
>>>> maintaining two sets of files that could easily get out of 
>>>> sync
>>>> and *not* using the docs is way more insane.
>>>>
>>>>
>>> I'd say the docs are more likely to be out of sync than .di 
>>> code. If
>>> the .di code is really out of sync you'll likely even get 
>>> linker
>>> errors. And not everything ends up being documented.
>>>
>>> And then what about existing tools like IDEs and editors. E.g.
>>> autocomplete wouldn't work anymore.
>>>
>>
>> I'd say you'd be wrong.
>> Both di and docs are auto-generated from the same source.
>> As I said docs are designed for human consumption. This 
>> includes all sorts
>> of features such as a table of contents, a symbol index, the 
>> symbols should
>> have links, the docs provide usage examples, etc, etc.
>> Docs can be put online thus ensuring they're always up-to-date.
>>
>> Tools should either read the data from the lib file or 
>> retrieve it from
>> the web. Keeping separate local di files is simply insane.
>>
>> And really, have you never heard of Java? How about Pascal?
>> Should I continue back in history to all the languages that 
>> implemented
>> this feature decades ago?
>> C/C++ is a huge PITA with their nonsense compilation model 
>> which we
>> shouldn't have copied verbatim in D.
>>
>
> I like the idea, but what about templates? For them, you'd 
> basically be
> stuffing source code into the object files (unless you came up 
> with a way
> to store the AST, but that seems like the effort/benefit ratio 
> wouldn't be
> worth it since we currently have no way to preserve an AST tree 
> between
> compiler runs).
> Otherwise, I find this idea very compelling. I'm sure there are 
> probably
> other issues, though.

C++ has pre-compiled header files (.pch) which speedup 
compilation time for projects with lots'o'templates. The same 
kind of info could be stored inside the object files, for example 
by serializing the AST as you said yourself.

There are many uses for this kind of technology. we can store 
additional info that currently isn't available for all sorts of 
link-time optimizations.