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

shorten expectations list #810

Open
OmarTawfik opened this issue Feb 13, 2024 · 0 comments
Open

shorten expectations list #810

OmarTawfik opened this issue Feb 13, 2024 · 0 comments
Assignees

Comments

@OmarTawfik
Copy link
Collaborator

OmarTawfik commented Feb 13, 2024

Instead of something like this:

Error: Expected AddressKeyword or AsciiStringLiteral or AssemblyKeyword or BoolKeyword or BreakKeyword or ByteKeyword or CloseBrace or ContinueKeyword or DecimalLiteral or DeleteKeyword or DoKeyword or FalseKeyword or FixedBytesType or ForKeyword or FunctionKeyword or HexLiteral or HexStringLiteral or Identifier or IfKeyword or MappingKeyword or NewKeyword or OpenBrace or OpenBracket or OpenParen or PayableKeyword or ReturnKeyword or SignedFixedType or SignedIntegerType or StringKeyword or ThrowKeyword or TrueKeyword or UnsignedFixedType or UnsignedIntegerType or VarKeyword or WhileKeyword.

We can add a flag (e.g. error_recovery = (override_children_expectations: bool)) to StructItem and EnumItem and other non-terminal items .. When any item fails to parse its children, and only when the error position has made no progress in input stream, we replace the current "expectations list" of children kinds with the current parent kind only, propagating it up the stack. This leads to nicer errors like:

  • Error: Expected Expression or Statement.
  • Error: Expected Modifier or FunctionAttribute.

Open Questions

  • Should this behaviour be enabled by default, and only disabled where needed? which is the better DX here?
  • Do we even need a flag here? can we enable this for all enums for now? does this miss anything?
@OmarTawfik OmarTawfik assigned OmarTawfik and Xanewok and unassigned OmarTawfik Feb 20, 2024
@Xanewok Xanewok removed their assignment May 17, 2024
@OmarTawfik OmarTawfik self-assigned this May 27, 2024
@OmarTawfik OmarTawfik assigned OmarTawfik and unassigned OmarTawfik Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ⏳ Todo
Development

No branches or pull requests

2 participants