Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: go/types.ImportFunc #63477

Open
adonovan opened this issue Oct 9, 2023 · 3 comments
Open

proposal: go/types.ImportFunc #63477

adonovan opened this issue Oct 9, 2023 · 3 comments
Labels
Proposal
Milestone
Proposal

Comments

@adonovan
Copy link
Member

adonovan commented Oct 9, 2023

I propose to add these two lines to go/types:

// An ImporterFunc is an implementation of the single-method
// types.Importer interface based on a function value.
type ImporterFunc func(path string) (*types.Package, error)

func (f ImporterFunc) Import(path string) (*types.Package, error) { return f(path) }

since we seem to keep typing them out everywhere else:

go/analysis/unitchecker/separate_test.go
293:type importerFunc func(path string) (*types.Package, error)

go/analysis/unitchecker/unitchecker.go
438:type importerFunc func(path string) (*types.Package, error)

go/analysis/passes/cgocall/cgocall.go
367:type importerFunc func(path string) (*types.Package, error)

go/packages/packages.go
1099:type importerFunc func(path string) (*types.Package, error)

gopls/internal/lsp/cache/check.go
1861:type importerFunc func(path string) (*types.Package, error)

internal/gcimporter/iexport_test.go
451:type importerFunc func(path string) (*types.Package, error)

internal/refactor/inline/everything_test.go
233:type importerFunc func(path string) (*types.Package, error)

@gri @findleyr
@gopherbot gopherbot added this to the Proposal milestone Oct 9, 2023
@mvdan
Copy link
Member

mvdan commented Oct 10, 2023 •
edited

I have a similar one here: https://github.com/burrowers/garble/blob/45b591d8eb924d05e7452c9c409e15a0a0b7775b/main.go#L158-L172

Note that it works with the ImportFrom method, and since ImporterFrom is documented as The types package does not call Import if an ImporterFrom is present, I make Import simply panic as I expect it to never be called.

Shouldn't that be the added API, e.g. as ImportFromFunc? Perhaps some of your use cases don't care about vendored packages, but in general I assume that the Import method should be treated as obsolete in favor of ImportFrom. For example:

// An ImporterFromFunc is an implementation of the single-method
// types.ImporterFrom interface based on a function value.
type ImporterFromFunc func(path, dir string, mode types.ImportMode) (*types.Package, error)

func (f ImporterFromFunc) Import(path string) (*types.Package, error) {
    panic("Import should never be called when ImportFrom is present")
    // or alternatively...
    // return f(path, "", 0)
}

func (f ImporterFromFunc) ImportFrom(path, dir string, mode types.ImportMode) (*types.Package, error) {
    return f(path, dir, mode)
}

@findleyr
Copy link
Contributor

@mvdan I think the in the common case we already know the mapping of package path -> package, because we've loaded it from go/packages and/or are type checking a single package. Therefore I expect the API @adonovan proposes is more likely to be useful, as suggested by the cited reproductions.

@rsc
Copy link
Contributor

rsc commented Oct 27, 2023

If we accept #47487, then we won't need this. Perhaps it makes sense to muddle along with these unexported implementations for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Proposal
Projects
Proposals
Status: Incoming
Milestone
Proposal
Development

No branches or pull requests
5 participants
@rsc @mvdan @adonovan @gopherbot @findleyr