Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

attributes, mock: permit #[instrument(follows_from = …)] #2093

Merged
merged 5 commits into from
Apr 26, 2022

Conversation

jswrenn
Copy link
Contributor

@jswrenn jswrenn commented Apr 25, 2022

This PR extends the #[instrument] attribute to accept an optional follows_from = … argument that supplies any number of Span::follows_from relationships to the generated Span.

Motivation

This PR resolves #879.

Solution

This PR largely follows the implementation strategy articulated by @hawkw: #879 (comment)

In that comment, @hawkw suggests taking one of two approaches:

  1. each follows_from relationship is supplied with a distinct follows_from argument
  2. the follows_from argument is provided once, and its value is a list of indirect causes

I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime.

This addition is complemented by changes to tracing-mock to permit making follows_from assertions for testing purposes.

This permits assertions that a cause indirectly `follows_from` a
consequence.
The optional `follows_from` argument allows users to specify any
number of `Span::follows_from` relationships. The value to this
argument is an expression of type:
  `impl IntoIterator<Item = impl Into<Option<Id>>>`

Fixes: tokio-rs#879
@jswrenn jswrenn requested review from hawkw, davidbarsky and a team as code owners April 25, 2022 23:11
Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for working on this, the change seems good to me, but i had some minor suggestions on the documentation.

tracing-attributes/src/lib.rs Show resolved Hide resolved
tracing-attributes/src/lib.rs Outdated Show resolved Hide resolved
Explicitly document the type requirements of `follows_from`.
The argument to `follows_from` is evaluated after the generated span is
created, but before the span is entered. Consequently, this example
should NOT produce a cyclic `follows_from` relationship:

  #[instrument(follows_from = [&Span::current()])]
  fn follows_from_current() {}
@hawkw hawkw enabled auto-merge (squash) April 26, 2022 20:37
Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, this looks good to me! thanks for the test additions as well!

@hawkw hawkw merged commit 14eff63 into tokio-rs:master Apr 26, 2022
hawkw pushed a commit that referenced this pull request Apr 26, 2022
This PR extends the `#[instrument]` attribute to accept an optional
`follows_from = …` argument that supplies any number of
`Span::follows_from` relationships to the generated `Span`.

## Motivation

This PR resolves #879.

## Solution

This PR largely follows the implementation strategy articulated by
@hawkw:
#879 (comment)

In that comment, @hawkw suggests taking one of two approaches:
1. each `follows_from` relationship is supplied with a distinct
   `follows_from` argument
2. the `follows_from` argument is provided once, and its value is a
   **list** of indirect causes

I take the second approach, since it is slightly more flexible: it
allows for the number of indirect causes to vary at runtime.

This addition is complemented by changes to `tracing-mock` to permit
making `follows_from` assertions for testing purposes.
hawkw pushed a commit that referenced this pull request Apr 26, 2022
This PR extends the `#[instrument]` attribute to accept an optional
`follows_from = …` argument that supplies any number of
`Span::follows_from` relationships to the generated `Span`.

## Motivation

This PR resolves #879.

## Solution

This PR largely follows the implementation strategy articulated by
@hawkw:
#879 (comment)

In that comment, @hawkw suggests taking one of two approaches:
1. each `follows_from` relationship is supplied with a distinct
   `follows_from` argument
2. the `follows_from` argument is provided once, and its value is a
   **list** of indirect causes

I take the second approach, since it is slightly more flexible: it
allows for the number of indirect causes to vary at runtime.

This addition is complemented by changes to `tracing-mock` to permit
making `follows_from` assertions for testing purposes.
hawkw pushed a commit that referenced this pull request Apr 26, 2022
This PR extends the `#[instrument]` attribute to accept an optional
`follows_from = …` argument that supplies any number of
`Span::follows_from` relationships to the generated `Span`.

## Motivation

This PR resolves #879.

## Solution

This PR largely follows the implementation strategy articulated by
@hawkw:
#879 (comment)

In that comment, @hawkw suggests taking one of two approaches:
1. each `follows_from` relationship is supplied with a distinct
   `follows_from` argument
2. the `follows_from` argument is provided once, and its value is a
   **list** of indirect causes

I take the second approach, since it is slightly more flexible: it
allows for the number of indirect causes to vary at runtime.

This addition is complemented by changes to `tracing-mock` to permit
making `follows_from` assertions for testing purposes.
hawkw pushed a commit that referenced this pull request Apr 26, 2022
This PR extends the `#[instrument]` attribute to accept an optional
`follows_from = …` argument that supplies any number of
`Span::follows_from` relationships to the generated `Span`.

## Motivation

This PR resolves #879.

## Solution

This PR largely follows the implementation strategy articulated by
@hawkw:
#879 (comment)

In that comment, @hawkw suggests taking one of two approaches:
1. each `follows_from` relationship is supplied with a distinct
   `follows_from` argument
2. the `follows_from` argument is provided once, and its value is a
   **list** of indirect causes

I take the second approach, since it is slightly more flexible: it
allows for the number of indirect causes to vary at runtime.

This addition is complemented by changes to `tracing-mock` to permit
making `follows_from` assertions for testing purposes.
hawkw pushed a commit that referenced this pull request Apr 26, 2022
This PR extends the `#[instrument]` attribute to accept an optional
`follows_from = …` argument that supplies any number of
`Span::follows_from` relationships to the generated `Span`.

## Motivation

This PR resolves #879.

## Solution

This PR largely follows the implementation strategy articulated by
@hawkw:
#879 (comment)

In that comment, @hawkw suggests taking one of two approaches:
1. each `follows_from` relationship is supplied with a distinct
   `follows_from` argument
2. the `follows_from` argument is provided once, and its value is a
   **list** of indirect causes

I take the second approach, since it is slightly more flexible: it
allows for the number of indirect causes to vary at runtime.

This addition is complemented by changes to `tracing-mock` to permit
making `follows_from` assertions for testing purposes.
hawkw pushed a commit that referenced this pull request Apr 26, 2022
This PR extends the `#[instrument]` attribute to accept an optional
`follows_from = …` argument that supplies any number of
`Span::follows_from` relationships to the generated `Span`.

## Motivation

This PR resolves #879.

## Solution

This PR largely follows the implementation strategy articulated by
@hawkw:
#879 (comment)

In that comment, @hawkw suggests taking one of two approaches:
1. each `follows_from` relationship is supplied with a distinct
   `follows_from` argument
2. the `follows_from` argument is provided once, and its value is a
   **list** of indirect causes

I take the second approach, since it is slightly more flexible: it
allows for the number of indirect causes to vary at runtime.

This addition is complemented by changes to `tracing-mock` to permit
making `follows_from` assertions for testing purposes.
hawkw added a commit that referenced this pull request Apr 26, 2022
# 0.1.21 (April 26, 2022)

This release adds support for setting explicit parent and follows-from
spans in the `#[instrument]` attribute.

### Added

- `#[instrument(follows_from = ...)]` argument for setting one or more
  follows-from span ([#2093])
- `#[instrument(parent = ...)]` argument for overriding the generated
  span's parent ([#2091])

### Fixed

- Extra braces around `async` blocks in expanded code (causes a Clippy
  warning) ([#2090])
- Broken documentation links ([#2068], [#2077])

Thanks to @jarrodldavis, @ben0x539, and new contributor @jswrenn for
contributing to this release!

[#2093]: #2093
[#2091]: #2091
[#2090]: #2090
[#2077]: #2077
[#2068]: #2068
hawkw added a commit that referenced this pull request Apr 27, 2022
# 0.1.21 (April 26, 2022)

This release adds support for setting explicit parent and follows-from
spans in the `#[instrument]` attribute.

### Added

- `#[instrument(follows_from = ...)]` argument for setting one or more
  follows-from span ([#2093])
- `#[instrument(parent = ...)]` argument for overriding the generated
  span's parent ([#2091])

### Fixed

- Extra braces around `async` blocks in expanded code (causes a Clippy
  warning) ([#2090])
- Broken documentation links ([#2068], [#2077])

Thanks to @jarrodldavis, @ben0x539, and new contributor @jswrenn for
contributing to this release!

[#2093]: #2093
[#2091]: #2091
[#2090]: #2090
[#2077]: #2077
[#2068]: #2068
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request May 22, 2024
This PR extends the `#[instrument]` attribute to accept an optional
`follows_from = …` argument that supplies any number of
`Span::follows_from` relationships to the generated `Span`.

## Motivation

This PR resolves tokio-rs#879.

## Solution

This PR largely follows the implementation strategy articulated by
@hawkw:
tokio-rs#879 (comment)

In that comment, @hawkw suggests taking one of two approaches:
1. each `follows_from` relationship is supplied with a distinct
   `follows_from` argument
2. the `follows_from` argument is provided once, and its value is a
   **list** of indirect causes

I take the second approach, since it is slightly more flexible: it
allows for the number of indirect causes to vary at runtime.

This addition is complemented by changes to `tracing-mock` to permit
making `follows_from` assertions for testing purposes.
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request May 22, 2024
# 0.1.21 (April 26, 2022)

This release adds support for setting explicit parent and follows-from
spans in the `#[instrument]` attribute.

### Added

- `#[instrument(follows_from = ...)]` argument for setting one or more
  follows-from span ([tokio-rs#2093])
- `#[instrument(parent = ...)]` argument for overriding the generated
  span's parent ([tokio-rs#2091])

### Fixed

- Extra braces around `async` blocks in expanded code (causes a Clippy
  warning) ([tokio-rs#2090])
- Broken documentation links ([tokio-rs#2068], [tokio-rs#2077])

Thanks to @jarrodldavis, @ben0x539, and new contributor @jswrenn for
contributing to this release!

[tokio-rs#2093]: tokio-rs#2093
[tokio-rs#2091]: tokio-rs#2091
[tokio-rs#2090]: tokio-rs#2090
[tokio-rs#2077]: tokio-rs#2077
[tokio-rs#2068]: tokio-rs#2068
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow specifying parent and/or follows_from of spans made by #[instrument]
2 participants