DI File Generation

[Timon Gehr]

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.