Problems with Template codegen

[kris]

At this time, D templates are a bit finicky when it comes to argument 
matching -- IFTI matching, to be explicit. For example:

# uint locate(T) (T[] source, T match, uint start=0);
#
# locate ("wumpus", 'p', 1);

will not compile because '1' is an integer literal, and does not match 
the template parameter 'uint'.

To get around this, template writers will revert to tricks like this one:

# uint locate(T) (T[] source, T match, uint start=0);
#
# uint locate(T, U=uint) (T[] source, T match, U start=0)
# {
#     return locate!(T) (source, match, start);
# }
#
# locate ("wumpus", 'p', 1);


See what's going on? There's a stub added, which marshalls (for want of 
a better term) the 'int' argument  across. This is done to (a) permit 
use of both int & uint arguments and (b) to avoid template duplication 
for both int and uint types.

So, that's a current shortcoming of IFTI -- but it's one that we hope 
will be fixed. Moving onto the primary concern ...

As one would expect, the DM compiler generates code for the stub to 
re-push the arguments and call the /real/ implementation. However, in 
/all/ cases we really want to eliminate the stub since it is nothing but 
a pass-through call; one generated to workaround what seems to be an 
IFTI limitation.

Unfortunately, the DM tools will remove the stub /only/ when you use the 
-inline switch. This is a very powerful switch, causing all kinds of 
inlining to occur -- in some cases, things which many engineers would 
balk at. Inline is often just too /big/ a switch to pull.

However, we'd still like darned stubs to be removed from the codegen. 
How do we get that to happen?