attributes: prepare to release 0.1.9

[hawkw]

0.1.9 (July 8, 2020)

Added

• Support for arbitrary expressions as fields in #[instrument] (attributes: support arbitrary field expressions #672)

Changed

• #[instrument] now emits a compiler warning when ignoring
  unrecognized input (attributes: support arbitrary field expressions #672, attributes: downgrade unrecognized input errors to warnings  #786)

Fixes #785

[hawkw]

It occurs to me that the second change in the changelog, emitting errors for unrecognized input to instrument rather than ignoring it, maybe should be considered a semver breaking change, as it could cause code that previously compiled to no longer compile. However, adding an error for incorrect code that was previously accepted could be considered a "bugfix"...

@carllerche do you have any thoughts on how this interacts with tokio's versioning policies?

[hawkw]

In an ideal world, we would emit warnings rather than errors, and this would definitely not be breaking...but unfortunately, there isn't currently a good way for proc macros to emit warnings.

[LucioFranco]

I think its fine tbh, curious what @davidbarsky thinks too?

[LucioFranco]

How many people do you think are using tracing in such a way that it would affect them rather than help them? (even if its breaking their code)

[hawkw]

How many people do you think are using tracing in such a way that it would affect them rather than help them? (even if its breaking their code)

Hmm. I mean, it's helping everyone, because they may be unaware that their code is actually not doing anything. But, if the incorrect code exists in the wild, it might e.g. break CI builds that were previously passing.

[yaahc]

as it could cause code that previously compiled to no longer compile

this is a pretty critical reason to increment the semver imo. I'm thinking about cases where I've had semver bit me. Most recently on a big project I hadn't touched in a year where it stopped compiling because amethyst or one of its deps fked up semver. I couldn't easily fix the issue other than figuring out the correct exact version or upgrading to the next version of amethyst which was more than I was willing to do so I just gave up trying to play with it and wrote off the codebase as dead. I can see this same issue cropping up if someone has a dependency that stops compiling because of this change, where its not an easy change to their own code to fix.

On the other side, if we do a major semver bump could any of this cause compilation failures if two different versions of this crate are linked in? I recently did a small breaking change bugfix to eyre and almost immediately got a bug report because someone had a crate that exposed color-eyre as part of its interface and then a user bumped their version to the newest one and couldn't figure out why it wouldn't compile anymore.

It seems like the former concern is the only one likely to be an issue for tracing-attributes, so I lean towards calling this a breaking change.

[hawkw]

On the other side, if we do a major semver bump could any of this cause compilation failures if two different versions of this crate are linked in?

This is especially concerning because tracing re-exports tracing-attributes. The hope was that breaking changes to the tracing-attributes crate could be decoupled while allowing users to opt in to the new version of tracing-attributes by depending on it explicitly. We should make sure that works before doing a semver bump --- otherwise, this will have to wait until we've prepared all the necessary breaking changes for tracing.

[hawkw]

If this does end up requiring a semver bump change, we should make sure to also change the behavior with empty fields in instrument as I described in #672 (comment)

One thing that's worth noting is that the current implementation will
generate an empty field when a field name is provided without an =
and a value. This makes sense when only simple fields with literal
values are permitted. However, if we accept arbitrary expressions in the
macro, this is not the ideal behavior --- we would prefer to use the
same local variable shorthand as the function-like tracing macros.
However, changing this now is a breaking change. Any code which uses a
name that doesn't exist in the current scope to declare an empty field
would fail to compile, because it attempts to reference a name that
doesn't exist. Instead, I left a comment noting that this is not the
ideal behavior and it should be changed next time we're ready to break
the proc macros.

[hawkw]

Okay, I've rebased to pick up #786 and updated the changelog. Now, we should emit warnings rather than errors for unrecognized input, meaning that this is no longer a potentially breaking change.