ssa: fix abi type error

[visualfc]

• ssa: fix abi byte/rune - uint8/int32
• cl: checkCompileMethods types.Named skip package-level type
• ssa: detect needAbiInit moved into builder.call

[gemini-code-assist]

Summary of Changes

Hello @visualfc, 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 refines the Go compiler's handling of Application Binary Interface (ABI) types, particularly for byte and rune, to ensure accurate internal representation. It also introduces an optimization to skip redundant method compilation for certain named types and centralizes the detection mechanism for ABI initialization, improving the overall correctness and efficiency of the generated code.

Highlights

• ABI Type Correction for byte/rune: The internal ABI representation for Go's byte and rune types has been corrected to llgo_uint8 and llgo_int32 respectively, ensuring proper type mapping in the generated LLVM IR. This also includes explicit string representation for these types as 'uint8' and 'int32'.
• Optimized Method Compilation for Named Types: The compiler now intelligently skips method compilation for package-level named types that do not have type arguments, preventing unnecessary processing and potential issues.
• Centralized ABI Initialization Detection: The logic for detecting the need for ABI initialization, particularly for reflect package functions, has been moved from function declaration to the builder.Call method. This ensures ABI initialization is triggered precisely when a relevant reflect function is invoked, and the reflectFunc map has been expanded to cover more reflect.Value methods.
• New ABI Type Test: A new test file (cl/_testrt/abitype/in.go) has been added to specifically verify the correct ABI string representation for byte and rune types.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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. ↩

[gemini-code-assist]

Code Review

This pull request introduces several fixes and improvements related to SSA generation and ABI type handling. Key changes include correctly mapping byte and rune to their underlying ABI types, adding new test cases, optimizing method compilation by skipping package-level named types, and refactoring the logic for detecting NeedAbiInit. The changes are generally good, but I've found one inconsistency in a generated test file that should be addressed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.06%. Comparing base (5899edf) to head (38d9fa2).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1595      +/-   ##
==========================================
+ Coverage   91.01%   91.06%   +0.04%     
==========================================
  Files          45       45              
  Lines       11971    11981      +10     
==========================================
+ Hits        10896    10911      +15     
+ Misses        899      894       -5     
  Partials      176      176              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[xgopilot]

Code Review Summary

This PR addresses three important fixes: ABI type naming for byte/rune, method compilation for local named types, and reflect function detection. The changes are well-structured with appropriate test coverage.

Key Observations:

• The ABI naming fix correctly maps byte → "uint8" and rune → "int32" for type identity
• Moving NeedAbiInit detection to Builder.Call is semantically more accurate
• Local type method compilation enables proper interface satisfaction

Minor concern: The BasicName function now returns llgo_uint8 for byte but regular types use _llgo_ prefix - please confirm this naming difference is intentional for distinguishing alias types.