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.

Sign up for GitHub

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

Jump to bottom

Generate less dead code for async block return type hint #2709

Merged
merged 3 commits into from
Sep 5, 2023
Merged

Generate less dead code for async block return type hint #2709

merged 3 commits into from
Sep 5, 2023

Conversation

kornelski
Copy link
Contributor

Motivation

#[tracing::instrument] uses unreachable!() macro which needlessly expands to panicking and formatting code. It only needs any ! type.

Solution

loop {} works just as well for a ! type, and it crates less work for the compiler. The code is truly unreachable, so the message would never be useful. Rust used to be concerned about semantics of empty loops in LLVM, but this has been solved.

@kornelski kornelski requested review from hawkw, davidbarsky and a team as code owners September 4, 2023 12:53
hawkw
hawkw approved these changes Sep 5, 2023
View reviewed changes
Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great, looks good to me! thank you!

@hawkw hawkw enabled auto-merge (squash) September 5, 2023 17:28
@hawkw hawkw merged commit 683cc8a into tokio-rs:master Sep 5, 2023
56 checks passed
@kornelski kornelski deleted the cheap-never branch September 8, 2023 22:39
davidbarsky pushed a commit that referenced this pull request Sep 26, 2023
@kornelski @davidbarsky
attributes: generate less dead code for async block return type hint (#…
82ed54b 
…2709)

## Motivation

`#[tracing::instrument]` uses `unreachable!()` macro which needlessly
expands to panicking and formatting code. It only needs any `!` type.

## Solution

`loop {}` works just as well for a `!` type, and it crates less work for
the compiler. The code is truly unreachable, so the message would never
be useful. Rust used to be concerned about semantics of empty loops in
LLVM, but this [has been solved](https://reviews.llvm.org/D85393).
@davidbarsky davidbarsky mentioned this pull request Sep 26, 2023
Merged
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
@kornelski @davidbarsky
attributes: generate less dead code for async block return type hint (#…
44f7471 
…2709)

## Motivation

`#[tracing::instrument]` uses `unreachable!()` macro which needlessly
expands to panicking and formatting code. It only needs any `!` type.

## Solution

`loop {}` works just as well for a `!` type, and it crates less work for
the compiler. The code is truly unreachable, so the message would never
be useful. Rust used to be concerned about semantics of empty loops in
LLVM, but this [has been solved](https://reviews.llvm.org/D85393).
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
@kornelski @davidbarsky
attributes: generate less dead code for async block return type hint (#…
a818b96 
…2709)

## Motivation

`#[tracing::instrument]` uses `unreachable!()` macro which needlessly
expands to panicking and formatting code. It only needs any `!` type.

## Solution

`loop {}` works just as well for a `!` type, and it crates less work for
the compiler. The code is truly unreachable, so the message would never
be useful. Rust used to be concerned about semantics of empty loops in
LLVM, but this [has been solved](https://reviews.llvm.org/D85393).
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
@kornelski @davidbarsky
attributes: generate less dead code for async block return type hint (#…
5de9ec7 
…2709)

## Motivation

`#[tracing::instrument]` uses `unreachable!()` macro which needlessly
expands to panicking and formatting code. It only needs any `!` type.

## Solution

`loop {}` works just as well for a `!` type, and it crates less work for
the compiler. The code is truly unreachable, so the message would never
be useful. Rust used to be concerned about semantics of empty loops in
LLVM, but this [has been solved](https://reviews.llvm.org/D85393).
davidbarsky pushed a commit that referenced this pull request Sep 27, 2023
@kornelski @davidbarsky
attributes: generate less dead code for async block return type hint (#…
02044dd 
…2709)

## Motivation

`#[tracing::instrument]` uses `unreachable!()` macro which needlessly
expands to panicking and formatting code. It only needs any `!` type.

## Solution

`loop {}` works just as well for a `!` type, and it crates less work for
the compiler. The code is truly unreachable, so the message would never
be useful. Rust used to be concerned about semantics of empty loops in
LLVM, but this [has been solved](https://reviews.llvm.org/D85393).
davidbarsky pushed a commit that referenced this pull request Sep 29, 2023
@kornelski @davidbarsky
attributes: generate less dead code for async block return type hint (#…
b658b1f 
…2709)

## Motivation

`#[tracing::instrument]` uses `unreachable!()` macro which needlessly
expands to panicking and formatting code. It only needs any `!` type.

## Solution

`loop {}` works just as well for a `!` type, and it crates less work for
the compiler. The code is truly unreachable, so the message would never
be useful. Rust used to be concerned about semantics of empty loops in
LLVM, but this [has been solved](https://reviews.llvm.org/D85393).
hawkw pushed a commit that referenced this pull request Oct 1, 2023
@kornelski @hawkw
attributes: generate less dead code for async block return type hint (#…
df6793f 
…2709)

## Motivation

`#[tracing::instrument]` uses `unreachable!()` macro which needlessly
expands to panicking and formatting code. It only needs any `!` type.

## Solution

`loop {}` works just as well for a `!` type, and it crates less work for
the compiler. The code is truly unreachable, so the message would never
be useful. Rust used to be concerned about semantics of empty loops in
LLVM, but this [has been solved](https://reviews.llvm.org/D85393).
hawkw pushed a commit that referenced this pull request Oct 13, 2023
@davidbarsky
chore: prepare tracing-attributes 0.1.27 (#2756)
d34dcab 
# 0.1.27 (October 13, 2023)

### Changed

- Bump minimum version of proc-macro2 to 1.0.60 (#2732)
- Generate less dead code for async block return type hint (#2709)

### Fixed

- Fix a compilation error in `#[instrument]` when the `"log"`
  feature is enabled (#2599)
hawkw pushed a commit that referenced this pull request Oct 13, 2023
@davidbarsky @hawkw
chore: prepare tracing-attributes 0.1.27 (#2756)
2502f19 
# 0.1.27 (October 13, 2023)

### Changed

- Bump minimum version of proc-macro2 to 1.0.60 (#2732)
- Generate less dead code for async block return type hint (#2709)

### Fixed

- Fix a compilation error in `#[instrument]` when the `"log"`
  feature is enabled (#2599)
hawkw pushed a commit that referenced this pull request Oct 13, 2023
@davidbarsky @hawkw
chore: prepare tracing 0.1.39 (#2755)
4b99457 
# 0.1.39 (October 12, 2023)

This release adds several additional features to the `tracing` macros.
In addition, it updates the `tracing-core` dependency to
[v0.1.32][core-0.1.32] and the `tracing-attributes` dependency to
[v0.1.27][attrs-0.1.27].

### Added

- Allow constant field names in macros ([#2617])
- Allow setting event names in macros ([#2699])
- **core**: Allow `ValueSet`s of any length ([#2508])

### Changed

- `tracing-attributes`: updated to [0.1.27][attrs-0.1.27]
- `tracing-core`: updated to [0.1.32][core-0.1.32]
- **attributes**: Bump minimum version of proc-macro2 to 1.0.60
  ([#2732])
-  **attributes**: Generate less dead code for async block return type
   hint ([#2709])

### Fixed

- Use fully qualified names in macros for items exported from std
  prelude ([#2621], [#2757])
- **attributes**: Allow [`clippy::let_with_type_underscore`] in
  macro-generated code ([#2609])
- **attributes**: Allow `unknown_lints` in macro-generated code
  ([#2626])
- **attributes**: Fix a compilation error in `#[instrument]` when the
  `"log"` feature is enabled ([#2599])

### Documented

- Add `axum-insights` to relevant crates. ([#2713])
- Fix link to RAI pattern crate documentation ([#2612])
- Fix docs typos and warnings ([#2581])
- Add `clippy-tracing` to related crates ([#2628])
- Add `tracing-cloudwatch` to related crates ([#2667])
- Fix deadlink to `tracing-etw` repo ([#2602])

[#2617]: #2617
[#2699]: #2699
[#2508]: #2508
[#2621]: #2621
[#2713]: #2713
[#2581]: #2581
[#2628]: #2628
[#2667]: #2667
[#2602]: #2602
[#2626]: #2626
[#2757]: #2757
[#2732]: #2732
[#2709]: #2709
[#2599]: #2599
[`let_with_type_underscore`]: http://rust-lang.github.io/rust-clippy/rust-1.70.0/index.html#let_with_type_underscore
[attrs-0.1.27]:
    https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.27
[core-0.1.32]:
    https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.32
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request May 22, 2024
@davidbarsky @kaffarell
chore: prepare tracing-attributes 0.1.27 (tokio-rs#2756)
aa934b7 
# 0.1.27 (October 13, 2023)

### Changed

- Bump minimum version of proc-macro2 to 1.0.60 (tokio-rs#2732)
- Generate less dead code for async block return type hint (tokio-rs#2709)

### Fixed

- Fix a compilation error in `#[instrument]` when the `"log"`
  feature is enabled (tokio-rs#2599)
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request May 22, 2024
@davidbarsky @kaffarell
chore: prepare tracing 0.1.39 (tokio-rs#2755)
4003892 
# 0.1.39 (October 12, 2023)

This release adds several additional features to the `tracing` macros.
In addition, it updates the `tracing-core` dependency to
[v0.1.32][core-0.1.32] and the `tracing-attributes` dependency to
[v0.1.27][attrs-0.1.27].

### Added

- Allow constant field names in macros ([tokio-rs#2617])
- Allow setting event names in macros ([tokio-rs#2699])
- **core**: Allow `ValueSet`s of any length ([tokio-rs#2508])

### Changed

- `tracing-attributes`: updated to [0.1.27][attrs-0.1.27]
- `tracing-core`: updated to [0.1.32][core-0.1.32]
- **attributes**: Bump minimum version of proc-macro2 to 1.0.60
  ([tokio-rs#2732])
-  **attributes**: Generate less dead code for async block return type
   hint ([tokio-rs#2709])

### Fixed

- Use fully qualified names in macros for items exported from std
  prelude ([tokio-rs#2621], [tokio-rs#2757])
- **attributes**: Allow [`clippy::let_with_type_underscore`] in
  macro-generated code ([tokio-rs#2609])
- **attributes**: Allow `unknown_lints` in macro-generated code
  ([tokio-rs#2626])
- **attributes**: Fix a compilation error in `#[instrument]` when the
  `"log"` feature is enabled ([tokio-rs#2599])

### Documented

- Add `axum-insights` to relevant crates. ([tokio-rs#2713])
- Fix link to RAI pattern crate documentation ([tokio-rs#2612])
- Fix docs typos and warnings ([tokio-rs#2581])
- Add `clippy-tracing` to related crates ([tokio-rs#2628])
- Add `tracing-cloudwatch` to related crates ([tokio-rs#2667])
- Fix deadlink to `tracing-etw` repo ([tokio-rs#2602])

[tokio-rs#2617]: tokio-rs#2617
[tokio-rs#2699]: tokio-rs#2699
[tokio-rs#2508]: tokio-rs#2508
[tokio-rs#2621]: tokio-rs#2621
[tokio-rs#2713]: tokio-rs#2713
[tokio-rs#2581]: tokio-rs#2581
[tokio-rs#2628]: tokio-rs#2628
[tokio-rs#2667]: tokio-rs#2667
[tokio-rs#2602]: tokio-rs#2602
[tokio-rs#2626]: tokio-rs#2626
[tokio-rs#2757]: tokio-rs#2757
[tokio-rs#2732]: tokio-rs#2732
[tokio-rs#2709]: tokio-rs#2709
[tokio-rs#2599]: tokio-rs#2599
[`let_with_type_underscore`]: http://rust-lang.github.io/rust-clippy/rust-1.70.0/index.html#let_with_type_underscore
[attrs-0.1.27]:
    https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.27
[core-0.1.32]:
    https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@hawkw hawkw hawkw approved these changes

@davidbarsky davidbarsky Awaiting requested review from davidbarsky davidbarsky is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@kornelski @hawkw