Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A macro to get the current function name. #2818

Open
wants to merge 6 commits into
base: master
from

Conversation

@Lokathor
Copy link

Lokathor commented Nov 15, 2019

rendered

text/0000-fn_name_macro.md Outdated Show resolved Hide resolved
# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

Use of the `function!` macro expands to the compiler's internal name for the function. This will generally be the name that the user wrote into the file but in the case of a closure or similar it will be something like the function's name with a unique suffix.

This comment has been minimized.

Copy link
@kennytm

kennytm Nov 15, 2019

Member

What about a closure in a static?

static F: &(dyn Fn() -> &'static str + Sync) = &|| "1";

(the fully-qualified name is currently playground::F::{{closure}})

This comment has been minimized.

Copy link
@Lokathor

Lokathor Nov 15, 2019

Author

@eddyb know this one (i hope)

@comex

This comment has been minimized.

Copy link

comex commented Nov 15, 2019

👍

Pie-in-the-sky: It would be nice to have a more flexible feature where you could have a function automatically receive its caller's file/line/function name/etc., like C++ recently added with std::source_location (although the design C++ picked is terrible). But of course there's no need for that to block the current RFC.

@Lokathor

This comment has been minimized.

Copy link
Author

Lokathor commented Nov 15, 2019

That actually was requested earlier today: #2815

@CryZe

This comment has been minimized.

Copy link

CryZe commented Nov 15, 2019

It would be nice to have a more flexible feature where you could have a function automatically receive its caller's file/line/function name/etc.

@comex This is already being implemented rust-lang/rust#65881

text/0000-fn_name_macro.md Outdated Show resolved Hide resolved
text/0000-fn_name_macro.md Show resolved Hide resolved
text/0000-fn_name_macro.md Outdated Show resolved Hide resolved
text/0000-fn_name_macro.md Outdated Show resolved Hide resolved
For debug information about what's happening within the program there's several useful macros that you might use. One of them is the `function!` macro, which expands to the name of the current function. If used outside of a function it causes a compilation error.

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

This comment has been minimized.

Copy link
@Centril

Centril Nov 15, 2019

Member

This section needs some elaboration to consider the various cases (e.g. like the one @kennytm raised) and give examples of code and what the result is.

Also, looking at the implementation of module_path! in libsyntax_ext https://github.com/rust-lang/rust/blob/9e8c4e6fb1c952048fb823e59f4c9c6487bf9a58/src/libsyntax_ext/source_util.rs#L65-L73 it looks like the information is readily available. In this case however, the information is not available in cx or reachable fields. Some elaboration on the implementation would be good. cc @petrochenkov since they are the most likely T-compiler reviewer for this RFC. Also, this probably has little to do with "debuginfo" -- that's a different part of the compiler that comes into play much later in the compilation process.

text/0000-fn_name_macro.md Outdated Show resolved Hide resolved
text/0000-fn_name_macro.md Show resolved Hide resolved
text/0000-fn_name_macro.md Show resolved Hide resolved
text/0000-fn_name_macro.md Outdated Show resolved Hide resolved
@Centril

This comment has been minimized.

Copy link
Member

Centril commented Nov 15, 2019

Who is going to implement this RFC by the way? I think we should have someone available to do that, with mentoring if necessary (if so a mentor is required, e.g. @petrochenkov), before accepting the RFC.

@da-x

This comment has been minimized.

Copy link
Member

da-x commented Nov 15, 2019

I have a reference implementation of this feature.

https://github.com/da-x/rust/tree/function-macro-1.38.0

It's working, but would probably need some changes to conform to the RFC.

@Centril

This comment has been minimized.

Copy link
Member

Centril commented Nov 15, 2019

https://github.com/da-x/rust/tree/function-macro-1.38.0

Hmm; it feels fairly invasive to add &Option<ast::Path> in so many places. Looking over that, I think something like item_path!() which is the concatenation of the module_path!() as well as e.g. StructName::function_name would be less invasive and strictly more general.

@da-x

This comment has been minimized.

Copy link
Member

da-x commented Nov 15, 2019

@Centril I agree regarding having &Option<ast::Path> added in the internal API, and so I've originally also had a change to extend ExtCtxt with a new field instead. However 1) it's for a much earlier rustc version and 2) it uses Rc as in the new Option<Rc<ast::Path>> field which I opt to avoid. Need to see how it fits into the scheme of things now.

@comex

This comment has been minimized.

Copy link

comex commented Nov 15, 2019

@comex This is already being implemented rust-lang/rust#65881

What! Now that's the kind of pleasant surprise that comes rarely.

Hmm... but if that is already being implemented, might it make sense to not add a new macro, but instead just add the function name to Location?

It seems like Location::caller() is already enough to get you the current location – making it equivalent to file!()/line!()/etc. – if the current function is not #[track_caller]. But we should probably add something that always gets the current location even if the current function is #[track_caller]; I'll comment in the tracking issue.

On the other hand, it may be worth adding a macro just to avoid confusing people who see the macros but don't know about Location.

Lokathor and others added 4 commits Nov 16, 2019
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
@Lokathor

This comment has been minimized.

Copy link
Author

Lokathor commented Nov 16, 2019

Updated based on current feedback.

I'm extremely convinced by the item_path!() idea, to the point where if Centril had simply suggested it yesterday instead of today I wouldn't have even opened this RFC.

# Prior art
[prior-art]: #prior-art
* C99 has a `__func__` pre-processor macro that expands to the current funciton name. [link](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1642.html)

This comment has been minimized.

Copy link
@jonas-schievink

jonas-schievink Nov 17, 2019

Member

(Luckily) This is not a pre-processor macro, just a predefined identifier provided by the C compiler

@joshtriplett

This comment has been minimized.

Copy link
Member

joshtriplett commented Nov 20, 2019

I'm in favor of item_path! as well, as a generalization of this that seems quite useful.

@Lokathor

This comment has been minimized.

Copy link
Author

Lokathor commented Nov 20, 2019

This time you write it Josh ;3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.