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

chore: revert #943 #986

Closed
wants to merge 1 commit into from
Closed

Conversation

davidbarsky
Copy link
Member

This commit appears to break Tower.

@davidbarsky davidbarsky requested review from hawkw and a team as code owners September 24, 2020 22:53
@davidbarsky davidbarsky changed the title Revert 943 chore: revert #943 Sep 24, 2020
@hawkw hawkw closed this in #987 Sep 25, 2020
hawkw added a commit that referenced this pull request Sep 25, 2020
## Motivation

In PR #943, the construction of `ValueSet`s for events and spans was
moved out of the code expanded at the callsite and into a closure, in
order to reduce the amount of assembly generated in functions containing
tracing macros. However, this introduced an accidental breaking change
for some dependent crates. Borrowing values inside a closure meant that
when a field of a struct, array, or tuple was used as a field value, the
closure must borrow the _entire_ struct, array, or tuple, rather than
the individual field. This broke code where another unrelated field of
that struct, array, or tuple would then be mutably borrowed or moved
elsewhere. 

## Solution

This branch fixes the breaking change by moving `ValueSet` construction
back out of a closure and into the code expanded at the callsite. This
_does_ regress the amount of assembly generated a bit: a function
containing a single `event!` macro generates 32 instructions in release
mode on master, and after this change, it generates 83 instructions.
However, this is better than reverting PR #943 entirely, which generates
103 instructions for the same function. This change allows us to
continue to benefit from *some* of the changes made in #943, although we
no longer can benefit from the most significant one.

Rather than trying to further optimize the macro expanded code now, I
think we should wait for the `ValueSet` rework that will land in
`tracing` 0.2, where we could potentially generate significantly less
code by virtue of constructing a `ValueSet` with a much simpler array
literal (no `FieldSet` iteration required).

Fixes #954 
Closes #986

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
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.

1 participant