refactor: remove init$patchDeps mechanism (no longer needed after PR #1450) by luoliwoshang · Pull Request #1596 · goplus/llgo

luoliwoshang · 2026-02-02T07:19:01Z

Summary

Since PR #1450 changed ABI types to compile-time constant data, the init$after lazy loading mechanism no longer exists. This means the initialization order issue that PR #1414 fixed is no longer possible.

Before PR #1450

Types were initialized at runtime via init$after with lazy loading (check null → create)
Cross-package initialization order could cause types to be skipped
Required init$patchDeps to ensure correct initialization order

After PR #1450

Types are compile-time constants embedded directly in LLVM IR
No runtime initialization, no lazy loading, no order issues
init$patchDeps mechanism is no longer needed

LLVM IR Changes

Before (with `init$patchDeps`)

define void @"go/build.init"() {
_llgo_1:
  store i1 true, ptr @"go/build.init$guard", align 1
  call void @"go/build.init$patchDeps"()    ; Separate function for dependency inits
  call void @"go/build.init$hasPatch"()     ; Only global var initialization
  ...
}

define void @"go/build.init$patchDeps"() {
  call void @"bufio.init"()
  call void @"bytes.init"()
  ; ... more dependency inits
  ret void
}

define void @"go/build.init$hasPatch"() {
  ; Only global variable initialization (guard check with inverted branches)
}

After (simplified)

define void @"go/build.init"() {
_llgo_1:
  store i1 true, ptr @"go/build.init$guard", align 1
  call void @"go/build.init$hasPatch"()     ; Contains BOTH dependency inits AND global vars
  ...
}

; No more init$patchDeps function!

define void @"go/build.init$hasPatch"() {
  ; Dependency init calls stay here (not extracted):
  call void @"bufio.init"()
  call void @"bytes.init"()
  ; ... more dependency inits
  ; Global variable initialization
}

Diff

 define void @"go/build.init"() {
   store i1 true, ptr @"go/build.init$guard", align 1
-  call void @"go/build.init$patchDeps"()
   call void @"go/build.init$hasPatch"()
 }

-define void @"go/build.init$patchDeps"() {
-  call void @"bufio.init"()
-  call void @"bytes.init"()
-  ; ...
-  ret void
-}

 define void @"go/build.init$hasPatch"() {
+  call void @"bufio.init"()      ; dependency inits now stay here
+  call void @"bytes.init"()
+  ; ...
   ; global variable initialization
 }

Code Changes

This PR removes:

init$patchDeps function generation
initDepsFnNameOfHasPatch() helper
findFirstNonInitInstruction() helper
createInitDepsFunction() method
Related .init$patchDeps handling in notInit()

Related PRs

ssa: abi type global constant data #1450 - ssa: abi type global constant data
Fix: Correct initialization order for overlay packages #1414 - Fix: Correct initialization order for overlay packages (this PR reverts it)

🤖 Generated with Claude Code

…oplus#1450) Since PR goplus#1450 changed ABI types to compile-time constant data, the init$after lazy loading mechanism no longer exists. This means the initialization order issue that PR goplus#1414 fixed is no longer possible: - Before PR goplus#1450: Types were initialized at runtime via init$after with lazy loading (check null → create). Cross-package initialization order could cause types to be skipped. - After PR goplus#1450: Types are compile-time constants embedded directly in LLVM IR. No runtime initialization, no lazy loading, no order issues. This commit removes: - init$patchDeps function generation - initDepsFnNameOfHasPatch() helper - findFirstNonInitInstruction() helper - createInitDepsFunction() method - Related .init$patchDeps handling in notInit() The overlay package init sequence is simplified back to: overlay.init() → call init$hasPatch() 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

gemini-code-assist · 2026-02-02T07:19:14Z

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 refactors the compiler by eliminating the init$patchDeps mechanism. This mechanism became obsolete after a previous change (PR #1450) converted ABI types to compile-time constants, thereby removing the need for complex runtime initialization order management. The change simplifies the overall initialization flow for overlay packages and removes associated helper functions and logic.

Highlights

Removal of init$patchDeps mechanism: The init$patchDeps mechanism, previously used to manage cross-package initialization order, has been completely removed from the codebase.
Simplification of overlay package initialization: The overlay package initialization sequence is simplified as the init$patchDeps function is no longer generated or called, streamlining the process back to a direct call to overlay.init() → call init$hasPatch().
Obsoleted by ABI type changes: This removal is a direct consequence of PR ssa: abi type global constant data #1450, which changed ABI types to compile-time constant data, eliminating the runtime initialization order issues that init$patchDeps was designed to fix.

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

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 is an excellent refactoring that correctly removes the init$patchDeps mechanism, which became obsolete after the changes in PR #1450. The removal of createInitDepsFunction and its associated helper functions is clean and complete. The related logic in compileBlock and notInit has been simplified accordingly. These changes reduce code complexity and improve maintainability by eliminating unnecessary logic. The pull request is well-explained and the implementation aligns perfectly with the stated goal.

xgopilot · 2026-02-02T07:28:59Z

Code Review Summary

This PR cleanly removes the init$patchDeps mechanism that became obsolete after PR #1450 moved ABI types to compile-time constants. The refactoring is well-executed:

Code Quality: Dead code removed completely with no leftover artifacts or unused imports
Performance: Simplifies init sequence, removing unnecessary function generation and string allocations
Security: No concerns; reduces code complexity
Documentation: Comment in notInit() correctly updated

The PR description clearly explains the rationale. LGTM.

codecov · 2026-02-02T07:43:58Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.00%. Comparing base (5899edf) to head (505a3fb).
⚠️ Report is 12 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1596      +/-   ##
==========================================
- Coverage   91.01%   91.00%   -0.02%     
==========================================
  Files          45       45              
  Lines       11971    11927      -44     
==========================================
- Hits        10896    10854      -42     
+ Misses        899      898       -1     
+ Partials      176      175       -1

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

luoliwoshang · 2026-02-02T08:40:02Z

Reopening this PR. After re-analysis:

The createInitDepsFunction extracts dependency init calls from init$hasPatch into a separate init$patchDeps function.

If we remove this extraction:

Dependency init calls stay inside init$hasPatch
When init$hasPatch executes (guard=true due to inverted branches), it will:
1. First call all dependency init functions
2. Then initialize global variables

The execution is equivalent but simpler:

Before (with init$patchDeps):

overlay.init() → init$patchDeps() → init$hasPatch()
                      ↓                    ↓
               call dep inits      init global vars

After (simplified):

overlay.init() → init$hasPatch()
                      ↓
          call dep inits + init global vars (all inside)

Same functionality, cleaner code!

xgopilot · 2026-02-02T09:21:52Z

cl/compile.go

@@ -508,15 +502,7 @@ func (p *context) compileBlock(b llssa.Builder, block *ssa.BasicBlock, n int, do
 	isCgoCmacro := isCgoCmacro(fnName)
 	for i, instr := range instrs {
 		if i == 1 && doModInit && p.state == pkgInPatch { // in patch package but no pkgFNoOldInit


Minor: The comment mentions pkgFNoOldInit but the condition doesn't check for it. Consider clarifying what the comment is documenting:

Suggested change

if i == 1 && doModInit && p.state == pkgInPatch { // in patch package but no pkgFNoOldInit

for i, instr := range instrs {

if i == 1 && doModInit && p.state == pkgInPatch { // in patch package: call original init$hasPatch

This would make it clearer that the comment describes the action being taken, not what's being checked.

xgopilot · 2026-02-02T09:21:54Z

cl/compile.go

@@ -508,15 +502,7 @@ func (p *context) compileBlock(b llssa.Builder, block *ssa.BasicBlock, n int, do
 	isCgoCmacro := isCgoCmacro(fnName)
 	for i, instr := range instrs {
 		if i == 1 && doModInit && p.state == pkgInPatch { // in patch package but no pkgFNoOldInit


Minor: The comment mentions pkgFNoOldInit but the condition doesn't check for it. Consider clarifying what the comment is documenting:

Suggested change

if i == 1 && doModInit && p.state == pkgInPatch { // in patch package but no pkgFNoOldInit

for i, instr := range instrs {

if i == 1 && doModInit && p.state == pkgInPatch { // in patch package: call original init$hasPatch

This would make it clearer that the comment describes the action being taken, not what's being checked.

xgopilot · 2026-02-02T09:22:05Z

Code Review Summary

Clean refactoring that removes dead code after PR #1450. The removal is complete and consistent - no orphaned references to init$patchDeps remain in the codebase.

Highlights:

✅ Documentation accurately updated in notInit() comment
✅ No security concerns - the underlying vulnerability class was eliminated at the source by PR ssa: abi type global constant data #1450
✅ Small compile-time improvement from removing function generation code
✅ Generated code simplified (one fewer function call for overlay packages)

One minor inline comment suggestion for comment clarity. LGTM otherwise.

luoliwoshang · 2026-02-04T02:58:02Z

@xushiwei

gemini-code-assist bot reviewed Feb 2, 2026

View reviewed changes

luoliwoshang marked this pull request as draft February 2, 2026 07:47

luoliwoshang closed this Feb 2, 2026

luoliwoshang reopened this Feb 2, 2026

luoliwoshang marked this pull request as ready for review February 2, 2026 09:08

luoliwoshang requested a review from visualfc February 2, 2026 09:08

xgopilot bot reviewed Feb 2, 2026

View reviewed changes

visualfc approved these changes Feb 3, 2026

View reviewed changes

luoliwoshang requested a review from xushiwei February 4, 2026 02:57

xushiwei merged commit 07b712c into goplus:main Feb 4, 2026
90 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

refactor: remove init$patchDeps mechanism (no longer needed after PR #1450)#1596

refactor: remove init$patchDeps mechanism (no longer needed after PR #1450)#1596
xushiwei merged 1 commit intogoplus:mainfrom
luoliwoshang:refactor/remove-init-patch-deps

luoliwoshang commented Feb 2, 2026 •

edited

Loading

Uh oh!

gemini-code-assist bot commented Feb 2, 2026

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

xgopilot bot commented Feb 2, 2026

Uh oh!

codecov bot commented Feb 2, 2026 •

edited

Loading

Uh oh!

luoliwoshang commented Feb 2, 2026

Uh oh!

xgopilot bot Feb 2, 2026

Uh oh!

xgopilot bot Feb 2, 2026

Uh oh!

xgopilot bot commented Feb 2, 2026

Uh oh!

luoliwoshang commented Feb 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	if i == 1 && doModInit && p.state == pkgInPatch { // in patch package but no pkgFNoOldInit
	for i, instr := range instrs {
	if i == 1 && doModInit && p.state == pkgInPatch { // in patch package: call original init$hasPatch

Conversation

luoliwoshang commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Before PR #1450

After PR #1450

LLVM IR Changes

Before (with init$patchDeps)

After (simplified)

Diff

Code Changes

Related PRs

Uh oh!

gemini-code-assist bot commented Feb 2, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

xgopilot bot commented Feb 2, 2026

Uh oh!

codecov bot commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

luoliwoshang commented Feb 2, 2026

Uh oh!

xgopilot bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

xgopilot bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

xgopilot bot commented Feb 2, 2026

Code Review Summary

Uh oh!

luoliwoshang commented Feb 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

luoliwoshang commented Feb 2, 2026 •

edited

Loading

Before (with `init$patchDeps`)

codecov bot commented Feb 2, 2026 •

edited

Loading