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: backport changes since October 1st, 2023 #2794

Merged
merged 9 commits into from
Nov 7, 2023

Conversation

davidbarsky
Copy link
Member

Backport of last month's commits from master.

(The set of commits I needed to backport were generated using patcher ~/Developer/tracing "2023-10-01 00:00:00" --destination="v0.1.x. I'm happy with that CLI.)

bburnichon and others added 6 commits November 6, 2023 19:14
Currently, link points to an outdated version.

Make the link point to latest released version
## Motivation

`NonBlocking` from `tracing-appender` wraps a writer and requires that
writer to implement `Sync` (among other bounds). However it is not clear
why this bound is necessary in first place: this writer is sent to a
dedicated thread and never used directly concurrently.

#1934 demonstrates that it is a real problem for some people. Also at my
current work we hit this issue as well when a third-party writer did not
implement `Sync`. Our workaround was to wrap that writer in our own type
and manually implement `Send` and `Sync` for it. Needless to say that it
is more a hack than a proper solution.

## Solution

Remove `Sync` bound in relevant places. Yep, that simple. Probably
having it in first place was just an oversight.

Closes #1934
These docs were updated (in response to #1669), but the "or equal to"
phrase should have been moved to the other case.

Fixes: #1993

## Motivation

When these docs were updated in response to #1669, they were updated
incompletely (a level that is equal to a filter is _enabled_, not
_disabled_) and therefore remained incorrect.

## Solution

The docs were updated, moving the "or equal to" phrase to the other
case.
When a user has a crate named `core`, it can cause issues
because our crates import from `::core::*`. Now we are
importing from `$crate::__macro_support::*` and there will
be no more name clashes.
The `from_env` and `try_from_env` methods on the builder had the same documentation. This change updates their docs to correctly describe their difference in behavior.


## Motivation

Make the docs more clear, so that users need not look at the source to understand the difference between these two functions.

## Solution

Updated the docs

Co-authored-by: Eliza Weisman <eliza@buoyant.io>
When using a function annotated with `#[instrument]` it parses the
parameters of the function and records them either using `Value` or
using `std::fmt::Debug`. There were a few types that implement `Value`
but were missing the RecordTypes array. Added them + a unit test for a
single one.

Fixed: #2775
@davidbarsky davidbarsky requested review from a team, yaahc and hawkw as code owners November 7, 2023 00:23
@davidbarsky davidbarsky changed the title David/backport 11 06 2023 chore: backport changes since October 1st, 2023 Nov 7, 2023
@davidbarsky davidbarsky force-pushed the david/backport-11-06-2023 branch 2 times, most recently from 459b8bb to f9c577d Compare November 7, 2023 01:31
davidbarsky added a commit that referenced this pull request Nov 7, 2023
davidbarsky added a commit that referenced this pull request Nov 7, 2023
@hawkw hawkw merged commit 1dc1e6a into v0.1.x Nov 7, 2023
52 checks passed
@hawkw hawkw deleted the david/backport-11-06-2023 branch November 7, 2023 21:37
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request Feb 14, 2024
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.

6 participants