On 12/14/2011 09:05 PM, Adam Wilson wrote:
On Wed, 14 Dec 2011 10:58:30 -0800, Timon Gehr <[email protected]> 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.
