Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/gopls: using overlay in GOPACKAGESDRIVER fails or panics #33727
I can't seem to figure out how to prepare the results from my GOPACKAGESDRIVER for gopls to correctly use them. I am using overlay to simultaneously inject my own new packages and to zero out (i.e. replace with
What did you do?
I am working on trying to get a go/packages driver working for TinyGo. My package driver performs overlays before calling out to packages.Load. If I do this, then I see errors about not being able to open files under $GOROOT that aren't actually there, they're in an overlay. So, I decided to translate the GoFiles, CompiledGoFiles, etc back to the original files on their way back to gopls. This only made things even more interesting :)
What did you expect to see?
Gopls should parse the remapped files (maybe), or at least report an error message if some information is not available.
What did you see instead?
gopls crashes with a stack trace:
This corresponds to the
I checked the results that are getting sent back, and they do set TypesSizes:
If I forcibly return from that analysis, I get a different failure further down the line:
I agree that we should probably handle nil pointers in go/analysis a bit better, as these do seem to happen fairly often.
However, I'm not sure on how to help with the overlay issue - is there a way we can reproduce this to help you investigate? I'm not surprised that
I've added an example of this as kylelemons/gopls33727 -- though along the way, it looks like the panic that I'm getting might not actually relate to the overlay. If you comment out the overlay environment variable and replace MaxInt with something that exists like Max, I still see the same panic.
EDIT: If I patch