Update links to goplus/llgo in README.md - #2250
Conversation
There was a problem hiding this comment.
FennoAI Review — PR #2250
Makes the main-package main. symbol-prefix rewrite unconditional by removing the RewriteMainPrefix config field and the -rewrite-main-prefix CLI flag. The change is clean and internally consistent: no dangling references to the removed flag remain anywhere in the tree, the always-on behavior is centralized in abi.PathOf, and the accompanying golden _testdata/_testmeta updates reflect the new canonical main.* symbol names.
Verified specifically:
- Linkage safety — the always-on
main.prefix cannot collide across binaries: each main package is linked into its own artifact (internal/build/build.go), non-rootmainpackages are skipped during a link, and test builds rename the package type tomain.testso they fall through to their real import path. PCLNMode = PCLNNoneadditions incl/compile_test.goare correct and well-commented — without them the always-on dynamicmain.*export would retain otherwise-dead symbols on Linux and mask the GlobalDCE measurement.funcInfoDisplayNamecorrectly reduces to anon-func normalization now that the prefix rewrite lives upstream infuncName/PathOf; its doc comment stays accurate.
A few minor, non-blocking findings inline. No correctness, security, or performance issues found.
Findings without inline locations
internal/build/main_module.go:106: Minor (maintainability): this re-implements the "main package ->main" rule that this PR intentionally centralizes inabi.PathOf(ssa/abi/abi.go:287). Consider callingllssa.PathOf(pkg.Types)here (guarded onpkg.Types != nil) so there's a single source of truth. The two paths differ subtly —PathOftrimsPatchPathPrefix, this usespkg.PkgPathverbatim — which agrees today (an entry module is never a patch-lib package) but invites future drift. ReusingPathOfalso preserves themain.testtest-mode behavior, sincePathOflikewise keys onName() == "main".ssa/abi/abi.go:287: Minor (docs): now that the main-package collapse is unconditional (no longer flag-gated), consider updating thePathOfdoc comment above to note it — e.g. "main packages always returnmain." The comment currently only says it "returns the package path," which no longer fully describes the behavior.
| * [ssa](https://pkg.go.dev/github.com/xgo-dev/llgo/ssa): It generates LLVM IR files (LLVM SSA) using the semantics (interfaces) of Go SSA. Although `LLVM SSA` and `Go SSA` are both IR languages, they work at completely different levels. `LLVM SSA` is closer to machine code, which abstracts different instruction sets. While `Go SSA` is closer to a high-level language. We can think of it as the instruction set of the `Go computer`. `llgo/ssa` is not just limited to the `llgo` compiler. If we view it as the high-level expressive power of `LLVM`, you'll find it very useful. Prior to `llgo/ssa`, you had to operate `LLVM` using machine code semantics. But now, with the advanced SSA form (in the semantics of Go SSA), you can conveniently utilize `LLVM`. | ||
| * [cl](https://pkg.go.dev/github.com/xgo-dev/llgo/cl): It is the core of the llgo compiler. It converts a Go package into LLVM IR files. It depends on `llgo/ssa`. | ||
| * [internal/build](https://pkg.go.dev/github.com/xgo-dev/llgo/internal/build): It strings together the entire compilation process of `llgo`. It depends on `llgo/ssa` and `llgo/cl`. | ||
| * [ssa](https://pkg.go.dev/github.com/goplus/llgo/ssa): It generates LLVM IR files (LLVM SSA) using the semantics (interfaces) of Go SSA. Although `LLVM SSA` and `Go SSA` are both IR languages, they work at completely different levels. `LLVM SSA` is closer to machine code, which abstracts different instruction sets. While `Go SSA` is closer to a high-level language. We can think of it as the instruction set of the `Go computer`. `llgo/ssa` is not just limited to the `llgo` compiler. If we view it as the high-level expressive power of `LLVM`, you'll find it very useful. Prior to `llgo/ssa`, you had to operate `LLVM` using machine code semantics. But now, with the advanced SSA form (in the semantics of Go SSA), you can conveniently utilize `LLVM`. |
There was a problem hiding this comment.
The three "Key modules" links here (lines 452-454) now point at github.com/goplus/llgo/..., but the rest of the README still references xgo-dev/llgo — the badges (lines 4-7) and the clone/install commands (e.g. git clone https://github.com/xgo-dev/llgo.git, the raw.githubusercontent.com/xgo-dev/llgo/... scripts). After this change the README points at two different canonical hosts for the same repo. go.mod also still uses github.com/xgo-dev/llgo. Recommend making it internally consistent — update all host references or none. Note the install sections are mirrored from doc/_readme/scripts/*.sh (also xgo-dev), so a README-only change would drift from those sources.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
No description provided.