DI Generation Needs your Help!

[Adam Wilson]

On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro <alvaroDotSegura at gmail.com>  
wrote:

> El 19/12/2011 9:11, Adam Wilson escribió:
>>
>> 1. Function Implementations are removed
>>
>
> What about function inlining? would it work from a different module?
>
> I think the implementation of small functions should be kept so that  
> client code can inline them.
>
> The current DMD does this apparently, it keeps small functions in .di  
> files.

The problem is that in DI generation, at least as near as I can tell, D  
has now idea how big a function is during DI generation. In my experience  
it was keeping all functions not just small ones. And frankly DI  
generation is targeted at library builders who are well aware of the  
inlining trade-offs. And then comes the question of how do you define  
"small functions" to an adequately technical level. Because theoretically  
you can inline ANYTHING. Yes, there are rules the prevent inlining, but  
you'll also note that the state of these rules is not guaranteed to be  
known at generation time.

DI generation currently works as such. After the code has been parsed into  
an AST, the compiler runs a special set of virtual functions called  
toCBuffer (and it's variants) that is used to print out the AST in source  
form again. NO semantic analysis of any kind has been performed on the AST  
yet. And you wouldn't want to generate DI's after semantic analysis as the  
analysis fundamentally alters the AST such that you would not get the same  
code back out and some things would be missing from the DI files that you  
intended to be there. The AST at DI generation is an incredibly naive  
representation of the SOURCE not the SEMANTICS; which is what you would  
need to determine the eligibility of inlining.

The answer that Walter has always given for objections about how DI files  
are built is that if you want anything customized about the output, you  
have to do it yourself. DI generation will probably NEVER be as perfect as  
everyone wants. But I think this solution represents a best effort to get  
DI files to a point where the community agrees that they would be most  
useful in achieving their intended purpose, which is as interface files  
for compiled libraries. It's not perfect, but it gets you A LOT further  
than the current one, if you need customization beyond that, well, D lets  
you do that too. :-)

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