DI File Generation

[Adam Wilson]

On Wed, 14 Dec 2011 12:30:33 -0800, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 12/14/2011 09:05 PM, Adam Wilson wrote:
>> On Wed, 14 Dec 2011 10:58:30 -0800, Timon Gehr <timon.gehr at gmx.ch>  
>> wrote:
>>
>>> On 12/14/2011 07:47 PM, Adam Wilson wrote:
>>>> Hello everyone,
>>>>
>>>> As some of you may be aware I have been working on improvements to the
>>>> .di file generation capabilities in D
>>>
>>> Nice!
>>>
>>>> and I've run across a few things
>>>> that I think should be put to the community.
>>>>
>>>> The first involves the handling of variable instantiation. Say you
>>>> create the following member variable in a class:
>>>>
>>>> export int Foo = 1;
>>>>
>>>> Currently the di generation output is identical to the above line. My
>>>> understanding is that, similar to C/C++, D doesn't care if you keep  
>>>> the
>>>> initializer in the include file so this is primarily a stylistic
>>>> question.
>>>> Should we keep the output as is, or remove the initializer? My  
>>>> personal
>>>> preference is to remove the initializer but I think the community  
>>>> should
>>>> decide.
>>>>
>>>> Another question that has come up pertains to the reason for the
>>>> original implementation of DI generation, inlining. According to what
>>>> I've read on these newsgroups and various other sources, DI generation
>>>> is supposed to include the implementation for some small functions  
>>>> that
>>>> would be good inlining candidates, however, it looks like is actually
>>>> happening is that all DMD does is check to see if there are any cases
>>>> where the compiler would fail if it attempted to inline the function.  
>>>> As
>>>> long as the compiler can compile it, it gets thrown into the DI file,
>>>> regardless of size. My current patches never include the  
>>>> implementation,
>>>> and I think that for most people this is a reasonable solution, if not
>>>> ideal. All of the people I've talked to seemed to agree. What do you
>>>> think? Does this work for you?
>>>
>>> Yes, it is always possible to include the function bodies manually or
>>> to compile the modules together for release mode if inlining is that
>>> important. For now, .di generation should ideally just work.
>>>
>>>> Should there be a way to specify the
>>>> maximum size of an inline function? NOTE: Doing this would require at
>>>> least a command line switch and probably some significant reworking of
>>>> the function symbol exporter. As such it'd take a lot more time to get
>>>> into to D; I'd recommend implementing the simple solution first then
>>>> adding this only if it's requested by a significant number of people.
>>>>
>>>> The next question is primarily directed at Walter, but anybody who  
>>>> knows
>>>> anything about the compiler internals is welcome to chime in. For
>>>> functions defined in Class and Interfaces, calling isFuncDeclaration()
>>>> as I iterate through the symbol tree works as expected and returns the
>>>> Function. However, when I try to call that on a function that is
>>>> declared in a module (with no surrounding class) or in a struct, it
>>>> always returns null, regardless of whether or not it's actually a
>>>> function. Is there any way to determine if the symbol is a function  
>>>> when
>>>> it's not a class member? NOTE: As near as I can tell, it is actually a
>>>> FuncDeclaration.
>>>>
>>>> The final bit of DI generation revolves around the handling of  
>>>> protected
>>>> functions in exported classes. But that's better suited to a separate
>>>> topic as that involves the general design of scoping in D2 and isn't
>>>> limited to DI generation. I'll be posting another topic on that soon.
>>>>
>>>> Thank you all for taking the time to read and chime in on this!
>>>>
>>>
>>> How will your patch handle top level string mixins/static if's/version
>>> declarations?
>>
>> At the moment, it doesn't do anything with them that I know off, but I
>> don't know enough about how the compiler handles those constructs to
>> give a good answer. Although if you have a piece of code that you can
>> share for testing against my patches, i'll let you know.
>>
>
> I think currently it just creates a corrupted .di file if it encounters  
> the construct. Ideally it would just expand them to make their  
> compilation faster.

We'll have to complain loudly enough to Walter about that then. I'm not  
familiar enough with the compiler internals to tackle that issue myself.  
:-)

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