cmd/link: include DWARF declaration position for types #25064
Comments
|
AFAIK, declaration coordinates for types are not stored anywhere in the object files that the linker gets. Type information in the linker comes from the runtime type structures, so we'd have expand those, which would increase memory usage and binary size even when DWARF was disabled. That's unlikely to happen unless there's a really compelling case for it. If type DIEs were generated in the compiler, this would be more feasible, but that's a big project. We might get to it eventually. |
|
Thank you for your quick reply. I realize that this is not necessarily a priority in the big picture. Would producing the package import path, for example |
|
This isn't my area of expertise, but I believe that main is special and doesn't actually have an import path at all, since it's never imported. If it did that would be a good solution. Does DW_AT_compilation_dir help at all? |
ianlancetaylor
added
the
NeedsInvestigation
gopherbot
added
the
compiler/runtime
The linker should include the declaration position for types so that we can use this information in editors and disambiguate where the types come from.
The easiest to replicate the confusion is to have a project which has multiple main packages and to try to go to a specific type declared in both those main package. In this case, the type contains only the
main.TypeNameinformation so an editor would be forced to implement additional logic to infer where themainpackage is located in the binary.Thank you.
The text was updated successfully, but these errors were encountered: