-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Introduce a T_err type for type errors #1871
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
Comments
An alternative might be to try and avoid reporting derived errors. In this case, for example, the second error occurs because we assign the type of unit to undefined fields (I think that was my fault, but I'm not sure). It would be perhaps nicer to assign a special type (T_err or some such) indicating a compile-time error and then not report type errors that relate to T_err. |
That would also be totally plausible in this case! I think a similar situation might come up with user-generated errors and so the approach I suggested would be more general, but I can't think of an example right now. |
Assigning ty_bot should actually also work -- that unifies with everything. (Though it'll probably add spurious unreachable statement warnings that have to somehow be suppressed.) |
#1504 outlines another possible solution. |
Since no one has jumped on this, I'd like to fix it when I get a chance... but I don't know when that will be. |
This allows more errors to be non-fatal, as per rust-lang#1871. I only went through and started changing span_fatal to span_err in check.rs. There are probably more errors that could be made non-fatal.
Done, pending review. |
Glad to see progress on this! |
If I compile this code, I get two error messages for (basically) the same span:
This kind of thing gets annoying fast. Would it be reasonable to only print an error message for the smallest sub-span when there are multiple error messages such that one span encloses the other? (In this case, the spans aren't exactly the same, but we should see the first error and realize "oh, we don't need to print out the second error, since its span is a superspan of the other")
The text was updated successfully, but these errors were encountered: