On 2011-12-23 01:22, Adam Wilson wrote:
> On Thu, 22 Dec 2011 13:02:49 -0800, Jacob Carlborg <doob@me.com> wrote:
>> Never mind, it seems to be working.
>
> Did you check it against my forked code? I want to make sure that there
> are as few errors as possible before I open up the pull. :-)
>

No, I checked with DMD 1.072.

-- 
/Jacob Carlborg

On 12/19/11, Adam Wilson <flyboynw@gmail.com> wrote:
> If anyone wishes to test my changes against their code, you can download them from my git account here: https://LightBender@github.com/LightBender/dmd.git

This seems to work nicely even with the latest release. It's much better than the current .di generation for sure. Any plans on merging this with mainline before it goes stale?

On 3/14/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> This seems to work nicely even with the latest release. It's much better than the current .di generation for sure. Any plans on merging this with mainline before it goes stale?

Although I would really like to be able to keep documentation comments in the .di files, e.g.:

class Foo {
    /** Commented ctor. */
    this() { }
}

->
class Foo {
    /** Commented ctor. */
    this();
}

On Wed, 14 Mar 2012 12:30:00 -0700, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 12/19/11, Adam Wilson <flyboynw@gmail.com> wrote:
>> If anyone wishes to test my changes against their code, you can download
>> them from my git account here:
>> https://LightBender@github.com/LightBender/dmd.git
>
> This seems to work nicely even with the latest release. It's much
> better than the current .di generation for sure. Any plans on merging
> this with mainline before it goes stale?

I am currently maintaining this against DMD HEAD, but until this bug (http://d.puremagic.com/issues/show_bug.cgi?id=7423) gets fixed I can't open a pull request because the patch will break both the Phobos and DRuntime builds badly without it.
I would fix the bug myself, but I am getting married in a month and am rather short on time. Earliest I'll likely be able to investigate a fix is May. If anyone else wants to take a shot at a fix before then, I'd happily open up a pull request once they're done.

On Wed, 14 Mar 2012 12:35:03 -0700, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 3/14/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>> This seems to work nicely even with the latest release. It's much
>> better than the current .di generation for sure. Any plans on merging
>> this with mainline before it goes stale?
>
> Although I would really like to be able to keep documentation comments
> in the .di files, e.g.:
>
> class Foo {
>     /** Commented ctor. */
>     this() { }
> }
>
> ->
> class Foo {
>     /** Commented ctor. */
>     this();
> }

I'll look into it when I get the chance. :-)

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

El 19/12/2011 9:11, Adam Wilson escribió:
>
> 1. Function Implementations are removed
>

What about function inlining? would it work from a different module?

I think the implementation of small functions should be kept so that client code can inline them.

The current DMD does this apparently, it keeps small functions in .di files.

On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro <alvaroDotSegura@gmail.com> wrote:

> El 19/12/2011 9:11, Adam Wilson escribió:
>>
>> 1. Function Implementations are removed
>>
>
> What about function inlining? would it work from a different module?
>
> I think the implementation of small functions should be kept so that client code can inline them.
>
> The current DMD does this apparently, it keeps small functions in .di files.

The problem is that in DI generation, at least as near as I can tell, D has now idea how big a function is during DI generation. In my experience it was keeping all functions not just small ones. And frankly DI generation is targeted at library builders who are well aware of the inlining trade-offs. And then comes the question of how do you define "small functions" to an adequately technical level. Because theoretically you can inline ANYTHING. Yes, there are rules the prevent inlining, but you'll also note that the state of these rules is not guaranteed to be known at generation time.

DI generation currently works as such. After the code has been parsed into an AST, the compiler runs a special set of virtual functions called toCBuffer (and it's variants) that is used to print out the AST in source form again. NO semantic analysis of any kind has been performed on the AST yet. And you wouldn't want to generate DI's after semantic analysis as the analysis fundamentally alters the AST such that you would not get the same code back out and some things would be missing from the DI files that you intended to be there. The AST at DI generation is an incredibly naive representation of the SOURCE not the SEMANTICS; which is what you would need to determine the eligibility of inlining.

The answer that Walter has always given for objections about how DI files are built is that if you want anything customized about the output, you have to do it yourself. DI generation will probably NEVER be as perfect as everyone wants. But I think this solution represents a best effort to get DI files to a point where the community agrees that they would be most useful in achieving their intended purpose, which is as interface files for compiled libraries. It's not perfect, but it gets you A LOT further than the current one, if you need customization beyond that, well, D lets you do that too. :-)

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Adam Wilson:

I think I said this before, but for what it's worth,
I think your new approach is spot-on correct.

On 3/14/12, Adam Wilson <flyboynw@gmail.com> wrote:
> I would fix the bug myself, but I am getting married in a month and am rather short on time.

That's ok I'm in no hurry just curious. Congrats on getting married! :)

On Wed, 14 Mar 2012 14:23:19 -0700, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 3/14/12, Adam Wilson <flyboynw@gmail.com> wrote:
>> I would fix the bug myself, but I am getting married in a month and am
>> rather short on time.
>
> That's ok I'm in no hurry just curious. Congrats on getting married! :)

Thank you! Hehe, well, I have big plans for D, but I need DI files to work better to execute them, so I am a little bit of a hurry, but real life wins for now. ;-)

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/