Errors and warnings #941
Labels
Comments
flavorjones
added a commit
to flavorjones/yarp
that referenced
this issue
Sep 7, 2023
The parser now passes around `yp_diagnostic_id_t` for diagnostic messages instead of character strings, and we rely on the function `diagnostic_message()` to resolve that to a string. In addition, many messages were edited so that the parser expresses coordinate ideas in similar form [1] using consistent voice and typographic conventions. Closes ruby#1379, and makes progress on ruby#941. [1] Strunk & White rule 19
flavorjones
added a commit
to flavorjones/yarp
that referenced
this issue
Sep 7, 2023
The parser now passes around `yp_diagnostic_id_t` for diagnostic messages instead of character strings, and we rely on the function `diagnostic_message()` to resolve that to a string. In addition, many messages were edited so that the parser expresses coordinate ideas in similar form [1] using consistent voice and typographic conventions. Closes ruby#1379, and makes progress on ruby#941. [1] Strunk & White rule 19
flavorjones
added a commit
to flavorjones/yarp
that referenced
this issue
Sep 7, 2023
The parser now passes around `yp_diagnostic_id_t` for diagnostic messages instead of character strings, and we rely on the function `diagnostic_message()` to resolve that to a string. In addition, many messages were edited so that the parser expresses coordinate ideas in similar form [1] using consistent voice and typographic conventions. Closes ruby#1379, and makes progress on ruby#941. [1] Strunk & White rule 19
|
Closing this for now since we now have |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've been relatively slapdash with the language used in our errors and warnings so far. Before we release v1 of this, I'd like to get the language, voice, and capitalization consistent.
Something I'd be interested in doing is having more structure with our errors. At the moment the strings are baked directly into the source and they're scattered all over the place. We don't have any kind of interpolation/formatting on them because we haven't had to yet, but it would be nice to have more details in them. For example, we have one error that reads
"Can't set variable". It would be nice to have at minimum{ message: "Setting the {{name}} variable is invalid.", name: (0...5) }.Part of this work is also to enumerate all of the errors and warnings in the CRuby parser to ensure that we have all of them covered in YARP. Effectively the existing parser errors and warnings should be a strict subset of YARP's.
One possible solution would be to put all of the error messages into
config.ymlor another YAML file and template out a struct similar to our nodes. This would allow us to put names to the errors, which I like a lot because tools that consume these errors would no longer need to rely on the specific message which is pretty brittle. For example, in IRB (https://github.com/ruby/irb/blob/625f759ca8fbee6d8a248c6b924165b16453fa48/lib/irb/ruby-lex.rb#L306-L351) it looks specifically at the messages being received. With classes it would be much simpler.Prior art in this area includes things like structured errors from TypeScript (https://github.com/yoavbls/pretty-ts-errors).
The text was updated successfully, but these errors were encountered: