fix(cl): fill cross-package unexported method Ifn/Tfn so itab is complete

[luoliwoshang]

Fixed #1559

Summary

• Fix itab construction when a type embeds a cross-package type with unexported methods: previously the emitted method metadata set Ifn/Tfn to nil for those promoted unexported methods, leaving the itab with fun[0]=0 and causing interface calls to jump to a null pointer. Now
  Ifn/Tfn are always emitted, so the itab is complete.
• Keep method names fully qualified for unexported methods (package path included) to match interface requirements, but never skip generating function pointers.
• Add regression demo _demo/go/ifaceprom-1599 (self-contained foo package) that embeds a foreign Game and asserts it implements the foreign interface, covering the crash path.
• Regenerate cl/_testgo/abimethod/out.ll to align with the corrected method metadata (no skipped Ifn/Tfn).

Root Cause

• A embeds cross-package B and gains promoted unexported methods.
• During A’s metadata emission (abiUncommonMethods), for unexported methods from another package, skipfn set Ifn/Tfn to nil. The method name/type still matched the interface, but the pointer was nil.
• NewItab matched the method but received a nil Ifn, set fun[0]=0, and marked the itab as “not implemented”; interface calls then dereferenced a null pointer and crashed.

Fix

• Remove the skip-on-cross-package-unexported behavior: always emit Ifn/Tfn using the concrete type’s package; do not write nil pointers.
• Preserve name selection: exported methods use the type’s package for names, unexported methods use the defining package’s fully qualified name; only the function pointers needed correction.
• Ensure both Ifn (interface-call wrapper) and Tfn (direct-call wrapper) are present for promoted methods so itab stays valid.

Tests

• _demo/go: llgo run ./ifaceprom-1599

[gemini-code-assist]

Summary of Changes

Hello @luoliwoshang, 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 introduces two significant compiler fixes: one addressing a nil pointer dereference when calling interface methods on types with promoted, cross-package unexported embedded methods, and another correcting float32 to unsigned integer conversions to match Go's specification. These changes enhance the correctness and stability of the compiler's type system and numerical operations, accompanied by new regression tests and detailed documentation for clarity.

Highlights

• Interface Method Table (itab) Fix: Resolved a runtime panic where promoted, cross-package unexported methods in embedded types resulted in nil function pointers in interface method tables. The fix ensures correct wrapper function pointer emission from the concrete type's package.
• Float-to-Unsigned Integer Conversion Fix: Addressed an issue (Issue 1538) where llgo incorrectly handled float32 to uint8/uint32 conversions, leading to incorrect values and test failures. The compiler now aligns with Go's specification by performing a two-step conversion (float to 64-bit int, then truncate).
• Regression Tests & Documentation: Comprehensive regression tests have been added for both fixes, including _demo/go/ifaceprom for the itab issue and _demo/go/issue1538-floatcvtuint-over for the float conversion. Detailed documentation explaining the root cause and fix strategy for both issues is also included.

🧠 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 contains two main changes: a fix for itab generation for promoted embedded methods, and a fix for a float-to-uint conversion issue (issue #1538). The itab generation fix is well-implemented, and the associated refactoring of the ABI type system in ssa/abitype.go is a significant improvement. The regression test is also comprehensive. However, bundling the unrelated fix for issue #1538 makes this pull request difficult to review and understand. It's a strong convention to have one pull request address one concern. This helps with reviewability, testing, and maintaining a clean commit history. I highly recommend splitting this PR into two separate ones. My review comments are focused on the current state of the code.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.01%. Comparing base (f6337d4) to head (d2adf5d).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1560      +/-   ##
==========================================
- Coverage   91.01%   91.01%   -0.01%     
==========================================
  Files          45       45              
  Lines       11971    11960      -11     
==========================================
- Hits        10896    10885      -11     
  Misses        899      899              
  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 correctly fixes the itab generation bug for promoted embedded methods. The fix is well-targeted: removing the flawed skipfn path and always emitting function pointers from the concrete type's package.

Strengths:

• Clean removal of buggy conditional logic
• Proper separation of concerns: method name uses defining package (mPkg), function pointer uses concrete type's package (fnPkg)
• Demo adequately demonstrates the regression scenario

Minor suggestions:

• The fnPkg := pkg variable could be eliminated since it's never modified
• Demo file would benefit from comments explaining the test case

Overall, this is a correct and focused bug fix.

[visualfc]

对于 Go 官方编译器，结构体的嵌入类型如果位于不同包，未导出的的 method ifn/tfn 始终为 -1 。这块可以分析一下是否还有其他实现原因。

[luoliwoshang]

对于 Go 官方编译器，结构体的嵌入类型如果位于不同包，未导出的的 method ifn/tfn 始终为 -1 。这块可以分析一下是否还有其他实现原因。

明白了，在Go中的可达性标记+链接阶段的DCE后，最终的类型在二进制的元数据中对于未导出的的 method ifn/tfn 始终为 -1 ，
Go在生成类型原始数据时候，对于IFn和TFn是全量的。在链接阶段，会根据可达性标记的信息，去对于对应的方法表的IFn和TFn置为-1。而在 #1450 的优化方向中，会更期望现在生成的IR元数据直接更像Go经过这两个阶段最终产出的类型元数据。
在Go的运行时，也就是使用的未导出的 method ifn/tfn （即元数据中Ifn和Tfn始终为-1）在断言并调用接口对应的方法是能正确执行的。
那当前空指针错误，可能是因为拼接Itab的逻辑/数据结构与Go不一致导致的，这块将会去做对应的调查/确认

Got it. In Go, IFn/Tfns are emitted in full during compilation, then the linker’s reachability + DCE pass rewrites unreachable method entries to -1. In the #1450 optimization, we want our generated IR metadata to resemble Go’s final post-link type metadata. In Go’s runtime,
having unexported methods’ IFn/Tfn set to -1 in metadata still leads to correct interface assertions and calls. Our current nil-pointer crash likely stems from our itab assembly logic/data differing from Go’s; we’ll investigate and confirm that.

[luoliwoshang]

提交新的PR https://github.com/goplus/llgo/pull/1576，在https://github.com/goplus/llgo/pull/1450优化之后，类型元数据的abi.Method列表与Go保持一致，并且对于未导出并跨包的嵌入方法不填充TFn和IFn(在Go中实现为-1），所以在创建Itab的时候，IFn返回nil,现在并不是代表签名匹配失败，所以修改findMethod为返回 bool（是否签名匹配）, abi.Text（函数指针）而函数指针在分析为不可达的情况下是允许为空的，这里保持和Go的行为一致，继续下一个itab的方法指针填充