-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Make typechecker compositional #5461
Conversation
The typechecker previously passed around a boolean return flag to indicate whether it saw something with type _|_ (that is, something it knows at compile-time will definitely diverge) and also had some manual checks for the `ty_err` pseudo-type that represents a previous type error. This was because the typing rules implemented by the typechecker didn't properly propagate _|_ and ty_err. I fixed it. This also required changing expected error messages in a few tests, as now we're printing out fewer derived errors -- in fact, at this point we should print out no derived errors, so report any that you see (ones that include "[type error]") as bugs.
Tim---this basically looks great! I didn't read it through in utmost detail, more skimmed over. This seems prone to fast bitrot so I thought it better to give r+ now and we can refine later. One improvement I would like is if you would modify the comment in typeck/check/mod.rs (or create one on |
@nikomatsakis No, that's not the invariant -- I wanted it to be, but wasn't able to implement it because if I tried to change |
Added a comment -- @nikomatsakis r? just to make sure I was clear. |
r? @nikomatsakis The typechecker previously passed around a boolean return flag to indicate whether it saw something with type _|_ (that is, something it knows at compile-time will definitely diverge) and also had some manual checks for the `ty_err` pseudo-type that represents a previous type error. This was because the typing rules implemented by the typechecker didn't properly propagate _|_ and ty_err. I fixed it. This also required changing expected error messages in a few tests, as now we're printing out fewer derived errors -- in fact, at this point we should print out no derived errors, so report any that you see (ones that include "[type error]") as bugs.
…st, r=matthiaskrgr Temporarily disable rustfmt integration test Running rustfmt from master is currently broken and [fails our bors build](https://github.com/rust-lang/rust-clippy/runs/582066368#step:10:19): rust-lang#71077 changelog: none
r? @nikomatsakis The typechecker previously passed around a boolean return flag to
indicate whether it saw something with type | (that is, something
it knows at compile-time will definitely diverge) and also had some
manual checks for the
ty_err
pseudo-type that represents a previoustype error. This was because the typing rules implemented by the
typechecker didn't properly propagate | and ty_err. I fixed it.
This also required changing expected error messages in a few tests,
as now we're printing out fewer derived errors -- in fact, at this
point we should print out no derived errors, so report any that
you see (ones that include "[type error]") as bugs.