DI File Generation

[Adam Wilson]

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.

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