You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Defensive issue. The zero-config behavior added in #57979 means that gopls works in a lot of cases where it didn't work at all before. In particular, with dynamic build tag support (#29202), gopls will select build contexts to cover a lot of files that it couldn't previously load.
I'm excited for the simpler workspace configuration, but I worry that the newly automatic behavior may be surprising in some cases, for example #65496, where gopls "correctly" identifies a build error in an unsupported port. Additionally, while all this was enabled by our scalability work, having many different build contexts still incurs an overhead, and that may not be desirable in some huge repositories.
I think we should proceed with the new default behavior -- after all the idea was to make gopls "just work" in more cases -- but I think we should add hidden settings to disable (1) dynamic workspace views and (2) dynamic build tag support, in case users encounter unforeseen issues. My guess is that dynamic workspace layout detection is almost always desirable, but build tag behavior is more likely to be confusing.
This won't be hard: we just need to truncate the selectViewDefs algorithm if these defensive settings are present.
gopherbot
added
Tools
This label describes issues relating to any tools in the x/tools repository.
gopls
Issues related to the Go language server, gopls.
labels
Feb 4, 2024
findleyr
changed the title
x/tools/gopls: add temporary setting(s) to disable zero-config algorithms
x/tools/gopls: add temporary setting(s) to optionally disable zero-config algorithms
Feb 4, 2024
Defensive issue. The zero-config behavior added in #57979 means that gopls works in a lot of cases where it didn't work at all before. In particular, with dynamic build tag support (#29202), gopls will select build contexts to cover a lot of files that it couldn't previously load.
I'm excited for the simpler workspace configuration, but I worry that the newly automatic behavior may be surprising in some cases, for example #65496, where gopls "correctly" identifies a build error in an unsupported port. Additionally, while all this was enabled by our scalability work, having many different build contexts still incurs an overhead, and that may not be desirable in some huge repositories.
I think we should proceed with the new default behavior -- after all the idea was to make gopls "just work" in more cases -- but I think we should add hidden settings to disable (1) dynamic workspace views and (2) dynamic build tag support, in case users encounter unforeseen issues. My guess is that dynamic workspace layout detection is almost always desirable, but build tag behavior is more likely to be confusing.
This won't be hard: we just need to truncate the selectViewDefs algorithm if these defensive settings are present.
CC @adonovan
The text was updated successfully, but these errors were encountered: