Add a #[must_use] annotation to Span

[radix]

Motivation

I noticed we had some code at work that was creating spans with e.g. info_span!() and not doing anything with the spans. This seems like it should be prevented.

Please let me know if I'm wrong about this and there are useful use-cases for creating and not using Spans and I'll close this PR.

Solution

Add a #[must_use] to tracing::Span.

[radix]

I've updated this PR to target 0.1.x, since that's the version we're on.

I'm not sure what the CI failures are about - they don't seem relevant to my change but maybe I'm missing a subtle implication of my change.

[jplatte]

I've updated this PR to target 0.1.x

Please undo that, as the maintainers have stated in multiple other PRs that they prefer to take care of backporting themselves.

I'm not sure what the CI failures are about

Should be gone after rebasing.

[hds]

If you're still interested in submitting this PR, please rebase onto the main branch (which is equivalent to the email oldv0.1.x branch).

This process has changed recently, so sorry for the conflicting messages.

[hds]

If you're still interested in submitting this PR, please rebase onto the main branch (which is equivalent to the email oldv0.1.x branch).

This process has changed recently, so sorry for the conflicting messages.

Okay. Thinking about this. I'm not sure if it's not a breaking change.

Let me dwell on it a little and ask some experts.

[mladedav]

Not an expert, but for what it's worth, I don't think adding must_use qualifies as a breaking change. At worst, people get new warnings (which they of course can treat as errors) which I don't think is considered as breaking.

[mladedav]

On the other hand, at least this RFC considers that potentially breaking:

Marking functions #[must_use] is a breaking change in certain cases, e.g. if someone is ignoring their result and has the relevant lint (or warnings in general) set to be an error. This is a general problem of improving/expanding lints.

[jplatte]

Yeah, #[deny()] / #[forbid()] is opting out of usual semver guarantees. std adds new warnings (which affects (#[deny(warnings)]) or improves existing ones all the time.