x/tools/imports: permission denied causes non-deterministic updating of imports #31285
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
Consistently see the import added to the file
What did you see instead?
The import is sometime added and sometimes not added.
What I think is happening
The problem appears to be that
addExternalCandidates
sometimes sees the package in the vendor dir and sometimes doesn't.https://github.com/golang/tools/blob/d996c1aa53b10c3c47e1764d087a569bb6c32ed1/imports/fix.go#L682
I think it's because it calls
gopathResolver.scan
to find a list of all packageshttps://github.com/golang/tools/blob/d996c1aa53b10c3c47e1764d087a569bb6c32ed1/imports/fix.go#L910
and scan will quit upon the first error it encounters because it uses
fastwalk.Walk
https://github.com/golang/tools/blob/923d25813098b2ffdf1b4bb7ee4ec425fef796a9/internal/fastwalk/fastwalk.go#L195Because it quits on the first error, if it reads the vendor dir with the wanted import first, then the import will be there, and if it hits the dir it can't read first, then it will exit without the import.
I think we should always walk the entire tree and walk around unreadable directories rather than aborting the entire walk at that point.
I can see 2 options:
I'm happy to help with making this change as well.
Related Issue(s)
This issue appears similar to #16890 but it seems like that question is more targetted towards what log messages are printed, here I'm more concerned about the actual behavior (which dirs are scanned).
The text was updated successfully, but these errors were encountered: