#[instrument] attribute is not IDE friendly
#1633
Labels
Comments
hawkw
added
crate/attributes
|
A patch so tracing's proc-macro pastes the block as tokenstream when parsing fails: cynecx@81fde81. |
Thank you! Would you be interested in opening a PR for this change? |
hawkw
pushed a commit
that referenced
this issue
Oct 17, 2021
## Motivation Recent `rust-analyzer` versions enabled automatic expansion of proc macro attributes by default. This is a problem with `#[instrument]`, because it currently produces a `compile_error!` when parsing the code inside the `#[instrument]`ed function fails, and *discards* those tokens. This means that if the `#[instrument]` attribute is placed on a function whose implementation fails to parse, recent versions of `rust-analyzer` will no longer be able to display diagnostics for those errors. In some cases, this can also break autocompletion. ## Solution This branch changes `#[instrument]` to always expand to the tokens contained in the `#[instrument]`ed function body, regardless of whether or not they could be parsed successfully. Now, an error is only emitted when the `#[instrument]` attribute *itself* could not be parsed. Since the instrumented function is always expanded, any errors within that function can be displayed properly by `rust-analyzer`. Fixes #1633.
hawkw
pushed a commit
that referenced
this issue
Oct 22, 2021
## Motivation Recent `rust-analyzer` versions enabled automatic expansion of proc macro attributes by default. This is a problem with `#[instrument]`, because it currently produces a `compile_error!` when parsing the code inside the `#[instrument]`ed function fails, and *discards* those tokens. This means that if the `#[instrument]` attribute is placed on a function whose implementation fails to parse, recent versions of `rust-analyzer` will no longer be able to display diagnostics for those errors. In some cases, this can also break autocompletion. ## Solution This branch changes `#[instrument]` to always expand to the tokens contained in the `#[instrument]`ed function body, regardless of whether or not they could be parsed successfully. Now, an error is only emitted when the `#[instrument]` attribute *itself* could not be parsed. Since the instrumented function is always expanded, any errors within that function can be displayed properly by `rust-analyzer`. Fixes #1633.
hawkw
pushed a commit
that referenced
this issue
Oct 22, 2021
## Motivation Recent `rust-analyzer` versions enabled automatic expansion of proc macro attributes by default. This is a problem with `#[instrument]`, because it currently produces a `compile_error!` when parsing the code inside the `#[instrument]`ed function fails, and *discards* those tokens. This means that if the `#[instrument]` attribute is placed on a function whose implementation fails to parse, recent versions of `rust-analyzer` will no longer be able to display diagnostics for those errors. In some cases, this can also break autocompletion. ## Solution This branch changes `#[instrument]` to always expand to the tokens contained in the `#[instrument]`ed function body, regardless of whether or not they could be parsed successfully. Now, an error is only emitted when the `#[instrument]` attribute *itself* could not be parsed. Since the instrumented function is always expanded, any errors within that function can be displayed properly by `rust-analyzer`. Fixes #1633.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Feature Request
Crates
tracing-attributesMotivation
In short this is a problem with how syn and attributes using syn implement failure, as these crates tend to just discard the entire attributed item on a parsing failure, replacing it with a
compile_error!invocation. This has the side effect that when typing inside an item, a user may momentarily create invalid syntax causing the item to be fully discarded resulting in loss of IDE features as the item now effectively does not exist in the file until this syntax error has been fixed.This is becoming a bigger problem now as Rust-Analyzer enabled attribute expansion by default starting this week which causes users to run into this problem.
Proposal
A simple solution to this problem is to change the attribute such that when it errors, it re-emits the original item with the
compile_error!invocation, that way IDEs will still see the item even if the attribute fails causing IDE features to continue to function.Sidenote: This will fix the general problem, but if the attribute introduces new usable items inside the item which could benefit from IDE features like completions for example, they will of course not always be visible to these features with just this fix. An ideal fix would be to make the attribute do parsing with recovery in such cases if required or emit the expected output on a best effort basis even with invalid or unexpected input.
The text was updated successfully, but these errors were encountered: