DI File Generation

[Timon Gehr]

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?