On Wed, Dec 10, 2014 at 07:00:24PM +0000, Tobias Pankrath via Digitalmars-d wrote: > >>// my code > >>foo!(ArcaneType1, DubiousType2)(a, d); > > > >That's why the current object file model doesn't work very well. > > > >You'd have to extend the object file format to include compiler IR > >for templates, then the compiler can instantiate templates from that > >IR without needing access to the source. Which is a feature I've > >brought up several times, but nobody seems to be interested in doing > >anything about it. > > > > > >T > > What information would / could that IR contain besides an AST?
It could include additional attributes computed by the compiler that could help in later optimization, such as whether the function escapes references, any inferred function attributes, etc.. The compiler could recompute all this from the IR, of course, but if it's already computed before, why not just reuse the previous results. Also, storing a full AST is probably overkill -- lexing and parsing the source generally doesn't take up too much of the compiler's time, so we might as well just use the source code instead. What makes it more worthwhile is if the AST has already been somewhat processed, e.g., constants have been folded, etc.. Probably after semantic1 and semantic2 have been run (though I'm not sure how far one can get if the template hasn't been instantiated yet). This way, work that has already been done doesn't need to be repeated again. T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
