Agreed, I actually use this a lot when debugging backend bugs.
What I do is modify FuncDeclaration::toObjFile() in glue.c.
To do it properly would require a (fairly simple) pass over the syntax tree, but the function case one is the most important by far. As you can see, it's very simple.
Incidentally, when properly implemented, this feature would bring us much of the way towards having a C backend.


                //printf("'%s' is SCfastpar\n",sp->Sident);
            }
        }
    }
+ if (!parent->isDeclaration()) {    
+       printf("%s ", ((TypeFunction *)(func->type))->next->toChars());
+       printf("%s(%s)\n{\n %s}\n\n", func->toChars(),
+            parameters?parameters->toChars() : "",
+            func->fbody->toChars());
+ }
    if (func->fbody)
    {   block *b;
        Blockx bx;
        Statement *sbody;

        localgot = NULL;

        sbody = func->fbody;

Some time ago, I have been playing around with a patch to dmd that would dunp any mixin expansion into a file passed on the command line. After compilation, you could look them up, but even better, you can single step through the code with a debugger (at least, if there are line feeds in the mixin). 

Another benefit: source line numbers in mixins do not overlap with the source code after the mixin anymore, but the patch was not good enough to show the place of instantiation in an error message.

If there is interest, I can dig it up and create a diff to current svn.

Yeah, post it, please.

Created attachment 839 [details]
write mixin expansions to file

Here it is against svn 780.

Usage is: dmd test.d -mixin=mixins.d

What's missing is the instantiation backtrace for the line numbers in the error messages, but the resulting mixin file shows the source line number of the instantiation in a comment.

Here's another proposal:
https://github.com/D-Programming-Language/dmd/pull/426

According to Walter, dmd has a --b flag (purportedly only in debug builds?) that prints the expression trees sent to the backend. Not quite preprocessed D code per se, but close enough for debugging purposes.

No, --b prints out stuff like this:

********* Basic Block 003B7D28 ************
el:003B9488 cnt=0 cs=0 ,  TYvoid 003B8C20 003B9450
 el:003B8C20 cnt=0 cs=0 =  TY* 003B8B40 003B8BE8
  el:003B8B40 cnt=0 cs=0 var  TY*  c
  el:003B8BE8 cnt=0 cs=0 call  TY* 003B8BB0 003B8B78
   el:003B8BB0 cnt=0 cs=0 var  TYC func  _d_newclass
   el:003B8B78 cnt=0 cs=0 relconst  TY*  0+& _D5testx5C16877__ClassZ
 el:003B9450 cnt=0 cs=0 ||  TYvoid 003B9230 003B9418
  el:003B9230 cnt=0 cs=0 ==  TYbool 003B8DA8 003B91F8
   el:003B8DA8 cnt=0 cs=0 *  TY* 003B8D70
    el:003B8D70 cnt=0 cs=0 +  TY* 003B8C90 003B8D38
     el:003B8C90 cnt=0 cs=0 *  TY* 003B8C58
      el:003B8C58 cnt=0 cs=0 var  TY*  c
     el:003B8D38 cnt=0 cs=0 *  TYunsigned 003B8CC8 003B8D00
      el:003B8CC8 cnt=0 cs=0 const  TYunsigned 0L
      el:003B8D00 cnt=0 cs=0 const  TYunsigned 4L
   el:003B91F8 cnt=0 cs=0 *  TY* 003B91C0
    el:003B91C0 cnt=0 cs=0 +  TY* 003B9150 003B9188
     el:003B9150 cnt=0 cs=0 ,  TY* 003B9070 003B9118
      el:003B9070 cnt=0 cs=0 =  TYlong long 003B8EB0 003B9038
       el:003B8EB0 cnt=0 cs=0 var  TYlong long  __dgtmp4

Not really usable for debugging anything except the glue layer.

I also find this usefull and in the absence of such feature currently use expression dumping (exp->toChars()) during IR stage - https://github.com/mxfm/dmd/compare/patched, but Don's way is probably better.

Just don't such switch "partial compilation" because in computer science "partial compilation" or "partial evaluation" mean something different for compilations:
http://en.wikipedia.org/wiki/Partial_evaluation

That would be an interesting project. I'm envisioning it as a standalone program called e.g. "dlower" that lowers D code into a smaller subset of D. Possible flags for that program:

--expand-mixins = expand all possible mixins in the code

--lookup = execute lookup on all symbols and write the full symbol, e.g. writeln becomes .std.stdio.writeln

--operators = explicitate all user-defined operators, e.g. a + b becomes a.opBinary!"+"(b)

--omit-function-bodies = do not output function bodies, .di style

--specialize-templates = write specialized versions for all templates used within the module (this is likely to be tricky)

--scope = lower all scope statements into try statements

--foreach = lower all foreach statements into for statements

--explicit-import = specify the exact symbols needed for each import statement (which means: if no symbols, the import is redundant - easy to mark as a warning by a subsequent tool)

--static-if = evaluate all static ifs possible (this mostly makes sense if --specialize-templates is also present)

--versions = lower code using version(), i.e. make the unused branch disappear

--omit-comments = make all comments disappear

--omit-nondoc-comments = make only non-documentation comments disappear

--ctfe = evaluate all possible CTFEs (tricky)

The tool should generate compilable D code with the same semantics as the input and #line directives pointing to the input.

Such a tool would make possible a bunch of others. I'll talk to the graduate students, maybe someone will take this.

*** Issue 5137 has been marked as a duplicate of this issue. ***

We have -mixin now, so I guess we can close this (considering Andrei's suggested tool out of scope for this issue).

*** This issue has been marked as a duplicate of issue 12790 ***