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

Introduce semantic analysis #144

Closed
2 tasks done
lrlna opened this issue Jan 20, 2022 · 1 comment
Closed
2 tasks done

Introduce semantic analysis #144

lrlna opened this issue Jan 20, 2022 · 1 comment
Assignees
Labels
apollo-compiler issues/PRs pertaining to semantic analysis & validation

Comments

@lrlna
Copy link
Member

lrlna commented Jan 20, 2022

Context

apollo-parser provides users with an AST to programmatically derive information from any given GraphQL input. Although the parser runs lexical and syntactic analysis, we still cannot be certain that the input provided does not contain errors. To ensure that the input is entirely error free, apollo-rs’s compiler must also take into the account each input statement’s context. All of this will be done as part of semantic analysis.

There are two main goals of this task:

  1. Validate each statement in an input and ensure it contains no errors.
  2. Provide a user-facing API to context. To be able to 1. the compiler must build up knowledge and details about each statement’s context. This context, let's call it Source Database, is to be provided as an API.

High-level implementation details

  • Validation is to be separated out into two parts: document and type system validation. To unblock other Apollo teams, we will focus on query work first.
  • All statement validation requires knowledge/context awareness. This will manifest itself as accessor methods to the Source Database. These will be the basis of queries, a user-facing API for Source Database, which will be backed by salsa-rs. The queries are to be expanded based on the information needed overtime for validation or usage purposes. Examples information includes:
    • “get all fragment names in a given query”,
    • “get all arguments defined by a given operation definition”,
    • “is this variable used in a given query already defined?”,
    • "what is the type of the current node?",
    • "given this type, what are its subtypes?".
  • In the process of validation, we might have to do some processing, or normalisation (e.g. processing StringValue). This should not modify the original AST, but should modify the string values in Source Database.
  • Initial validation work will focus on whether an node is semantically correct, and produce semantic errors. As per apollo-rs error-resilience philosophy, semantic errors will be returned alongside The next stage for diagnostics work is to additionally create warnings, hints and suggestions.
  • Diagnostics will be divided into: errors, warnings, hints and suggestions. Hints and suggestions will be an addition to the errors and warnings created.

Current task list:

@lrlna
Copy link
Member Author

lrlna commented May 12, 2023

🙏 compleeeteee

@lrlna lrlna closed this as completed May 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apollo-compiler issues/PRs pertaining to semantic analysis & validation
Projects
None yet
Development

No branches or pull requests

1 participant