-
Notifications
You must be signed in to change notification settings - Fork 56
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
Refactor codegen error reporting #1031
Comments
I was playing around with codegen yesterday to try and move to the newer inkwell version and realized this would be a requirement. With the current inkwell version all builder methods are now results, and they fail if the builder is not setup correctly, which apparently was just being ignored in our usecase. |
I'm in favor of removing / not using |
Not with my refactor of the diagnostics =) , but I don't think thiserror will be needed in anycase |
Reopening this since I feel like we should wait for #1104 and futhermore ensure that
|
Is your refactor request related to a problem? Please describe.
Currently we have some lines making use of
map_err
in our codegen code. While this is not an issue per-se, it can remove the initial diagnostic with a somewhat less detailed diagnostic (and thus error message). For example take the following codeCompiling it, will return "Some initial values were not generated", however initially a
cannot_generate_string_literal
diagnostic is returned, which is remapped to acannot_generate_initializer
diagnostic removing the previous diagnostic (and any other codegen error is later remapped to acannot_generate_initializer
error anyways because of the pipeline here).Describe the solution you'd like
The given code should probably return the underlying root issue, namely a "Cannot generate String-Literal for type INT" error message (
cannot_generate_string_literal
). So either remapping diagnostics should maintain a referenceAdditional context
These remapping are only a problem because we map them to e.g. a
SyntaxError
which has no fields for references. One solution could be introducing aninitial: Option<Diagnostic>
field for all variants of the Diagnostics enum and on any remapping that field is "carried over".cc @ghaith : IIRC you're already working on something similar to this issue?
The text was updated successfully, but these errors were encountered: