Repository: rust
Issue: `Location` is missing the function name
Labels: C-enhancement,T-compiler,A-error-handling

For our project, I implemented a version of `Result` which uses `Try` trait in such a way as to track the error handling locations, so we get a "call stack" of the error at the end. This works in conjunction with `#[track_caller]` very well and we see the locations the error handling took.

However, there is one major deficiency in `Location` - it only gives us the source name and line. Yes, with that, it's possible to manually look up the function where it happened, but it would be significantly simpler to evaluate bug reports by looking at the call trace with function names (we have practiced this in a large C++ project, where basically the dev support standardized on initially evaluating everything by function names in the call trace, ignoring line numbers). So it would be extremely useful if the `Location` would be extended with another `&str` containing the function name (ideally with generics). It can be also a mangled name, I don't care much, but the function name is important.

Before you shout "backtrace!" - yes, but... We are using heavy asynchronous processing, handling errors across `await`s, where the backtrace has about zero value. Similar for tracing, we can't just keep the trace active permanently due to performance reasons. So the error handling "call stack" is a perfect compromise - cheap and sufficiently valuable (except that it's missing the function name).

According to my code study of the Rust compiler code, it should basically boil down to getting the function name from the current `Span` and adding it in addition to the file name to the generated const `Location` here:

https://github.com/rust-lang/rust/blob/012720ffb075a087b781325d17d1822a340a2f2a/compiler/rustc_codegen_cranelift/src/common.rs#L351

I raised this initially in a comment in https://github.com/rust-lang/rust/issues/47809. Here some observations from the discussion there:
- It's clear that adding the function name will increase generated string section (by potentially quite a bit), because instead of a single string per file we'll need to store potentially many strings per file.
- It's also clear that compilation speed might be minimally affected (only where the location is actually used, though), because instead of a single string with the file name another string with the function name must be created.

To alleviate this, storing function name could be made optional at compilation time, e.g., using a compiler flag.

Of course, one could argue that this could be also done in post-processing of traced errors. Of course, that's a possibility. But that's another step, which makes it quite cumbersome to use and needs a lot of resources and exact source code. The compiler already knows it at compile time and aside from costing more space in the generated executable (string section), there should be no adverse effects of having the function name in the `Location`.

Further, having the function name in `Location`, it would in general allow building various tools which use the location for debugging purposes, which in turn would help the community in general. So I think it's worth extending it.

@anp, @eddyb & @aturon you seem to have worked on this topic recently, so CC to you.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"BGR360"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->