attributes: downgrade unrecognized input errors to warnings #786
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
davidbarsky
approved these changes
Jul 7, 2020
|
Just wanted to make sure that folks think the warnings in the screenshot are clear enough before I go ahead and merge this (cc @yaahc @LucioFranco) |
|
I think its fine as is but it might be clearer if the error msg is: |
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw
added a commit
that referenced
this pull request
Jul 8, 2020
Added - **attributes**: Support for arbitrary expressions as fields in `#[instrument]` (#672) - **attributes**: `#[instrument]` now emits a compiler warning when ignoring unrecognized input (#672, #786) - Improved documentation on using `tracing` in async code (#769) Changed - Updated `tracing-core` dependency to 0.1.11 Fixed - **macros**: Excessive monomorphization in macros, which could lead to longer compilation times (#787) - **log**: Compiler warnings in macros when `log` or `log-always` features are enabled (#753) - Compiler error when `tracing-core/std` feature is enabled but `tracing/std` is not (#760) Thanks to @nagisa for contributing to this release!
hawkw
added a commit
that referenced
this pull request
Jul 8, 2020
### Added - **attributes**: Support for arbitrary expressions as fields in `#[instrument]` (#672) - **attributes**: `#[instrument]` now emits a compiler warning when ignoring unrecognized input (#672, #786) - Improved documentation on using `tracing` in async code (#769) ### Changed - Updated `tracing-core` dependency to 0.1.11 ### Fixed - **macros**: Excessive monomorphization in macros, which could lead to longer compilation times (#787) - **log**: Compiler warnings in macros when `log` or `log-always` features are enabled (#753) - Compiler error when `tracing-core/std` feature is enabled but `tracing/std` is not (#760) Thanks to @nagisa, and everyone who contributed to the new `tracing-core` and `tracing-attributes` versions, for contributing to this release!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
In PR #672, the
#[instrument]attribute was rewritten to use a customsynparser rather than usingsyn::AttributeArgs. This was primarilyto allow the use of arbitrary expressions as fields, but it had the side
benefit of also allowing more sophisticated error reporting. In
particular, we were able to replace the previous behavior of silently
ignoring unknown input with a compiler error, which has been requested a
few times (see #772 and #727). However, emitting a compiler error for
inputs that we previously allowed (even if they did nothing) is
technically a breaking change --- see
#773 (comment) and
following comments. This means that the other new features added in #672
cannot be released until we release
tracing-subscriber0.2.Solution
This branch avoids the breaking change by downgrading these errors to
warnings. However, it isn't currently possible to emit a warning from a
proc-macro on stable --- the
proc_macro::DiagnosticAPI which wouldallow this requires a nightly feature. This branch hacks around this by
generating a fake deprecated item with for each unrecognized token in
the input, emitting the skipped item's parse error as the deprecation's
note, and "using" the deprecated item.The deprecated warning is used here rather than other code that will
emit compiler warnings, because it gives us a way to customize the
warning output (via the
notefield). I've tried to make it fairlyobvious that this is not a "real" deprecation. Sample output looks like
this:
Fixes #727
Fixes #772
Signed-off-by: Eliza Weisman eliza@elizas.website