More caveats about #line

I posted here about how you can use #line in the C# compiler to associate C# code with some other source file than the one it was compiled with. This can be very useful for code generation and for "hiding" various parts of the function from the debugger.
"Josh" asked an interesting followup question here.

But what I really want to be able to do... is to insert something like
#lineNo and #methodName into C# code and have the compiler replace it with the current method name for instrumentation purposes. This would be much better than using reflection.
Maybe for Orcas?
 

I don't fully understand what he's asking, but it does bring up some interesting points.

First, you can give filename information as well as the line number, so you really can map to any random line in any random source file.  The syntax would be: #line 15 "MyFile.txt".

Second, recall that this #line stuff just changes how the sequence points (the IL to source mapping) in the pdb are written - it doesn't have any impact on the actual code generated or the metadata. Since the debugger uses the pdb to map from a function back to source, changing the pdb lets you have an arbitrary mapping here.

In constrast, a managed callstack uses metadata, and not PDB information, to get the function names. So the #line stuff won't affect the function name in the callstack.
So you can use #line to have it such that when you're stopped in function Foo(), it maps you to the source for function Bar(). However, the callstack will still be accurate and show that you're in function Foo().
You could name your new instrumented functions like Bar_Probe() instead of Foo(), and then use #line to map to file and line number for Bar()'s source. Then the callstack would be more intuitive. Compilers can use these sort of naming conventions to try and make their code more debuggable without changing codegen. (I recall observing anonymous delegates doing this)