Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarifications on definitionScope #27

Open
cameel opened this issue Apr 19, 2023 · 0 comments
Open

Clarifications on definitionScope #27

cameel opened this issue Apr 19, 2023 · 0 comments
Assignees

Comments

@cameel
Copy link
Contributor

cameel commented Apr 19, 2023

  • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants