Currently the spec says that the definitionScope field contains two fields, one of which is also called definitionScope. Could be intentional but looks like a mistake, especially given that later the section refers to them without specifying which one.
Just to make sure I understand the spec correctly: the name field is included to account for the fact that a type may be imported into a scope under a changed name? Maybe it should be said explicitly.
definingContract contains the name of the contract, but that contract must necessarily also exist as a type - why not include its type ID instead?
Regarding the question in the discussion note on definingFile.name: a value that makes sense there from Solidity standpoint is the source unit name. From compiler's standpoint the file may not even be present on disk and it tries to be FS-agnostic. As other compilers seem to support the Standard JSON format too, it would probably be best to identify files by source unit names present in that format.
Another value that makes sense would be the ID assigned to that file under sources in the Standard JSON output. That ID is (probably) also available in the AST. But that's less human-readable.
definitionScope
field contains two fields, one of which is also calleddefinitionScope
. Could be intentional but looks like a mistake, especially given that later the section refers to them without specifying which one.name
field is included to account for the fact that a type may be imported into a scope under a changed name? Maybe it should be said explicitly.definingContract
contains the name of the contract, but that contract must necessarily also exist as a type - why not include its type ID instead?definingFile.name
: a value that makes sense there from Solidity standpoint is the source unit name. From compiler's standpoint the file may not even be present on disk and it tries to be FS-agnostic. As other compilers seem to support the Standard JSON format too, it would probably be best to identify files by source unit names present in that format.sources
in the Standard JSON output. That ID is (probably) also available in the AST. But that's less human-readable.