fix: support gno crossing entry points and build.env driver - #58
Draft
davd-gzl wants to merge 2 commits into
Draft
fix: support gno crossing entry points and build.env driver#58davd-gzl wants to merge 2 commits into
davd-gzl wants to merge 2 commits into
Conversation
Two things kept a gno realm package from type-checking cleanly. The in-process resolver was selected by reading GOPACKAGESDRIVER from the process environment. A folder that configures the driver through gnopls' build.env setting was left with a GoPackagesDriverView whose driver is never installed, and go/packages then tried to exec ":memory:" as a binary. Select it from the folder's effective driver instead. go/types rejects func init(cur realm) and func main(cur realm), which gno accepts and binds cur to the current realm. Drop the InvalidInitDecl error for those two signatures only. The parameter still resolves inside the body, so only the signature complaint has to go, and init declarations that are wrong in gno as well as in Go keep reporting. Add an end-to-end test that a realm package using the gno universe scope produces no diagnostics, and a regression test that the standard libraries living only under gnovm/tests/stdlibs stay resolvable.
davd-gzl
force-pushed
the
fix/gno-builtin-shim-drift
branch
from
August 3, 2026 21:14
1f5bc1c to
9106879
Compare
davd-gzl
changed the title
go/types reports the entry point signature complaint under two codes: init under InvalidInitDecl and main under InvalidMainDecl. Only the former was matched, so `func main(cur realm)` in package main still reported a spurious error even though the crossing form is what gno expects. Match both codes, and leave declarations carrying type parameters alone, because go/types reuses the same code for the "must have no type parameters" complaint, which gno rejects as well. Cover main in the integration tests, which had no package main case at all.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A folder that configures its go/packages driver through gnopls' build.env setting never reached the in-process resolver, because the selection read GOPACKAGESDRIVER from the process environment instead. Such a folder was left with a driver that is never installed, and go/packages would then try to exec ":memory:" as a binary. This selects the resolver from the folder's effective driver.
Separately, go/types rejects
func init(cur realm)andfunc main(cur realm), the crossing forms that gno accepts and binds cur to the current realm. This drops the signature error for those two forms. go/types reports init under InvalidInitDecl and main under InvalidMainDecl, so both codes are matched, and declarations carrying type parameters are left alone because their complaint shares the same code. Entry points that are wrong in gno as well as in Go keep reporting.Adds end-to-end tests that a realm package using the gno universe scope produces no diagnostics, that the crossing form of main is accepted in package main, and that non-crossing init forms still report, plus a regression test that the standard libraries living only under gnovm/tests/stdlibs stay resolvable.
Verified with
go test -count=1 ./pkg/..., which is what CI runs. In the integration diagnostics package the failure count is unchanged against main at 47, with the three new tests passing on top. Note that package is slow by default: each test's deadline is derived fromgo test -timeout, soGOPLS_INTEGRATION_TEST_TIMEOUT=60skeeps a run to a couple of minutes.