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

backport recent commits from master #2096

Merged
merged 4 commits into from Apr 26, 2022
Merged

backport recent commits from master #2096

merged 4 commits into from Apr 26, 2022

Commits on Apr 26, 2022

  1. core: document the callsite module (#2088)

    Currently, there isn't a lot of documentation explaining what callsites
    and registration are for, and how they work. There's some documentation
    explaining this stuff, but it's all on the `register_callsite` *method*,
    rather than in the `callsite` module itself. We should fix that.
    
    This branch adds new documentation to `tracing-core`'s `callsite`
    module. Hopefully this should shine some light on how this part of
    tracing works.
    
    Thanks to @JamesHallowell for fixing some typos!
    
    Signed-off-by: Eliza Weisman <eliza@buoyant.io>
    hawkw committed Apr 26, 2022
    Configuration menu
    Copy the full SHA
    0e135bc View commit details
    Browse the repository at this point in the history
  2. attributes: remove extra braces around async blocks (#2090)

    ## Motivation
    
    When using an `async` block (as an alternative to `async fn`, e.g. when
    implementing a trait), `#[instrument]` adds extra braces around the
    wrapped `async` block. This causes `rustc` to emit an `unused_braces`
    lint in some cases (usually for single-line `async` blocks, as far as I
    can tell). See #1831 for an example.
    
    ## Solution
    
    Since the `async` block extracted by `AsyncInfo::from_fn` already has
    braces around its statements, there's no need to wrap it with additional
    braces. This updates `gen_block` to remove those extra braces when
    generating the code providing the value of
    `__tracing_instrument_future`.
    
    - [x] add repros for `unused_braces` issue
    - [x] remove extra braces from async blocks
    
    Fixes #1831
    jarrodldavis authored and hawkw committed Apr 26, 2022
    Configuration menu
    Copy the full SHA
    a313f5d View commit details
    Browse the repository at this point in the history
  3. attributes: permit setting parent span via #[instrument(parent = …)] (

    #2091)
    
    This PR extends the `#[instrument]` attribute to accept an optionally
    `parent = …` argument that provides an explicit parent to the generated
    `Span`.
    
    ## Motivation
    
    This PR resolves #2021 and partially resolves #879. (It only partly
    resolves #879 in that it only provides a mechanism for specifying an
    explicit parent, but *not* for invoking `follows_from`.)
    
    ## Solution
    
    This PR follows the implementation strategy articulated by @hawkw:
    #879 (comment).
    The user-provided value to the `parent` argument may be any expression,
    and this expression is provided directly to the invocation of
    [`span!`](https://tracing.rs/tracing/macro.span.html).
    jswrenn authored and hawkw committed Apr 26, 2022
    Configuration menu
    Copy the full SHA
    bead0db View commit details
    Browse the repository at this point in the history
  4. attributes: permit #[instrument(follows_from = …)] (#2093)

    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.
    jswrenn authored and hawkw committed Apr 26, 2022
    Configuration menu
    Copy the full SHA
    0ac9995 View commit details
    Browse the repository at this point in the history