Implement the function!() macro

[da-x]

See: rust-lang/rfcs#1743

The introduced function!() macro in this change, returns a value of &'static str, that specifies the current function by name. It is an empty string if not used inside a function.

Under nesting of other functions, the outer functions will be included too with :: as a 'function path' separator. Under methods and traits, the trait or type name will be included. For types having type
parameters, the type parameters are not expanded, so the same string is used for all instantiations. For an impl of anonymous types such as (bool, u32), the name of the implemented trait is provided.

For example,

test.rs:

fn main()
{
    fn inner() {
        println!("{}", function!());
        fn inner_a() {
            println!("{}", function!());
        }
        inner_a();
    }

    fn inner2() {
        println!("{}", function!());
        fn inner_b() {
            println!("{}", function!());
        }
        inner_b();
    }

    println!("{}", module_path!());
    println!("{}", function!());
    inner();
    inner2();
}

Emits:

test
main
main::inner
main::inner::inner_a
main::inner2
main::inner2::inner_b

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[pnkfelix]

Hmm my suspicion is that a change like this needs to actually go through the RFC process to actually approve a design first. (The rust-lang/rfcs#1743 in the RFC repository represents a potentially desirable language feature that needs the design work done first; that's why its an issue in that repository rather than an issue in rust-lang/rust.)

Having said that, it seems like a lot of the work in this PR is similar to what had been outlined in rust-lang/rfcs#1719, a draft RFC that was closed due to inactivity but I think a lot of people were quite interested in.

So I am hesitant to just close this PR saying "needs an RFC first" ... maybe we can land it if it included feature gates and tests...

[pnkfelix]

cc @rust-lang/lang (or is there a better group more directly focused on what macros the compiler provides? I cannot think of one off hand)

[pnkfelix]

Let me be a little clearer:

I haven't done a thorough review yet. I can immediately tell you that this needs a feature gate and unit tests before it could possibly land.

But I also don't want the author to get dragged down addressing nitpicky revisions if it ends up being something where the lang team closes it with a note saying "needs to go through RFC process first."

Let me try to see if the lang team can get a chance to talk about this at their weekly triage.

[pnkfelix]

(oh, I just noticed that @da-x had even commented on rust-lang/rfcs#1743 saying that this is meant to service as a working reference implementation to promote discussion while hashing out an actual RFC...)

[da-x]

I've implemented this feature out of necessity for a logging system that I am writing, after seeing that the RFC was stalled for years. There may be other logging systems out there that were never released as open source due to a habit of companies to write logging systems 'in-house'.

Thanks for helping to promote it. Even if the changes don't make in, perhaps someone may find them useful.

[joshtriplett]

I don't know why rust-lang/rfcs#1743 has stalled out for as long as it has. I've nominated it for discussion in the next lang team meeting.

This will definitely need a feature gate and unit tests, as @pnkfelix mentioned. Given those, and approval from the language team, I'd like to see this land.

[joshtriplett]

We discussed this (and rust-lang/rfcs#1743) in the @rust-lang/lang meeting. There was full consensus that Rust should have a macro to return the function name. Procedurally, this needs to have an RFC (or revive the old one), and an implementation with tests and a feature gate. Other open questions include:

• Bikeshedding the name ;)
• Not breaking if people have a macro named function! already; may need better macro module handling (Tracking issue for "macro naming and modularisation" (RFC #1561) #35896). For instance, we need a test to make sure that a macro using this function! doesn't break if expanded in a file that defines its own macro named function!.
• What happens if you use this in a closure? Should it identify the closure somehow, or the containing named function, or both?

[pietroalbini]

If this needs an RFC, should this PR be closed?

[pietroalbini]

Since this seems to require an RFC and the PR stalled. I'm closing this. Please reopen if that's not the case!

[prasannavl]

@pietroalbini

Since this seems to require an RFC and the PR stalled. I'm closing this. Please reopen if that's not the case!

I think this is rather counter-intuitive: I can understand issues being closed to keep the number of open issues manageable, but in contexts like this, this only encourages opening more. Perhaps, leave issues open for ones that's agreed upon by the community to some extent that needs RFC to proceed to the next? RFC and PRs can get stalled - it's a part of the process. But opening and closing new ones in the same context seems very counter-intuitive to me. It's makes following things much harder.

For instance, this issue already has:
#466
#1719
#35651
#49820

Rather than closing issues aggressively, I think it would be more fruitful to close and re-open/open-new only when the discussion is becoming too long/hard-to-follow or if it's forks into a new context where the previous discussion may not apply.

[pietroalbini]

This is not an issue though, it's a PR, and there is no point in keeping a PR idle for months or possibly years (that RFC is still far away). It's just noise for the triage team, and with the regular changes to the rustc codebase the PR itself will probably need to be changed or even rewritten once the RFC is accepted.