## Motivation
As discussed in #292:
> A follow-up to remove an explicit dependency on `proc-macro2` would be
> great, though, as it would make it easier to avoid pulling duplicate
> versions of that crate.
## Solution
Remove `proc-macro2` as a direct dependency and replace usages of types
from it accordingly.
- remove `proc-macro2` as a direct dependency
- replace usage of `TokenStream` from `proc-macro2` with `impl ToTokens`
from `quote`
- remove usage of `Span::call_site` as that is used by default for the
`quote!` macro
## Motivation
`tokio` 0.2 introduced a `tokio-macros` crate that uses macro-related
dependencies similar to `tracing-attributes`. Recently, [those
dependencies were updated][1], incorporating breaking changes from those
dependencies. This means that users of `tokio` 0.2 and
`tracing-attributes` will have duplicate dependencies.
[1]: https://github.com/tokio-rs/tokio/pull/1432
## Solution
Update `proc-macro2`, `syn`, and `quote` to version 1, and react to the
breaking changes (mostly in `syn`).
Note that this is currently a naive, compiler-error-driven refactoring
of `tracing-attributes`. Everything appears to be working, but I'm not
sure if there's a better (e.g. more performant) way to use the new
dependencies. Additionally, I noticed that `tokio-macros` dropped having
a direct dependency on `proc-macro2`, and I don't know if
`tracing-attributes` should do the same.
- update `quote`, `syn`, and `proc-macro2` all to version 1
- react to breaking changes in `syn`
Fixes: #270
## Motivation
Some Tracing examples, especially in unstable crates, were written
against earlier versions of `tracing`. They don't always demonstrate
the most idiomatic use of Tracing APIs.
## Solution
This updates the examples to use newer Tracing APIs and syntax. Now, the
examples will demonstrate the preferred idioms.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
`tracing` is built with Rust's 2018 edition, but some examples use
outdated idioms. Ideally, examples would show code using the currently
preferred idioms. This improves clarity, especially for newer Rust
programmers who may not be familiar with the idioms of earlier editions.
## Solution
This branch updates all the examples to use Rust 2018 edition idioms,
and adds `deny` attributes to prevent the use of outdated idioms.
* deny rust 2018 idiom lints in examples
* examples: update to use Rust 2018 idioms
* examples: remove most uses of `extern crate`
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Users have expressed interest in using `tracing` on no_std platforms
with `liballoc`. Now that `tracing-core` supports no_std (see #256),
we can now add no_std support to `tracing` as well.
## Solution
This branch adds `no_std` support to `tracing` by adding a `std`
feature flag (on by default) which can be disabled to use `libcore` +
`liballoc` instead of `libstd`.
When the `std` feature is disabled, `tracing-core` will use
`spin::Once` rather than `std::sync::Once`, and the thread-local
scoped dispatcher will be disabled (since it necessitates a defined OS
threading model, which may not exist on `no_std` platforms).
Some tests, which rely on the thread-local dispatcher, are disabled when
the standard lib is disabled. The alternative is to use
`set_global_default` in those tests, which would necessitate placing
each test in its own separate file. Since the behavior being tested is
otherwise the same regardless of whether or not the standard library is
used, I opted to disable these tests instead.
Refs: #256Closes: #213
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
# 0.1.1 (August 9, 2019)
### Changed
- Using the `#[instrument]` attribute on `async fn`s no longer requires a
feature flag (#258)
### Fixed
- The `#[instrument]` macro now works on generic functions (#262)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Want to be able to use the amazing `#[instrument]` attribute on
functions which have generics/bounds.
## Solution
Add these to the proc macro.
## Motivation
Currently, using `tracing-attributes` with an `async fn` requires a
feature flag, as well as being on a compiler that supports async-await.
This is an unfortunate usability speedbump that is necessary as the Rust
1.34 compiler will fail on any file _containing_ `async` or `await`,
even if they are inside a macro input (such as `quote!`).
## Solution
This branch removes the necessity of feature-flagging async-await
support by constructing `syn::Ident` instances for the "async" and
"await" keywords, rather than quoting them. This means that
`#[instrument]` will now work for `async fn`s on any compiler that
supports async-await, without requiring a feature flag.
I've left the feature flag defined, although it no longer does anything.
Removing it would be a breaking change for code that enables it.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
In order to re-export the `#[instrument]` attribute macro in `tracing`,
it must be released to crates.io. There are some changes that needed to
be made prior to releasing the procedural macro crate.
## Solution
This branch makes the following changes:
- Rename the attribute macro from `trace` to `instrument` (see #246)
- Add support for setting a verbosity level (see #250)
- Add support for setting a target
- Rename the `tracing-proc-macros` crate to `tracing-attributes`
- Add documentation + a README
- Update Cargo.toml metadata
The crate should now be ready to publish and re-export from `tracing`.
Fixes: #246Fixes: #250
Refs: #245
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
