{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":165289175,"defaultBranch":"master","name":"tracing","ownerLogin":"tokio-rs","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2019-01-11T18:17:15.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/20248544?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1713277647.0","currentOid":""},"activityList":{"items":[{"before":"8b6dca65d837d0baa92b10e51a8b48206209021d","after":"51d7d9e17fc9210afeb28988cfd54d2a04c3b843","ref":"refs/heads/hds/missed-register-callsite-fix-v0.1.x","pushedAt":"2024-04-16T20:52:01.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"core: fix missed `register_callsite` error\n\nThere are 2 triggers which will cause a subscriber to receive a call to\n`Subscriber::register_callsite` for a specific callsite.\n1. The first time the event or span at that callsite is executed.\n2. When a new subscriber is added or removed (for example, calls to\n   `set_default` or `with_default`)\n\nIt is trigger (2) that will cause a new subscriber to receive\n`Subscriber::register_callsite` for all the callsites which had already\nbeen registered before it became active.\n\nWhen a callsite is registered for trigger (1), the callsite starts in\nstate `UNREGISTERED`.\n\nThe first thread to encounter the callsite will transition it to\n`REGISTERING` and determine the overall interest for the callsite by\nregistering with all known dispatchers (which will call into\n`Subscriber::register_callsite`).\n\nOnce that is complete, the callsite is added to the list of all known\ncallsites and its state is transitioned to `REGISTERED`.\n\nis (re)built for all known dispatchers. The callsite starts in state\n`UNREGISTERED`. The  This calls down into\n`Subscriber::register_callsite` for each subscriber. Once that is\ncomplete, the callsite is added to the global list of known callsites.\n\nWhile the callsite interest is being rebuilt, other threads that\nencounter the callsite will be given `Interest::sometimes()` until the\nregistration is complete. However, if a new subscriber is added during\nthis window, all the interest for all callsites will be rebuilt, but\nbecause the new callsite (in state `REGISTERING`) won't be included\nbecause it isn't yet in the global list of callsites.\n\nThis can cause a case where that new subscriber being added won't\nreceive `Subscriber::register_callsite` before it receives the subsequent\ncall to `Subscriber::event` or `Subscriber::new_span`.\n\nThe documentation on [Registering Callsites] is not very explicit on\nthis point, but it does suggest that `Subscriber::register_callsite`\nwill be called before the call to either `Subscriber::event` or\n`Subscriber::new_span`, and the current behavior can break this implicit\ncontract.\n\n[Registering Callsites]: https://docs.rs/tracing-core/0.1.32/tracing_core/callsite/index.html#registering-callsites\n\nThis change swaps the order of rebuilding the callsite interest and\nadding the callsite to the global list so that the callsite gets pushed\nfirst, avoiding this window in which a subscriber won't get a call to\n`register_callsite`.\n\nAs such, a callsite may have its interest read before it is set. In this\ncase, the existing implementation will return `Interest::sometimes()`\nfor the `DefaultCallsite` implementation. Other implementations (outside\nof the `tracing` project) may perform this differently, but in this\ncase, there is no documented guarantee regarding the ordering.\n\nA regression test is included which provokes the race condition 100% of\nthe time before the changes in this fix.\n\nFixes: #2743","shortMessageHtmlLink":"core: fix missed <code>register_callsite</code> error"}},{"before":"f8db87948d3dfea1fd31211abe8c197cb2b19bf0","after":"8b6dca65d837d0baa92b10e51a8b48206209021d","ref":"refs/heads/hds/missed-register-callsite-fix-v0.1.x","pushedAt":"2024-04-16T17:37:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"core: fix missed `register_callsite` error\n\nThere are 2 triggers which will cause a subscriber to receive a call to\n`Subscriber::register_callsite` for a specific callsite.\n1. The first time the event or span at that callsite is executed.\n2. When a new subscriber is added or removed (for example, calls to\n   `set_default` or `with_default`)\n\nIt is trigger (2) that will cause a new subscriber to receive\n`Subscriber::register_callsite` for all the callsites which had already\nbeen registered before it became active.\n\nWhen a callsite is registered for trigger (1), the callsite starts in\nstate `UNREGISTERED`.\n\nThe first thread to encounter the callsite will transition it to\n`REGISTERING` and determine the overall interest for the callsite by\nregistering with all known dispatchers (which will call into\n`Subscriber::register_callsite`).\n\nOnce that is complete, the callsite is added to the list of all known\ncallsites and its state is transitioned to `REGISTERED`.\n\nis (re)built for all known dispatchers. The callsite starts in state\n`UNREGISTERED`. The  This calls down into\n`Subscriber::register_callsite` for each subscriber. Once that is\ncomplete, the callsite is added to the global list of known callsites.\n\nWhile the callsite interest is being rebuilt, other threads that\nencounter the callsite will be given `Interest::sometimes()` until the\nregistration is complete. However, if a new subscriber is added during\nthis window, all the interest for all callsites will be rebuilt, but\nbecause the new callsite (in state `REGISTERING`) won't be included\nbecause it isn't yet in the global list of callsites.\n\nThis can cause a case where that new subscriber being added won't\nreceive `Subscriber::register_callsite` before it receives the subsequent\ncall to `Subscriber::event` or `Subscriber::new_span`.\n\nThe documentation on [Registering Callsites] is not very explicit on\nthis point, but it does suggest that `Subscriber::register_callsite`\nwill be called before the call to either `Subscriber::event` or\n`Subscriber::new_span`, and the current behavior can break this implicit\ncontract.\n\n[Registering Callsites]: https://docs.rs/tracing-core/0.1.32/tracing_core/callsite/index.html#registering-callsites\n\nThis change swaps the order of rebuilding the callsite interest and\nadding the callsite to the global list so that the callsite gets pushed\nfirst, avoiding this window in which a subscriber won't get a call to\n`register_callsite`.\n\nAs such, a callsite may have its interest read before it is set. In this\ncase, the existing implementation will return `Interest::sometimes()`\nfor the `DefaultCallsite` implementation. Other implementations (outside\nof the `tracing` project) may perform this differently, but in this\ncase, there is no documented guarantee regarding the ordering\nThis is the same","shortMessageHtmlLink":"core: fix missed <code>register_callsite</code> error"}},{"before":null,"after":"f8db87948d3dfea1fd31211abe8c197cb2b19bf0","ref":"refs/heads/hds/missed-register-callsite-fix-v0.1.x","pushedAt":"2024-04-16T14:27:27.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"core: fix missed `register_callsite` error\n\nThere are 2 triggers which will cause a subscriber to receive a call to\n`Subscriber::register_callsite` for a specific callsite.\n1. The first time the event or span at that callsite is executed.\n2. When a new subscriber is added or removed (for example, calls to\n   `set_default` or `with_default`)\n\nIt is trigger (2) that will cause a new subscriber to receive\n`Subscriber::register_callsite` for all the callsites which had already\nbeen registered before it became active.\n\nWhen a callsite is registered for trigger (1), the callsite starts in\nstate `UNREGISTERED`.\n\nThe first thread to encounter the callsite will transition it to\n`REGISTERING` and determine the overall interest for the callsite by\nregistering with all known dispatchers (which will call into\n`Subscriber::register_callsite`).\n\nOnce that is complete, the callsite is added to the list of all known\ncallsites and its state is transitioned to `REGISTERED`.\n\nis (re)built for all known dispatchers. The callsite starts in state\n`UNREGISTERED`. The  This calls down into\n`Subscriber::register_callsite` for each subscriber. Once that is\ncomplete, the callsite is added to the global list of known callsites.\n\nWhile the callsite interest is being rebuilt, other threads that\nencounter the callsite will be given `Interest::sometimes()` until the\nregistration is complete. However, if a new subscriber is added during\nthis window, all the interest for all callsites will be rebuilt, but\nbecause the new callsite (in state `REGISTERING`) won't be included\nbecause it isn't yet in the global list of callsites.\n\nThis can cause a case where that new subscriber being added won't\nreceive `Subscriber::register_callsite` before it receives the subsequent\ncall to `Subscriber::event` or `Subscriber::new_span`.\n\nThe documentation on [Registering Callsites] is not very explicit on\nthis point, but it does suggest that `Subscriber::register_callsite`\nwill be called before the call to either `Subscriber::event` or\n`Subscriber::new_span`, and the current behavior can break this implicit\ncontract.\n\n[Registering Callsites]: https://docs.rs/tracing-core/0.1.32/tracing_core/callsite/index.html#registering-callsites\n\nThis change swaps the order of rebuilding the callsite interest and\nadding the callsite to the global list so that the callsite gets pushed\nfirst, avoiding this window in which a subscriber won't get a call to\n`register_callsite`.\n\nAs such, a callsite may have its interest read before it is set. In this\ncase, the existing implementation will return `Interest::sometimes()`\nfor the `DefaultCallsite` implementation. Other implementations (outside\nof the `tracing` project) may perform this differently, but in this\ncase, there is no documented guarantee regarding the ordering\nThis is the same","shortMessageHtmlLink":"core: fix missed <code>register_callsite</code> error"}},{"before":"571c5305bc4ab0e076c0fe5000a420caf595d87a","after":"36bf06310c143e24fb4761dcb7e88a46c99b053c","ref":"refs/heads/v0.1.x","pushedAt":"2024-03-12T01:29:33.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"davidbarsky","name":"David Barsky","path":"/davidbarsky","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2067774?s=80&v=4"},"commit":{"message":"attributes: extract match scrutinee (#2880)\n\nOn clippy version 1.76.0 this gives a warning, extracting the\r\nscrutinee to a variable fixes this.\r\n\r\nFixes: #2876","shortMessageHtmlLink":"attributes: extract match scrutinee (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2135234985\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2880\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2880/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2880\">#2880</a>)"}},{"before":"0e3577f6f3995b92accee21e0737c25ef0f1953c","after":"908cc432a5994f6e17c8f36e13c217dc40085704","ref":"refs/heads/master","pushedAt":"2024-03-01T20:59:00.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"tracing: fix event macros with constant field names in the first position (#2883)\n\n\r\n## Motivation\r\n\r\nConst argumetns in `level!` macros do not work when in the first\r\nposition.\r\n\r\nThis also seems to have fixed #2748 where literals for fields names like\r\n`info!(\"foo\" = 2)` could not be used outside the `event!` macro.\r\n\r\n\r\nFixes #2837\r\nFixes #2738\r\n\r\n## Solution\r\n\r\nPrevisously, `level!($(args:tt))` was forwarded to `event!(target: ...,\r\nlevel: ..., { $(args:tt) })` but the added curly braces seem to have\r\nprevented the `event` macro from correctly understanding the arguments\r\nand it tried to pass them to `format!`.\r\n\r\nWith this change there may have some performance impact when expanding\r\nthe macros in most cases where the braces could have been added as it\r\nwill take one more step.\r\n\r\nThese are the two relevant `event!` blocks I believe, the new tests used\r\nto expand to the first one (with empty fields), now they expand to the\r\nlatter:\r\n```\r\n    (target: $target:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => (\r\n        $crate::event!(\r\n            target: $target,\r\n            $lvl,\r\n            { message = $crate::__macro_support::format_args!($($arg)+), $($fields)* }\r\n        )\r\n    );\r\n    (target: $target:expr, $lvl:expr, $($arg:tt)+ ) => (\r\n        $crate::event!(target: $target, $lvl, { $($arg)+ })\r\n    );\r\n```","shortMessageHtmlLink":"tracing: fix event macros with constant field names in the first posi…"}},{"before":"0e4a4bef5e4e8b7435e9e50e8bae25afba25d7d7","after":"571c5305bc4ab0e076c0fe5000a420caf595d87a","ref":"refs/heads/v0.1.x","pushedAt":"2024-03-01T20:53:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"chore: fixes for clippy changes in Rust 1.74 (#2814)\n\nWith the release of Rust 1.74, there are some new or modified clippy\nlints that need adaption in the code.\n\nThe main change was the removal of the `private_in_public`.\nhttps://rust-lang.github.io/rfcs/2145-type-privacy.html\n\nThen two more changes were required, in one case to adhere a lint and\nthe other to allow it. When talking about what an \"application\" needs to\ndo when setting up `tracing-error`, it makes sense to include `fn\nmain()` in the doctest, even though the lint recommends against it.\n; Conflicts:\n;\texamples/examples/map-traced-error.rs","shortMessageHtmlLink":"chore: fixes for clippy changes in Rust 1.74 (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2005215418\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2814\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2814/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2814\">#2814</a>)"}},{"before":"045b22ecd90318447b7973dc31baa118f812ec89","after":"0e3577f6f3995b92accee21e0737c25ef0f1953c","ref":"refs/heads/master","pushedAt":"2024-02-16T19:48:38.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"macros: Fix non-simple macro usage without message (#2879)\n\nIf something like `warn!(?foo)` and `warn!(name: \"foo\", ?foo)` works, then `warn!(name: \"foo\", target: \"foo_events\", ?foo)` should arguably also work. Before this change the more complicated variants of the macros however required a message argument, due to the usage of the `+` specifier in the macro definitions. This commit changes the `+` (1 or more) to `*` (0 or more), which matches how the `field` tokens are used in the simpler variants of the macro.","shortMessageHtmlLink":"macros: Fix non-simple macro usage without message (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2134202062\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2879\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2879/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2879\">#2879</a>)"}},{"before":"baeba47cdaac9ed32d5ef3f6f1d7b0cc71ffdbdf","after":"045b22ecd90318447b7973dc31baa118f812ec89","ref":"refs/heads/master","pushedAt":"2024-02-15T21:54:04.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"macros: Fix missing field prefixes (#2878)\n\n## Motivation\r\n\r\nIn the simple macro cases with e.g. only \"name\" or only \"target\" these\r\nprefixes exist, but for the more complicated cases like \"name + target\"\r\nthe prefixes were not piped through and silently ignored. This led to\r\nthe compiler complaining about `Value` not being implemented despite the\r\nusage of the `?` or `%` prefixes:\r\n\r\n<img width=\"1056\" alt=\"Bildschirmfoto 2024-02-14 um 12 38 00\"\r\nsrc=\"https://github.com/tokio-rs/tracing/assets/141300/f8b0b1af-fe66-41d8-9a08-2ecba2d67f9e\">\r\n\r\n\r\n## Solution\r\n\r\nThis change adds the missing prefixes to the `$($k)` tokens, like they\r\nalready exist for the simple cases mentioned above.","shortMessageHtmlLink":"macros: Fix missing field prefixes (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2134173536\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2878\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2878/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2878\">#2878</a>)"}},{"before":null,"after":"25368a341ea06ecfafc4ed09da7b2466f92ac9fe","ref":"refs/heads/jonhoo-patch-2","pushedAt":"2024-02-08T20:53:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jonhoo","name":"Jon Gjengset","path":"/jonhoo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/176295?s=80&v=4"},"commit":{"message":"Fix errant backtick in WeakDispatch docs\n\nNote: this error is not present on `master`.","shortMessageHtmlLink":"Fix errant backtick in WeakDispatch docs"}},{"before":null,"after":"99953e0bc5e6e22f9a2a31954aa4be771dfa201b","ref":"refs/heads/jonhoo-patch-1","pushedAt":"2024-02-08T20:48:23.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jonhoo","name":"Jon Gjengset","path":"/jonhoo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/176295?s=80&v=4"},"commit":{"message":"Exit spans the same way we enter them\n\nWe call `inner.enter` before we call `layer.on_enter`, so it feels wrong\r\nto then call `inner.exit` before we call `layer.on_exit`. Either the\r\ninner's view of the span wraps the outer's view of the span, or the\r\nother way around.","shortMessageHtmlLink":"Exit spans the same way we enter them"}},{"before":"c6bedbe2725830c1e78cbcdb9168de69c98e42fc","after":"0e4a4bef5e4e8b7435e9e50e8bae25afba25d7d7","ref":"refs/heads/v0.1.x","pushedAt":"2024-01-26T22:14:00.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"attributes: change order of async and unsafe modifier (#2864)\n\nWhen using `#[tracing::instrument]` and the `async unsafe` modifiers\nthe generated function read `unsafe async fn`, which is wrong. Corrected\nthe order and added a test.\n\nFixes: #2576\n\nSigned-off-by: Gabriel Goller <g.goller@proxmox.com>","shortMessageHtmlLink":"attributes: change order of async and unsafe modifier (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2102174544\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2864\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2864/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2864\">#2864</a>)"}},{"before":"b461897c78a63faa8c88304b6276122564e43aaa","after":"baeba47cdaac9ed32d5ef3f6f1d7b0cc71ffdbdf","ref":"refs/heads/master","pushedAt":"2024-01-25T17:21:29.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"use const `thread_local`s when possible (#2838)\n\nThis results in a substantial performance improvement,\nand is compatible with our MSRV. \n\nSigned-off-by: Alex Saveau <saveau.alexandre@gmail.com>\nCo-authored-by: Eliza Weisman <eliza@buoyant.io>","shortMessageHtmlLink":"use const <code>thread_local</code>s when possible (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2055909075\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2838\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2838/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2838\">#2838</a>)"}},{"before":"aa50d0e61373bb4af1ba567963e396dd2a54eb22","after":"b461897c78a63faa8c88304b6276122564e43aaa","ref":"refs/heads/master","pushedAt":"2024-01-25T04:29:56.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"davidbarsky","name":"David Barsky","path":"/davidbarsky","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2067774?s=80&v=4"},"commit":{"message":"docs: Update README.md with correct link to tracing-etw (#2861)","shortMessageHtmlLink":"docs: Update README.md with correct link to tracing-etw (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2099535400\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2861\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2861/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2861\">#2861</a>)"}},{"before":"335380a6b17e733899b95e0524ad03581861cbc2","after":"aa50d0e61373bb4af1ba567963e396dd2a54eb22","ref":"refs/heads/master","pushedAt":"2024-01-20T18:40:06.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"docs: fix typo \"synchonous\" => \"synchronous\" (#2850)\n\n## Motivation\r\n\r\nFix typo \"synchonous\" => \"synchronous\" in the crate level documentation.","shortMessageHtmlLink":"docs: fix typo \"synchonous\" =&gt; \"synchronous\" (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2073390482\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2850\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2850/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2850\">#2850</a>)"}},{"before":"d4ca988252211b12e3beccfa6b029064ede1d6dc","after":"335380a6b17e733899b95e0524ad03581861cbc2","ref":"refs/heads/master","pushedAt":"2024-01-15T19:43:42.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"chore: Fix spelling (#2854)","shortMessageHtmlLink":"chore: Fix spelling (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2081309697\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2854\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2854/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2854\">#2854</a>)"}},{"before":"07b490067c0e2af61f48a3d2afb85a20ab70ba95","after":"d4ca988252211b12e3beccfa6b029064ede1d6dc","ref":"refs/heads/master","pushedAt":"2024-01-11T20:28:41.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"journald: make level mappings configurable (#2824)\n\nThis allows to manually map tracing levels to journald levels.\r\n\r\nIt seems that @little-dude, who started the original PR, doesn't have\r\ntime to finish this, so I picked it up.  Reapplied the changes to the\r\nnewest master branch and fixed the latest comments/issues.\r\n\r\nThis will also fix/close:\r\n\r\nCloses #2649\r\nCloses #2661\r\nCloses #2347 (the original pr)","shortMessageHtmlLink":"journald: make level mappings configurable (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2029486504\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2824\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2824/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2824\">#2824</a>)"}},{"before":"b632be0e9882d038aa7a08de0a2b2458bda53303","after":null,"ref":"refs/heads/taiki-e/checkout","pushedAt":"2024-01-06T21:10:06.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"taiki-e","name":"Taiki Endo","path":"/taiki-e","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/43724913?s=80&v=4"}},{"before":"00ca2dc116d11b450cdc9c6306aaf59f6b7ed34a","after":"07b490067c0e2af61f48a3d2afb85a20ab70ba95","ref":"refs/heads/master","pushedAt":"2024-01-06T21:10:05.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"taiki-e","name":"Taiki Endo","path":"/taiki-e","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/43724913?s=80&v=4"},"commit":{"message":"chore(ci): update actions/checkout action to v4 (#2845)","shortMessageHtmlLink":"chore(ci): update actions/checkout action to v4 (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2068630902\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2845\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2845/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2845\">#2845</a>)"}},{"before":"3370d4018e289548dae16a0a8e1e2ef945951eaf","after":"b632be0e9882d038aa7a08de0a2b2458bda53303","ref":"refs/heads/taiki-e/checkout","pushedAt":"2024-01-06T19:28:56.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"taiki-e","name":"Taiki Endo","path":"/taiki-e","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/43724913?s=80&v=4"},"commit":{"message":"Merge branch 'master' into taiki-e/checkout","shortMessageHtmlLink":"Merge branch 'master' into taiki-e/checkout"}},{"before":"bac25085fcea68ca30b8e19b8981fbd689f53735","after":"00ca2dc116d11b450cdc9c6306aaf59f6b7ed34a","ref":"refs/heads/master","pushedAt":"2024-01-06T19:28:12.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hawkw","name":"Eliza Weisman","path":"/hawkw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2796466?s=80&v=4"},"commit":{"message":"examples: suppress false positive clippy lint (#2846)\n\nSigned-off-by: Alex Saveau <saveau.alexandre@gmail.com>","shortMessageHtmlLink":"examples: suppress false positive clippy lint (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2068764807\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2846\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2846/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2846\">#2846</a>)"}},{"before":null,"after":"3370d4018e289548dae16a0a8e1e2ef945951eaf","ref":"refs/heads/taiki-e/checkout","pushedAt":"2024-01-06T13:29:48.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"taiki-e","name":"Taiki Endo","path":"/taiki-e","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/43724913?s=80&v=4"},"commit":{"message":"chore(ci): update actions/checkout action to v4","shortMessageHtmlLink":"chore(ci): update actions/checkout action to v4"}},{"before":"10fd046ae45069a4ceca4678d6ad5c221dce93c3","after":"937e44d5b6d09842896f7b5ec236f7283f54cc3c","ref":"refs/heads/hds/mock-fix-expect-parent","pushedAt":"2023-11-29T13:41:23.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"Merge branch 'master' into hds/mock-fix-expect-parent","shortMessageHtmlLink":"Merge branch 'master' into hds/mock-fix-expect-parent"}},{"before":"1f423f4f74acfb2b825ce415bef250954ec0e147","after":null,"ref":"refs/heads/hds/clippy-1-74","pushedAt":"2023-11-26T15:34:18.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"davidbarsky","name":"David Barsky","path":"/davidbarsky","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2067774?s=80&v=4"}},{"before":"8ba80ae82371638aa749436e4f284b65adf9ff90","after":"bac25085fcea68ca30b8e19b8981fbd689f53735","ref":"refs/heads/master","pushedAt":"2023-11-26T15:34:17.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"davidbarsky","name":"David Barsky","path":"/davidbarsky","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2067774?s=80&v=4"},"commit":{"message":"chore: fixes for clippy changes in Rust 1.74 (#2814)\n\nWith the release of Rust 1.74, there are some new or modified clippy\r\nlints that need adaption in the code.\r\n\r\nThe main change was the removal of the `private_in_public`.\r\nhttps://rust-lang.github.io/rfcs/2145-type-privacy.html\r\n\r\nThen two more changes were required, in one case to adhere a lint and\r\nthe other to allow it. When talking about what an \"application\" needs to\r\ndo when setting up `tracing-error`, it makes sense to include `fn\r\nmain()` in the doctest, even though the lint recommends against it.","shortMessageHtmlLink":"chore: fixes for clippy changes in Rust 1.74 (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2005215418\" data-permission-text=\"Title is private\" data-url=\"https://github.com/tokio-rs/tracing/issues/2814\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/tokio-rs/tracing/pull/2814/hovercard\" href=\"https://github.com/tokio-rs/tracing/pull/2814\">#2814</a>)"}},{"before":null,"after":"1f423f4f74acfb2b825ce415bef250954ec0e147","ref":"refs/heads/hds/clippy-1-74","pushedAt":"2023-11-21T21:55:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"chore: fixes for clippy changes in Rust 1.74\n\nWith the release of Rust 1.74, there are some new or modified clippy\nlints that need adaption in the code.\n\nThe main change was the removal of the `private_in_public`.\nhttps://rust-lang.github.io/rfcs/2145-type-privacy.html\n\nThen two more changes were required, in one case to adhere a lint and\nthe other to allow it. When talking about what an \"application\" needs to\ndo when setting up `tracing-error`, it makes sense to include `fn\nmain()` in the doctest, even though the lint recommends against it.","shortMessageHtmlLink":"chore: fixes for clippy changes in Rust 1.74"}},{"before":"7e9044b422de9e63ef0578444fc181cc82f07938","after":null,"ref":"refs/heads/davidbarsky/prepare-release-oct-12-2023","pushedAt":"2023-11-21T20:17:00.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"davidbarsky","name":"David Barsky","path":"/davidbarsky","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2067774?s=80&v=4"}},{"before":"dd2c874dda96f6233d11c882e57f3674606cbacd","after":"10fd046ae45069a4ceca4678d6ad5c221dce93c3","ref":"refs/heads/hds/mock-fix-expect-parent","pushedAt":"2023-11-20T14:23:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"mock: correct contextual/explicit parent assertions\n\nWhen recording the parent of an event or span, the `MockCollector`\ntreats an explicit parent of `None` (i.e. an event or span that is an\nexplicit root) in the same way as if there is no explicit root. This\nleads to it picking up the contextual parent or treating the event or\nspan as a contextual root.\n\nThis change refactors the recording of the parent to use `is_contextual`\nto distinguish whether or not an explicit parent has been specified. The\nactual parent is also written into a `Parent` enum so that the expected\nand actual values can be compared in a more explicit way.\n\nAdditionally, the `Parent` struct has been moved into its own module and\nthe check behavior has been fixed. The error message has also been\nunified across all cases.\n\nGiven the number of different cases involved in checking parents,\nseparate integration tests have been added to `tracing-mock`\nspecifically for testing all the positive and negative cases when\nasserting on the parents of events and spans.\n\nThere were two tests in `tracing-attributes` which specified both an\nexplicit and a contextual parent. This behavior was never intended to\nwork as all events and spans are either contextual or not. The tests\nhave been corrected to only expect one of the two.\n\nFixes: #2440","shortMessageHtmlLink":"mock: correct contextual/explicit parent assertions"}},{"before":"f9f949617be833cb9da742bc47b0cb37b47fbf4b","after":"dd2c874dda96f6233d11c882e57f3674606cbacd","ref":"refs/heads/hds/mock-fix-expect-parent","pushedAt":"2023-11-20T13:04:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"mock: correct contextual/explicit parent assertions\n\nWhen recording the parent of an event or span, the `MockCollector`\ntreats an explicit parent of `None` (i.e. an event or span that is an\nexplicit root) in the same way as if there is no explicit root. This\nleads to it picking up the contextual parent or treating the event or\nspan as a contextual root.\n\nThis change refactors the recording of the parent to use `is_contextual`\nto distinguish whether or not an explicit parent has been specified. The\nactual parent is also written into a `Parent` enum so that the expected\nand actual values can be compared in a more explicit way.\n\nAdditionally, the `Parent` struct has been moved into its own module and\nthe check behavior has been fixed. The error message has also been\nunified across all cases.\n\nGiven the number of different cases involved in checking parents,\nseparate integration tests have been added to `tracing-mock`\nspecifically for testing all the positive and negative cases when\nasserting on the parents of events and spans.\n\nThere were two tests in `tracing-attributes` which specified both an\nexplicit and a contextual parent. This behavior was never intended to\nwork as all events and spans are either contextual or not. The tests\nhave been corrected to only expect one of the two.\n\nFixes: #2440","shortMessageHtmlLink":"mock: correct contextual/explicit parent assertions"}},{"before":"717b7918d1e6cbc6826327c583939c058a36cea8","after":"f9f949617be833cb9da742bc47b0cb37b47fbf4b","ref":"refs/heads/hds/mock-fix-expect-parent","pushedAt":"2023-11-20T13:01:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"mock: correct contextual/explicit parent assertions\n\nWhen recording the parent of an event or span, the `MockCollector`\ntreats an explicit parent of `None` (i.e. an event or span that is an\nexplicit root) in the same way as if there is no explicit root. This\nleads to it picking up the contextual parent or treating the event or\nspan as a contextual root.\n\nThis change refactors the recording of the parent to use `is_contextual`\nto distinguish whether or not an explicit parent has been specified. The\nactual parent is also written into a `Parent` enum so that the expected\nand actual values can be compared in a more explicit way.\n\nAdditionally, the `Parent` struct has been moved into its own module and\nthe check behavior has been fixed. The error message has also been\nunified across all cases.\n\nGiven the number of different cases involved in checking parents,\nseparate integration tests have been added to `tracing-mock`\nspecifically for testing all the positive and negative cases when\nasserting on the parents of events and spans.\n\nThere were two tests in `tracing-attributes` which specified both an\nexplicit and a contextual parent. This behavior was never intended to\nwork as all events and spans are either contextual or not. The tests\nhave been corrected to only expect one of the two.\n\nFixes: #2440","shortMessageHtmlLink":"mock: correct contextual/explicit parent assertions"}},{"before":"a722e89b41fe99d798d2e2dad737135d939f9d0d","after":"717b7918d1e6cbc6826327c583939c058a36cea8","ref":"refs/heads/hds/mock-fix-expect-parent","pushedAt":"2023-11-20T07:55:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"hds","name":"Hayden Stainsby","path":"/hds","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89589?s=80&v=4"},"commit":{"message":"mock: correct contextual/explicit parent assertions\n\nWhen recording the parent of an event or span, the `MockCollector`\ntreats an explicit parent of `None` (i.e. an event or span that is an\nexplicit root) in the same way as if there is no explicit root. This\nleads to it picking up the contextual parent or treating the event or\nspan as a contextual root.\n\nThis change refactors the recording of the parent to use `is_contextual`\nto distinguish whether or not an explicit parent has been specified. The\nactual parent is also written into a `Parent` enum so that the expected\nand actual values can be compared in a more explicit way.\n\nAdditionally, the `Parent` struct has been moved into its own module and\nthe check behavior has been fixed. The error message has also been\nunified across all cases.\n\nGiven the number of different cases involved in checking parents,\nseparate integration tests have been added to `tracing-mock`\nspecifically for testing all the positive and negative cases when\nasserting on the parents of events and spans.\n\nThere were two tests in `tracing-attributes` which specified both an\nexplicit and a contextual parent. This behavior was never intended to\nwork as all events and spans are either contextual or not. The tests\nhave been corrected to only expect one of the two.\n\nFixes: #2440","shortMessageHtmlLink":"mock: correct contextual/explicit parent assertions"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEMm75gwA","startCursor":null,"endCursor":null}},"title":"Activity · tokio-rs/tracing"}