RFC: Add "function name macro"

[mitsuhiko]

This RFC proposes the addition of a function! macro that expands to the function it's used in. This will greatly help error reporting.

Rendered View

[nrc]

What name will you give for anonymous functions such as closures?

[mitsuhiko]

As mentioned the name of the function they are contained in is used.

[bstrie]

The function in which they are defined, or the function in which they are invoked?

[scialex]

It would need to be the one they are defined in, unless we want to hold onto that information and pass it through dynamically, which seems heavy for a debug feature.

[thestinger]

I don't think Rust should continue down this road. I consider the usage of row / column numbers in failure messages to be a serious design flaw. It's a severe code bloat / performance issue along with resulting in terrible messages with only the local context (like Option::unwrap). It should just be using debug info to print out the source location and a traceback.

[mitsuhiko]

@thestinger what's your alternative? I rely on this error information to produce proper debug information. Taking it away without providing a replacement is not exactly a good idea. Obviously it's not fast, but that's hardly the point of a debug helper.

[dobkeratops]

+1 to this. Also I've always wondered if there could be a macro for the 'enclosing' function name in the case of inlined generic code.. you want to know where its' invoked from (e.g. iterators etc).
and as pointed out by the OP, just because something isn't useful for Release, doesn't mean it isn't useful . There's only so much you can determine at compile time... Rust doesn't obsolete the concept of debug builds with extra checks & so on.

[mitsuhiko]

I think this RFC should be seen separate to finding alternatives to line/file etc. I understand that @thestinger is concerned with compiling too much bloat into binaries but there are plenty of situations where this is actually a much more reasonable approach than using libbacktrace. For instance any logging system will probably see much higher performance from using line!() and others over trying to read DWARF info whenever it needs to log something.

[bstrie]

function!() does strike me as too generic. I much prefer the descriptiveness of function_name!(). I don't mind the underscore because ideally you'd have this wrapped in some more general error handling device.

[andrew-d]

+1 to this - would find this kind of information very useful, and there's precedent in systems languages already: C/C++ compilers provide the __func__ #define already.

[alexcrichton]

cc rust-lang/rust#9668, quite an old PR which attempted this some time ago.

I do think that the actual output of this macro is somewhat orthogonal to considering its inclusion. Many uses of function!() have an obvious return value, and I would suspect that we are at liberty to alter the "flavorful" use cases throughout the lifetime of the compiler (e.g. change the output in rust 1.1 and then again in rust 1.4). So in that sense, I don't want to get too bogged down into the details of what precisely is being emitted just yet. Nevertheless, I have a few questions!

• As a prelude macro (sorry about that!) we should take careful consideration of the name of this macro as well as its interface (primarily the output type). We won't be able to change it for forever most likely.
• The return type of this macro is interesting, you propose Option<&'static str> but as @huonw points out it would be quite useful to use concat! with a pre-existing macro like module_path! in order to generate a "full path".
• How useful is the vanilla name of a function? For example, a type could implement any number of methods named foo through a number of traits. I think that considering the scope of function may also be critical for this RFC (e.g. whether it's in an impl, whether it's a free function, whether it's a trait function, etc).

In general I don't think any of us have given an inordinate amount of thought to these "debugging related" macros in terms of long term stability. Most of them seem fairly harmless, but committing to provide all of them for all Rust programs forever is a strong commitment to make. We may want to briefly consider the story of these macros in conjunction with considering adding this new macro.

Regardless, thank you for taking the time to write this up @mitsuhiko! The work you're doing with error reporting is quite exciting, and I'd love to improve it even more!

[liigo]

Is this RFC merged normally? I can't find its content in both rfcs repo and @mitsuhiko 's "Rendered View" link. Github shows there is no commit and no file changed in this PR. @alexcrichton

[alexcrichton]

No this was an accident when @mitsuhiko updated his local master branch, I believe he was going to re-open the PR, or did I mis-hear @mitsuhiko?

[nstoddard]

Is this still being worked on? The 'rendered view' link doesn't work.

[androm3da]

I support the addition of a macro like __func__. I recognize the challenge in deciding on what/how to report on the context/path of this particular function. What's needed to move forward? A proposal that addresses @alexcrichton 's points? An implementation?

[ghost]

Rendered View

EDIT: Well, ignore this current issue, looks like the following one is overriding it AND still open: #1743