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.

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

go/types: Checker error with custom importer #12130

Closed
dooman87 opened this issue Aug 13, 2015 · 5 comments
Closed

go/types: Checker error with custom importer #12130

dooman87 opened this issue Aug 13, 2015 · 5 comments
Labels
FrozenDueToAge
Milestone
Unplanned

Comments

@dooman87
Copy link

I'm trying to create a gounexport tool for go challenge that was started couple of weeks ago. I have an error from go/types/Checker while trying to check golang.org/x/tools/godoc package.

I'm using docker image with 1.5 version from golang docker hub on:

root@7a8ffc8036f0:/go/src/github.com/dooman87/gounexport# go version
go version go1.5beta3 linux/amd64

The host system is Debian Jessie:

dooman@dimka:~/Projects/go/src/github.com/dooman87/gounexport$ uname -a
Linux dimka 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
dooman@dimka:~/Projects/go/src/github.com/dooman87/gounexport$

I got the following error:

2015/08/13 10:16:12     TYPE [func(tuple *golang.org/x/tools/go/types.Tuple) uint32], position [301 : 10]
2015/08/13 10:16:12 Error while checking sources
/go/src/golang.org/x/tools/go/ssa/create.go:36:28: cannot pass argument h (variable of type golang.org/x/tools/go/types/typeutil.Hasher) to parameter of type golang.org/x/tools/go/types/typeutil.Hasher
exit status 1
FAIL    github.com/dooman87/gounexport  1.139s

It looks little bit strange because I didn't find any issues with types. I'm just wondering could it be some sort of conflict between x/tools ang go/ packages?

On small test packages all working fine. Also, I have the similar issue if I'm trying to importer.Default() directly from customImporter (see commented line in Import func) when trying to analyze this source code.

I created my own importer that I'm using instead of default when default can't reach sources (all not compiled with go, I suppose). Also, I'm using it to collect information about packages that I'm interested in.

type customImporter struct {
    info            *types.Info
    fset            *token.FileSet
    pkg             string
    defaultImporter types.Importer
}

func (_importer *customImporter) Import(path string) (*types.Package, error) {
    //importer.Default().Import(path) //TODO: not working?
    pkg, err := _importer.defaultImporter.Import(path)
    if err != nil {
        log.Printf("Importing package [%s]", path)
        files := GetFiles(path, false)
        astFiles, fset := doParseFiles(files, _importer.fset)
        pkg, _ = doExtractInfo(path, astFiles, fset, _importer)

        return pkg, nil
    }
    return pkg, nil
}
...

func doExtractInfo(pkgName string, astFiles []*ast.File, fset *token.FileSet, importer *customImporter) (*types.Package, *token.FileSet) {
    var conf types.Config
    conf.Importer = importer

    pkg, err := conf.Check(pkgName, fset, astFiles, importer.info)
    if err != nil {
        log.Fatalf("Error while checking sources\n%v", err)
    }
    log.Printf("Package [%s] successfully parsed\n", pkg.Name())

    logInfo(importer.info, fset)

    return pkg, fset
}
@mikioh mikioh changed the title go/types/Checker error with custom importer go/types: Checker error with custom importer Aug 13, 2015
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Aug 13, 2015
@griesemer
Copy link
Contributor

@dooman87 I haven't looked into this in details but I have I have a suspicion: The error message mentions the same type "golang.org/x/tools/go/types/typeutil.Hasher" twice but they are not the same (according to the error).

This is a named type. The type-checker treats named types equal only if they are represented by the same identical pointer. I suspect that you have two different representations for the same named type, in this case an imported type. An importer must be careful to always canonicalize named types so that the same named type imported via different imports results in always the same type data structure (i.e., the same pointer). This error can appear if you write your own custom-importer from scratch and don't to the canonicalization, or if you use the existing importers but don't provide the same import package map. I suspect the latter is the culprit.

Please check and update this issue. Thanks.

@dooman87
Copy link
Author

Thanks @griesemer. I'm pretty sure that you are right. I'll try to add package map and do not importing packages that already was imported. Hopefully, it will help. Thanks a lot for help!

@griesemer
Copy link
Contributor

@dooman87 I'm going to close this for now. Feel free to re-open if you continue to run into trouble; ideally with a self-contained test case. Thanks.

@dooman87
Copy link
Author

@griesemer you was absolutely right, it was my bad. Thanks a lot, really appreciate that. Sorry for bothering, will use mail groups first. Just was little bit confused with error message.

@griesemer
Copy link
Contributor

@dooman87 No problem. Mailing the group probably wouldn't have helped much in this case because not many people are familiar with this specific detail. @alandonovan has written a pretty thorough document describing the finer details of how to use go/types. This document should become available soon and might help in the future.

@golang golang locked and limited conversation to collaborators Aug 22, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@dooman87 @ianlancetaylor @griesemer @gopherbot