-
Notifications
You must be signed in to change notification settings - Fork 663
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
ergonomics: the error message when trying to instrument const fn is hard to read #2414
Comments
Hmm, yeah, it looks like those are the errors that are emitted by rustc when the code generated by the This should hopefully be pretty straightforward to do, so I'm going to tag this as a "good first issue" if anyone's interested in working on it! |
I'll take a look at this now! Is there a way to assign myself to this issue? |
## Motivation The `#[instrument]` macro cannot be used on `const fn`s, because the generated code will perform runtime tracing behavior. However, when adding the attribute to a `const fn`, the compiler errors generated currently are somewhat unclear (see #2414). It would be better if we generated a less verbose error that simply states that `#[instrument]` is not supported on `const fn`s. ## Solution This branch changes the `#[instrument]` macro to detect when the annotated function is a `const fn`, and emit a simpler, more descritpive error message. The new error simply states that the `#[instrument]` attribute cannot be used on `const fn`s, and should be much less confusing to the user. Fixes #2414
## Motivation The `#[instrument]` macro cannot be used on `const fn`s, because the generated code will perform runtime tracing behavior. However, when adding the attribute to a `const fn`, the compiler errors generated currently are somewhat unclear (see #2414). It would be better if we generated a less verbose error that simply states that `#[instrument]` is not supported on `const fn`s. ## Solution This branch changes the `#[instrument]` macro to detect when the annotated function is a `const fn`, and emit a simpler, more descritpive error message. The new error simply states that the `#[instrument]` attribute cannot be used on `const fn`s, and should be much less confusing to the user. Fixes #2414
## Motivation The `#[instrument]` macro cannot be used on `const fn`s, because the generated code will perform runtime tracing behavior. However, when adding the attribute to a `const fn`, the compiler errors generated currently are somewhat unclear (see #2414). It would be better if we generated a less verbose error that simply states that `#[instrument]` is not supported on `const fn`s. ## Solution This branch changes the `#[instrument]` macro to detect when the annotated function is a `const fn`, and emit a simpler, more descritpive error message. The new error simply states that the `#[instrument]` attribute cannot be used on `const fn`s, and should be much less confusing to the user. Fixes #2414
Bug Report
I tried using
#[instrument]
on aconst fn
in a rush in a larger codebase which didn't use tracing before, and got a slightly convoluted compile error message. Once I stopped being angry at my code, it clicked to me why logging in const context would be kind of difficult, but the message doesn't make it super easy.I think it would be nice if the attribute macro outright rejected instrumenting const functions?
I looked for similar issues, but I suppose I'm first.
Version
Platform
Crates
tracing-attributes
, I thinkDescription
I got a minimal reproduction like this,
cargo new --lib a
,cargo add tracing
,Then if you try to compile it:
Thanks for the crate and your time
The text was updated successfully, but these errors were encountered: