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/importer: returning nil package on type-checking failure too aggressive #20855

Closed
griesemer opened this issue Jun 29, 2017 · 1 comment
Closed

go/importer: returning nil package on type-checking failure too aggressive #20855

griesemer opened this issue Jun 29, 2017 · 1 comment
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge
Milestone
Go1.10

Comments

@griesemer
Copy link
Contributor

Reminder issue.

The fix for #20837 ( https://go-review.googlesource.com/#/c/47074/ ) now returns nil if a source-imported package has type-checking failure. That is probably too aggressive. We could continue type-checking after the first failure (currently we abort since there's no error handler provided) which would ensure that the type-checked package data structures are in a reasonably consistent state, even in the presence of errors. If we want to be more cautious, we could look for packages with only soft errors (go/types.Error.Soft) or no errors. In those cases we're pretty certain that the data structures are fully set up.

It's an easy change. Try early in 1.10 to see if it's stable.
@griesemer griesemer added the early-in-cycle A change that should be done early in the 3 month dev cycle. label Jun 29, 2017
@griesemer griesemer added this to the Go1.10 milestone Jun 29, 2017
@griesemer griesemer self-assigned this Jun 29, 2017
@gopherbot
Copy link

Change https://golang.org/cl/55730 mentions this issue: go/importer: make source importer more tolerant in presence of errors

@golang golang locked and limited conversation to collaborators Aug 16, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge
Projects
None yet
Milestone
Go1.10
Development

No branches or pull requests
2 participants
@griesemer @gopherbot