refactor: rename EmitAsyncVoidInterceptor to EmitAsyncTaskInterceptor

[ANcpLua]

Summary

• Rename EmitAsyncVoidInterceptor to EmitAsyncTaskInterceptor in the instrumentation source generator
• The method generates async Task interceptors, not async void — the old name falsely implied the async void antipattern

Test plan

• dotnet build passes with zero warnings
• Verify generated interceptor output unchanged (rename is internal only)

🤖 Generated with Claude Code

Summary by CodeRabbit

• Refactor
  • Improved internal code organization and naming clarity in the instrumentation generator's interceptor emission logic.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Summary of Changes

Hello @ANcpLua, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the instrumentation source generator by updating the name of an internal method. The change ensures that the method's name accurately reflects its functionality of generating async Task methods, improving code clarity and consistency. This is an internal-only change with no expected impact on the generated output or external behavior.

Highlights

• Method Renaming: The method EmitAsyncVoidInterceptor has been renamed to EmitAsyncTaskInterceptor within the instrumentation source generator. This change clarifies that the method generates async Task interceptors, not async void, addressing the misleading implication of the old name.

Changelog

• src/qyl.instrumentation.generators/Emitters/InterceptorEmitter.cs
  • Updated the call site for the EmitAsyncVoidInterceptor method to EmitAsyncTaskInterceptor.
  • Renamed the method definition from EmitAsyncVoidInterceptor to EmitAsyncTaskInterceptor.

Activity

• The pull request was created by ANcpLua.
• The author has provided a summary and test plan, confirming that dotnet build passes with zero warnings.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

A private helper method is renamed from EmitAsyncVoidInterceptor to EmitAsyncTaskInterceptor to better reflect its actual behavior of returning an async Task. The corresponding call site in the switch statement is updated accordingly.

Changes

Cohort / File(s)	Summary
Interceptor Emitter Refactoring src/qyl.instrumentation.generators/Emitters/InterceptorEmitter.cs	Renamed private helper method EmitAsyncVoidInterceptor to EmitAsyncTaskInterceptor and updated the call site to match the corrected naming convention.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/release-readiness-warnings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request correctly renames EmitAsyncVoidInterceptor to EmitAsyncTaskInterceptor to more accurately reflect that it generates interceptors for async Task methods. While reviewing this change, I discovered a critical logic bug in the switch statement that determines which interceptor to emit. The current logic would incorrectly handle methods returning a non-generic Task, and the branch containing the newly renamed method is unreachable. I've provided a detailed comment with a suggested fix to correct the code generation logic.

[gemini-code-assist]

While the rename to EmitAsyncTaskInterceptor is correct, this case block is currently unreachable due to a logic flaw in the switch statement. The preceding condition case true when !isVoid: on line 83 incorrectly matches both Task<T> and non-generic Task, routing both to EmitAsyncInterceptor. This is only correct for Task<T> and would cause a compilation error if a method returning a non-generic Task were intercepted.

The entire switch block needs to be refactored to correctly differentiate between generic and non-generic tasks. Here is a suggested implementation:

// Before the switch statement, you can determine if the task is generic:
var isGenericTask = target.ReturnType.Contains('<');

// Then, replace the switch block (lines 81-92) with:
switch (isTask)
{
    case true when isGenericTask:
        EmitAsyncInterceptor(sb, target, methodId);
        break;
    case true:
        EmitAsyncTaskInterceptor(sb, target, methodId);
        break;
    default:
        EmitSyncInterceptor(sb, target, methodId);
        break;
}

This ensures Task<T> and Task are handled by their respective emitter methods, fixing the bug.

[Copilot]

Pull request overview

Renames an internal helper in the instrumentation source generator to reflect that it emits async Task (not async void) interceptors.

Changes:

• Rename EmitAsyncVoidInterceptor to EmitAsyncTaskInterceptor.
• Update the call site in EmitInterceptor to use the new method name.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The EmitAsyncTaskInterceptor branch is likely unreachable: isVoid only checks for void/System.Void, so any Task/Task<T> return type will have isVoid == false and hit EmitAsyncInterceptor. For non-generic Task (and ValueTask), EmitAsyncInterceptor will generate var result = await ..., which does not compile because await Task returns void. Consider explicitly detecting non-generic Task (and optionally ValueTask) and routing those to EmitAsyncTaskInterceptor, while keeping EmitAsyncInterceptor for Task<T>/ValueTask<T>.