Skip to content

cmd/compile: support type assertion diagnostics - #2201

Closed
MeteorsLiu wants to merge 9 commits into
xgo-dev:mainfrom
MeteorsLiu:fix/goroot-typeassert
Closed

cmd/compile: support type assertion diagnostics#2201
MeteorsLiu wants to merge 9 commits into
xgo-dev:mainfrom
MeteorsLiu:fix/goroot-typeassert

Conversation

@MeteorsLiu

Copy link
Copy Markdown
Contributor

No description provided.

@fennoai fennoai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review: type assertion diagnostics

The change is well-scoped and correct. The inlined / not inlined classification in cl/compile.go matches gc semantics — non-interface and empty-interface targets are inlined, non-empty interfaces are not inlined — and the emitted strings match gc's -d=typeassert reference (go/test/interface/assertinline.go), so removing the xfail.yaml entry is justified. No security concerns; when -d=typeassert is off the diagnostic block is fully guarded, so normal builds pay nothing beyond one boolean branch per assertion.

Two minor findings are inline. A few nits not worth blocking on:

  • SetTypeAssertDebug has no doc comment, but this matches the sibling setters (EnableDebug, EnableTrace), so it's consistent as-is.
  • typeAssertNoCols could be typeAssertNoColumns to match the noColumns param and NoErrorColumn config field.
  • The DebugTypeAssert field comment ("report type-assertion lowering decisions") is slightly imprecise: the diagnostic re-derives the verdict from the asserted type rather than observing the actual lowering path in ssa/interface.go. "report whether each type assertion is inlined" would read truer.

Comment thread cmd/internal/compile/compile.go
Comment thread cmd/internal/compile/compile.go Outdated
@codecov

codecov Bot commented Jul 28, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@MeteorsLiu
MeteorsLiu marked this pull request as draft July 28, 2026 09:44
@MeteorsLiu
MeteorsLiu marked this pull request as ready for review July 28, 2026 10:28

@fennoai fennoai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review summary

This PR adds a -d=typeassert type-assertion lowering diagnostic to match gc's test/interface/assertinline.go errorcheck, and removes that case's xfail entry. The core logic is sound:

  • The inlined / not-inlined classification via intf.NumMethods() != 0 on the asserted type's underlying interface matches gc's rule (assertions to a non-empty interface are "not inlined"; concrete types and empty interfaces are "inlined").
  • typeAssertDebugValue correctly handles typeassert, typeassert=0, typeassert=N, and rejects typeassert=garbage / nottypeassert=1, and is shared by both runCmd (behavioral) and compatibleDebugSetting (compatibility gate) so parsing is not duplicated.
  • The stderr Fprintf and fset.Position call are correctly gated behind if debugTypeAssert, so there is no cost on the normal compile path.

No bugs, regressions, security, or performance issues found. The findings below are minor comment-accuracy nits (left inline).

Note (not blocking): internal/build/build.go now calls cl.SetDebug(...) and its deferred reset unconditionally for every package, whereas previously this only happened inside the showDetail branch. cl's debug state is package-level global (debugInstr, debugTypeAssert, noErrorColumn), and buildPkg currently runs serially (buildAllPkgs iterates buildOne in plain for loops), so this is safe today. But createSSAPkg already carries a // TODO: build concurrently note — if package builds are ever parallelized, this per-package global set/reset would race and could clear the initial package's flags mid-compile. A short comment near the defer documenting the sequential-build assumption would make that coupling visible.

Comment thread internal/build/build.go
Comment thread ssa/interface.go Outdated
@MeteorsLiu MeteorsLiu closed this Jul 28, 2026
@MeteorsLiu MeteorsLiu reopened this Jul 28, 2026

@fennoai fennoai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review summary

This is a clean, well-scoped change that wires a -d=typeassert diagnostic end-to-end (flag parsing → cl emission) to mirror gc's assertinline.go errorcheck behavior, and correctly removes the now-obsolete xfail.yaml entry. Security and performance are not a concern here (the diagnostic block is fully gated behind debugTypeAssert, and parsing runs once at flag-parse time). The defer in buildPkg correctly resets both llssa and cl debug state, so no flag leaks into subsequently built packages.

The findings below are non-blocking; the most substantive is the classification gap between the diagnostic label and the actual lowering (inline comment on ssa/interface.go).

Findings are left as inline comments on the relevant diff lines.

Comment thread cl/compile.go
Comment thread cmd/internal/compile/compile.go
Comment thread cmd/internal/compile/compile.go
Comment thread internal/build/build.go
Comment thread ssa/interface.go Outdated
@MeteorsLiu
MeteorsLiu force-pushed the fix/goroot-typeassert branch from fd8476b to 5af4ae7 Compare August 5, 2026 04:38
@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown

LLGo baseline benchmarks

5af4ae737f03 | workflow run | long-term charts

Program measurements

Platform Workload File size vs base Build vs base Run vs base
Linux cprintf 18456 B +0.0% 282.695 ms -1.5% (better) 1.326 ms +7.5% (worse)
Linux fmtprintf 1829968 B +0.0% 2.912 s +0.1% (worse) 3.047 ms -1.4% (better)
Linux println 68008 B +0.0% 283.093 ms -0.1% (better) 1.697 ms +8.3% (worse)
macOS cprintf 84672 B +0.0% 308.160 ms -6.8% (better) 2.662 ms -2.9% (better)
macOS fmtprintf 1869328 B +0.0% 2.807 s -22.6% (better) 13.346 ms -4.8% (better)
macOS println 121200 B +0.0% 310.220 ms -9.9% (better) 3.570 ms -10.6% (better)
Core language and compiler benchmarks
Platform Benchmark ns/op vs base
Linux BenchmarkLookupPCRandom 13.320 ns/op +0.1% (worse)
Linux BenchmarkMergeCompilerFlags 150.500 ns/op -0.1% (better)
Linux BenchmarkMergeLinkerFlags 94.220 ns/op +0.0% (worse)
Linux BenchmarkChannelBuffered 33.660 ns/op +0.0% (worse)
Linux BenchmarkChannelHandoff 26626 ns/op +4.2% (worse)
Linux BenchmarkDefer 48.740 ns/op +2.3% (worse)
Linux BenchmarkDirectCall 1.556 ns/op +0.0%
Linux BenchmarkGlobalRead 1.564 ns/op +0.5% (worse)
Linux BenchmarkGlobalWrite 2.484 ns/op +0.2% (worse)
Linux BenchmarkGoroutine 31398 ns/op -0.5% (better)
Linux BenchmarkInterfaceCall 8.098 ns/op +0.0%
Linux BenchmarkRuntimeGetG 2.179 ns/op +0.0%
macOS BenchmarkLookupPCRandom 13.640 ns/op +2.1% (worse)
macOS BenchmarkMergeCompilerFlags 120.200 ns/op -12.5% (better)
macOS BenchmarkMergeLinkerFlags 96.340 ns/op +29.1% (worse)
macOS BenchmarkChannelBuffered 25.250 ns/op +14.3% (worse)
macOS BenchmarkChannelHandoff 7627 ns/op +10.8% (worse)
macOS BenchmarkDefer 41.520 ns/op +44.3% (worse)
macOS BenchmarkDirectCall 1.075 ns/op +2.4% (worse)
macOS BenchmarkGlobalRead 1.129 ns/op -10.8% (better)
macOS BenchmarkGlobalWrite 1.121 ns/op +0.1% (worse)
macOS BenchmarkGoroutine 49929 ns/op +57.6% (worse)
macOS BenchmarkInterfaceCall 5.039 ns/op +7.9% (worse)
macOS BenchmarkRuntimeGetG 2.341 ns/op +9.1% (worse)

Compared with 6670dae3884d measured in the same runner job.

@cpunion cpunion added the go-test-compat Go standard-library and GOROOT test compatibility label Aug 9, 2026
@cpunion

cpunion commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Closing because interface/assertinline.go is now explicitly classified on main as a cmd/compile-specific, not-applicable diagnostic case. LLGo does not need to reproduce this optimization diagnostic; the branch also predates the shared internal/goflags parsing path.

@cpunion cpunion closed this Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

go-test-compat Go standard-library and GOROOT test compatibility

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants