Remove #[expect(ungated_async_fn_track_caller)] when track_caller on async fns stabilizes

[coderabbitai]

Summary

Remove the #[expect(ungated_async_fn_track_caller)] attribute from collect_multi_packet in wireframe_testing/src/multi_packet.rs once Rust stabilizes track_caller on async functions.

Context

The function collect_multi_packet currently uses #[expect(ungated_async_fn_track_caller)] because #[track_caller] on async functions is still unstable in Rust. Once the feature is stabilised, this lint suppression should be removed.

References

• Upstream Rust tracking issue: Tracking Issue for #[track_caller] on async fn rust-lang/rust#110011
• Related PR: Replace #[allow] with #[expect] in tests and annotate #438
• Requested by: @leynos in Replace #[allow] with #[expect] in tests and annotate #438 (comment)

Acceptance Criteria

• Verify that track_caller on async functions has been stabilised in Rust
• Remove the #[expect(ungated_async_fn_track_caller, reason = "track_caller on async fns is unstable")] attribute
• Remove the associated FIXME comment
• Confirm tests pass with the updated code

[traycerai]

Plan

Observations

The codebase uses Rust nightly (nightly-2025-07-22) and has a single occurrence of #[allow(ungated_async_fn_track_caller)] in file:wireframe_testing/src/multi_packet.rs at line 31. The collect_multi_packet function uses #[track_caller] on an async function, which is currently unstable. The project has comprehensive testing infrastructure via make test and strict linting with Clippy warnings denied. The function is publicly exported from the wireframe_testing crate.

Approach

The implementation will follow a verification-first approach: confirm the Rust stabilization status, then perform a minimal surgical removal of the lint suppression attribute and comment. This maintains the existing #[track_caller] functionality while eliminating the workaround once the feature becomes stable. The approach ensures no behavioral changes, only cleanup of temporary unstable feature handling.

Implementation Steps

1. Verify Rust Stabilization Status

Before making any changes, confirm that #[track_caller] on async functions has been stabilized:

• Check the upstream Rust tracking issue at Tracking Issue for #[track_caller] on async fn rust-lang/rust#110011 to verify the feature has been marked as stabilized
• Review the Rust release notes for the version where stabilization occurred
• Verify the project's file:rust-toolchain.toml specifies a Rust version equal to or newer than the stabilization version
• If the current nightly version (nightly-2025-07-22) predates stabilization, update file:rust-toolchain.toml to a newer nightly or stable version that includes the stabilized feature

2. Remove Lint Suppression Attribute

In file:wireframe_testing/src/multi_packet.rs:

• Remove line 31: #[allow(ungated_async_fn_track_caller)] // track_caller on async is unstable
• Keep the #[track_caller] attribute on line 30 (this is the actual feature being used)
• Keep the #[must_use] attribute on line 29
• Ensure no other changes are made to the function signature or implementation

The function should retain only these attributes:

#[must_use]
#[track_caller]
pub async fn collect_multi_packet<F, E>(resp: Response<F, E>) -> Vec<F>

3. Verify No Other Occurrences

Confirm there are no other instances of this pattern in the codebase:

• Search for ungated_async_fn_track_caller across all Rust files
• Search for async_fn_track_caller to catch any related feature gates
• Verify no FIXME or TODO comments reference this issue

4. Run Test Suite

Execute the full test suite to ensure the change doesn't introduce regressions:

• Run make test to execute all unit and integration tests
• Run make test-bdd to execute BDD tests specifically
• Verify all tests pass without warnings or errors
• Confirm the #[track_caller] attribute functions correctly (panic messages should include proper caller location)

5. Run Linting Checks

Ensure code quality standards are maintained:

• Run make lint to execute Clippy with warnings denied
• Run make check-fmt to verify code formatting
• Confirm no new warnings or errors are introduced
• Verify the removal of the #[allow(...)] attribute doesn't trigger any new lints

6. Update Documentation (if applicable)

Check if any documentation references the unstable feature:

• Review file:docs/wireframe-testing-crate.md for mentions of the unstable feature or workarounds
• Update any comments in file:wireframe_testing/src/multi_packet.rs that reference the instability
• Ensure the function's doc comment (lines 8-28) remains accurate and doesn't need updates

7. Verification Checklist

Before considering the task complete:

• ✓ Rust version supports stable #[track_caller] on async functions
• ✓ #[allow(ungated_async_fn_track_caller)] attribute removed
• ✓ Associated comment removed
• ✓ #[track_caller] attribute retained
• ✓ All tests pass (make test)
• ✓ Linting passes (make lint)
• ✓ No new warnings introduced
• ✓ Function behavior unchanged

Expected Outcome

After implementation, the collect_multi_packet function will use #[track_caller] on an async function without any lint suppressions, relying on the stabilized Rust feature. The panic messages in the function will continue to correctly attribute to the caller's location, and all tests will pass without modifications.

Import In IDE

🤖 Prompt for AI Agents

## Observations

The codebase uses Rust nightly (nightly-2025-07-22) and has a single occurrence of `#[allow(ungated_async_fn_track_caller)]` in `file:wireframe_testing/src/multi_packet.rs` at line 31. The `collect_multi_packet` function uses `#[track_caller]` on an async function, which is currently unstable. The project has comprehensive testing infrastructure via `make test` and strict linting with Clippy warnings denied. The function is publicly exported from the `wireframe_testing` crate.

## Approach

The implementation will follow a verification-first approach: confirm the Rust stabilization status, then perform a minimal surgical removal of the lint suppression attribute and comment. This maintains the existing `#[track_caller]` functionality while eliminating the workaround once the feature becomes stable. The approach ensures no behavioral changes, only cleanup of temporary unstable feature handling.

## Implementation Steps

### 1. Verify Rust Stabilization Status

Before making any changes, confirm that `#[track_caller]` on async functions has been stabilized:

- Check the upstream Rust tracking issue at https://github.com/rust-lang/rust/issues/110011 to verify the feature has been marked as stabilized
- Review the Rust release notes for the version where stabilization occurred
- Verify the project's `file:rust-toolchain.toml` specifies a Rust version equal to or newer than the stabilization version
- If the current nightly version (nightly-2025-07-22) predates stabilization, update `file:rust-toolchain.toml` to a newer nightly or stable version that includes the stabilized feature

### 2. Remove Lint Suppression Attribute

In `file:wireframe_testing/src/multi_packet.rs`:

- Remove line 31: `#[allow(ungated_async_fn_track_caller)] // track_caller on async is unstable`
- Keep the `#[track_caller]` attribute on line 30 (this is the actual feature being used)
- Keep the `#[must_use]` attribute on line 29
- Ensure no other changes are made to the function signature or implementation

The function should retain only these attributes:
```
#[must_use]
#[track_caller]
pub async fn collect_multi_packet<F, E>(resp: Response<F, E>) -> Vec<F>
```

### 3. Verify No Other Occurrences

Confirm there are no other instances of this pattern in the codebase:

- Search for `ungated_async_fn_track_caller` across all Rust files
- Search for `async_fn_track_caller` to catch any related feature gates
- Verify no FIXME or TODO comments reference this issue

### 4. Run Test Suite

Execute the full test suite to ensure the change doesn't introduce regressions:

- Run `make test` to execute all unit and integration tests
- Run `make test-bdd` to execute BDD tests specifically
- Verify all tests pass without warnings or errors
- Confirm the `#[track_caller]` attribute functions correctly (panic messages should include proper caller location)

### 5. Run Linting Checks

Ensure code quality standards are maintained:

- Run `make lint` to execute Clippy with warnings denied
- Run `make check-fmt` to verify code formatting
- Confirm no new warnings or errors are introduced
- Verify the removal of the `#[allow(...)]` attribute doesn't trigger any new lints

### 6. Update Documentation (if applicable)

Check if any documentation references the unstable feature:

- Review `file:docs/wireframe-testing-crate.md` for mentions of the unstable feature or workarounds
- Update any comments in `file:wireframe_testing/src/multi_packet.rs` that reference the instability
- Ensure the function's doc comment (lines 8-28) remains accurate and doesn't need updates

### 7. Verification Checklist

Before considering the task complete:

- ✓ Rust version supports stable `#[track_caller]` on async functions
- ✓ `#[allow(ungated_async_fn_track_caller)]` attribute removed
- ✓ Associated comment removed
- ✓ `#[track_caller]` attribute retained
- ✓ All tests pass (`make test`)
- ✓ Linting passes (`make lint`)
- ✓ No new warnings introduced
- ✓ Function behavior unchanged

## Expected Outcome

After implementation, the `collect_multi_packet` function will use `#[track_caller]` on an async function without any lint suppressions, relying on the stabilized Rust feature. The panic messages in the function will continue to correctly attribute to the caller's location, and all tests will pass without modifications.

---

Execution Information

Branch: main
Commit: 61c27d1

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[leynos]

Plan: Remove #[expect(ungated_async_fn_track_caller)] — Issue #439

Context

Issue #439 requests removing the
#[expect(ungated_async_fn_track_caller)] attribute from collect_multi_packet in
wireframe_testing/src/multi_packet.rs once Rust stabilizes #[track_caller] on async
functions.

Finding: Feature Is NOT Yet Stabilized

After investigating the upstream Rust tracking issue and documentation:

• Tracking issue rust-lang/rust#110011 remains OPEN
• The feature is still listed in the Rust Unstable Book
• No stabilization PR has been filed
• Unresolved design question: whether #[track_caller] on async fns should track
  the poller (current behavior) or the original caller — this is blocking stabilization
• The project's nightly toolchain (nightly-2025-07-22) does not change this status

Consequence

The first acceptance criterion — "Verify that track_caller on async functions has been
stabilised in Rust" — cannot be satisfied. Removing the lint suppression now would
cause the project to fail its lint gate (make lint uses -D warnings), since the
compiler would emit the ungated_async_fn_track_caller warning for using #[track_caller]
on an async fn without the feature gate.

Recommendation

No code changes should be made at this time. The issue should remain open until Rust
stabilizes the feature. The existing code is correct:

// wireframe_testing/src/multi_packet.rs lines 29-37
#[must_use]
#[track_caller]
// FIXME: Remove when `track_caller` on async fns is stabilized.
// Tracking: https://github.com/rust-lang/rust/issues/110011
#[expect(
    ungated_async_fn_track_caller,
    reason = "track_caller on async fns is unstable"
)]
pub async fn collect_multi_packet<F, E>(resp: Response<F, E>) -> Vec<F> {

The FIXME comment and #[expect(...)] attribute correctly document the situation and
should be preserved until the upstream feature stabilizes.

Verification

No changes to verify — the recommendation is to take no action and leave the issue open.