For usages of implicitly available names that should be explicitly imported, we could include the location of (one of) the usages. That would make it quicker to debug stuff like #1.
For stale explicit import, we could include where that stale import is; this one wouldn't really be "proof" as the proof is that not only it exists, but it isn't used anywhere, and that's not a single line we can link to.
Relatedly, we should probably carve out some flexibility into the return types of the API so we can add more information later in a non-breaking way. E.g. for explicit_imports, instead of returning a list of submod => [ name => exporting_mod, ...], we could return a list of submod => [(; name, exporting_mod, ...), ...], and document that we may add fields to that NamedTuple.
For usages of implicitly available names that should be explicitly imported, we could include the location of (one of) the usages. That would make it quicker to debug stuff like #1.
For stale explicit import, we could include where that stale import is; this one wouldn't really be "proof" as the proof is that not only it exists, but it isn't used anywhere, and that's not a single line we can link to.
Relatedly, we should probably carve out some flexibility into the return types of the API so we can add more information later in a non-breaking way. E.g. for
explicit_imports, instead of returning a list ofsubmod => [ name => exporting_mod, ...], we could return a list ofsubmod => [(; name, exporting_mod, ...), ...], and document that we may add fields to that NamedTuple.