DI File Generation
Adam Wilson
flyboynw at gmail.com
Wed Dec 14 10:47:17 PST 2011
Hello everyone,
As some of you may be aware I have been working on improvements to the .di
file generation capabilities in D 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?
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!
--
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
More information about the Digitalmars-d
mailing list