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
This output is correct, if a bit strange: if you run a go command outside of any module, the effective module name for the resulting artifacts is command-line-arguments, and because you passed the -m flag it doesn't need a module path to resolve the effective import path of the current directory (and therefore doesn't error on the fact that there is no such module path).
I suppose that we could add some sort of special case, but I can't think of one would simplify this case more than it complicates others. Any concrete suggestions?
Is there anything go list -m can do without a module root? The arguments are all module paths or queries, and those are only meaningful if we can generate the build list, which is going to be empty if there's no go.mod and no source files.
There's a branch in go list to handle -m behavior. I think we can just add a call to modload.ModRoot in there. That would print the cannot find main module message.
True, so is -u. And positional query arguments work, too.
So if we added a special case for this, it would just be for go list -m. No positional arguments. No -u, -versions or other options that affect semantics (-json would be okay though). The logic would just be in internal/list/list.go though; module and package loading infrastructure would be unaffected.
The path to resolution is known, but the work has not been done.
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Issue is not actionable because of missing required information, which needs to be provided.
Jun 5, 2019