-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Block type-inference sometimes fails #912
Comments
The problem is that in order to typecheck the block, we need to figure out what f is. We currently use the hack of checking all of the none block arguments in a function call before checking the block arguments. I spent some time looking into this. The way that MLton deals with the similar problem in inferring functions that use SML flex-records is that it gives f a flexible record type that tracks the fields you know to be in the record. And then I think when it comes time to generalize the type variable, you require that the flex record be fully resolved (which would happen by unifying it with a non-flex record type). Unfortunately, autoderef screws that up some... |
Still doesn't work. |
Still a bug, 6/21/2012. |
Still a bug, 7/26/2012. |
Is this something we intend to fix? |
Because I think really fixing it requires getting rid of all of the places where we demand to know the type (or the first level of the type) of something. |
I don't believe this issue will ever be fixed. This amounts to restructuring the inference to have much more complex constraints like "a type that auto-derefs to something with a field f" and so forth. It would be more-or-less equivalent, I guess, to defering analysis of any particular expression when insufficient information is available and then re-checking until we reach a fixed point. Of course you wouldn't implement it like that, but whatever you did it would not be H-M nor even, really, inspired by H-M. I'm just going to close. |
This was marked xfail-test According to rust's issue rust-lang#912, this will not be fixed. There's no point in keeping the test if it is never intended to pass.
According to rust's issue #912, this will not be fixed. There's no point in keeping the test if it is never intended to pass.
Bumps [quote](https://github.com/dtolnay/quote) from 1.0.2 to 1.0.3. - [Release notes](https://github.com/dtolnay/quote/releases) - [Commits](dtolnay/quote@1.0.2...1.0.3) Signed-off-by: dependabot-preview[bot] <support@dependabot.com> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
The follow code fails with
If I move the
+=
statement above the call to find, it typechecks. Maybe this is a fundamental limitation of our typechecker, but it looks like it could be worked around by delaying the error until all constraints in a function have been collected.The text was updated successfully, but these errors were encountered: