Could something like tokio LocalKey be used to allow and_log_failure to work across scopes on multiple threads? #4
Comments
|
Thanks for the suggestion! We'll need to give some thought on how to support this without incorporating a dependency to Tokio. |
|
It could just be a feature for tokio. I know it's kinda one off, but Tokio so far is the defacto "winner" in the async space right now. |
|
Hmm, maybe something like the instrument combinator from tracing.rs adapted to tests. |
copybara-service bot
pushed a commit
that referenced
this issue
Apr 14, 2023
Previously, an async test annotated with `googletest::test` would not compile because the test content was put in an ordinary closure. Any uses of `.await` inside that closure would generate a compiler error. This changes the `googletest::test` macro implementation to detect that the test is async and adjust the generation accordingly. If the test is async, then no closure is generated, but the test content is placed in an async block. Unfortunately, there does not appear to be a single way to cover both the sync and async cases currently, as explained in the code comments. A further refinement of this approach could possibly address #4. PiperOrigin-RevId: 524288885
copybara-service bot
pushed a commit
that referenced
this issue
Apr 14, 2023
Previously, an async test annotated with `googletest::test` would not compile because the test content was put in an ordinary closure. Any uses of `.await` inside that closure would generate a compiler error. This changes the `googletest::test` macro implementation to detect that the test is async and adjust the generation accordingly. If the test is async, then no closure is generated, but the test content is placed in an async block. Unfortunately, there does not appear to be a single way to cover both the sync and async cases currently, as explained in the code comments. A further refinement of this approach could possibly address #4. PiperOrigin-RevId: 524288885
copybara-service bot
pushed a commit
that referenced
this issue
Apr 14, 2023
Previously, an async test annotated with `googletest::test` would not compile because the test content was put in an ordinary closure. Any uses of `.await` inside that closure would generate a compiler error. This changes the `googletest::test` macro implementation to detect that the test is async and adjust the generation accordingly. If the test is async, then no closure is generated, but the test content is placed in an async block. Unfortunately, there does not appear to be a single way to cover both the sync and async cases currently, as explained in the code comments. A further refinement of this approach could possibly address #4. PiperOrigin-RevId: 524288885
copybara-service bot
pushed a commit
that referenced
this issue
Apr 14, 2023
Previously, an async test annotated with `googletest::test` would not compile because the test content was put in an ordinary closure. Any uses of `.await` inside that closure would generate a compiler error. This changes the `googletest::test` macro implementation to detect that the test is async and adjust the generation accordingly. If the test is async, then no closure is generated, but the test content is placed in an async block. Unfortunately, there does not appear to be a single way to cover both the sync and async cases currently, as explained in the code comments. A further refinement of this approach could possibly address #4. PiperOrigin-RevId: 524288885
copybara-service bot
pushed a commit
that referenced
this issue
Apr 14, 2023
Previously, an async test annotated with `googletest::test` would not compile because the test content was put in an ordinary closure. Any uses of `.await` inside that closure would generate a compiler error. This changes the `googletest::test` macro implementation to detect that the test is async and adjust the generation accordingly. If the test is async, then no closure is generated, but the test content is placed in an async block. Unfortunately, there does not appear to be a single way to cover both the sync and async cases currently, as explained in the code comments. A further refinement of this approach could possibly address #4. PiperOrigin-RevId: 524288885
copybara-service bot
pushed a commit
that referenced
this issue
Apr 14, 2023
Previously, an async test annotated with `googletest::test` would not compile because the test content was put in an ordinary closure. Any uses of `.await` inside that closure would generate a compiler error. This changes the `googletest::test` macro implementation to detect that the test is async and adjust the generation accordingly. If the test is async, then no closure is generated, but the test content is placed in an async block. Unfortunately, there does not appear to be a single way to cover both the sync and async cases currently, as explained in the code comments. A further refinement of this approach could possibly address #4. PiperOrigin-RevId: 524288885
copybara-service bot
pushed a commit
that referenced
this issue
Apr 17, 2023
Previously, an async test annotated with `googletest::test` would not compile because the test content was put in an ordinary closure. Any uses of `.await` inside that closure would generate a compiler error. This changes the `googletest::test` macro implementation to detect that the test is async and adjust the generation accordingly. If the test is async, then no closure is generated, but the test content is placed in an async block. Unfortunately, there does not appear to be a single way to cover both the sync and async cases currently, as explained in the code comments. A further refinement of this approach could possibly address #4. PiperOrigin-RevId: 524288885
copybara-service bot
pushed a commit
that referenced
this issue
Apr 17, 2023
Previously, an async test annotated with `googletest::test` would not compile because the test content was put in an ordinary closure. Any uses of `.await` inside that closure would generate a compiler error. This changes the `googletest::test` macro implementation to detect that the test is async and adjust the generation accordingly. If the test is async, then no closure is generated, but the test content is placed in an async block. Unfortunately, there does not appear to be a single way to cover both the sync and async cases currently, as explained in the code comments. A further refinement of this approach could possibly address #4. PiperOrigin-RevId: 524774676
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://docs.rs/tokio/latest/tokio/task/struct.LocalKey.html
Just a thought
The text was updated successfully, but these errors were encountered: