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
I'd like to propose a feature enhancement to the go command-line tool, specifically regarding the behavior of the -C flag and the way compilation errors are reported, particularly in heterogeneous development environments
Current Behavior:
Currently, when using go -C <directory> <command>, the go command changes its working directory to <directory>. Consequently, all relative paths and error messages reported by the compiler are relative to this new working directory.
Desired Behavior:
It would be beneficial if there were an option or flag to display compilation errors with paths relative to the original working directory from which the go command was invoked, even when using -C. This would improve the usability of -C in scenarios where users need to execute Go commands in different directories while maintaining context with their original project structure.
Problem with Editor Integration:
Many editors and IDEs rely on absolute or project-relative paths to quickly navigate to error locations. When go -C is used, the reported relative paths are often not recognized by these tools, making it difficult to jump directly to the source of the error. This significantly hinders the debugging process.
Use Case:
Consider a situation where a user has a complex project structure and needs to run tests or builds in a subdirectory using go -C. When compilation errors occur, the reported paths are relative to the subdirectory, making it cumbersome to navigate back to the original file locations.
Proposed Solution (Optional):
Perhaps a new flag, such as -original-paths or similar, could be introduced to control this behavior. Alternatively, this could be achieved through an environment variable.
Benefits:
Significantly improved editor and IDE integration.
Faster and more efficient debugging workflow.
Enhanced usability of go -C in complex projects.
Reduced friction when working with Go in multi-language environments.
The text was updated successfully, but these errors were encountered:
Proposal Details
I'd like to propose a feature enhancement to the go command-line tool, specifically regarding the behavior of the
-C
flag and the way compilation errors are reported, particularly in heterogeneous development environmentsCurrent Behavior:
Currently, when using
go -C <directory> <command>
, thego
command changes its working directory to<directory>
. Consequently, all relative paths and error messages reported by the compiler are relative to this new working directory.Desired Behavior:
It would be beneficial if there were an option or flag to display compilation errors with paths relative to the original working directory from which the
go
command was invoked, even when using-C
. This would improve the usability of-C
in scenarios where users need to execute Go commands in different directories while maintaining context with their original project structure.Problem with Editor Integration:
Many editors and IDEs rely on absolute or project-relative paths to quickly navigate to error locations. When
go -C
is used, the reported relative paths are often not recognized by these tools, making it difficult to jump directly to the source of the error. This significantly hinders the debugging process.Use Case:
Consider a situation where a user has a complex project structure and needs to run tests or builds in a subdirectory using
go -C
. When compilation errors occur, the reported paths are relative to the subdirectory, making it cumbersome to navigate back to the original file locations.Proposed Solution (Optional):
Perhaps a new flag, such as
-original-paths
or similar, could be introduced to control this behavior. Alternatively, this could be achieved through an environment variable.Benefits:
go -C
in complex projects.The text was updated successfully, but these errors were encountered: