-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
proper subtyping/LUB/GLB for region fn types #2263
Comments
In fact the inference is wrong. We need to adjust our handling of functions and we need to correctly implement the algorithm for handling this sort of thing---
|
One important point: how do we handle GLB/LUB computations? |
@nikomatsakis suggested this as a starter project, so I'm assigning to myself... |
Some notes on what I'm doing for this: https://github.com/mozilla/rust/wiki/Bikeshed-function-subtyping-wrt-regions |
also: remove "auto-mode-matching" for implemented interfaces, as it is complex and interacts poorly with classes cc #2263
#2981 will help with this. |
This is becoming more problematic as demoding proceeds. I have flagged some of the awkward spots in the code that would benefit from having this bug fixed with FIXMEs. |
Fixes rust-lang#1896 which was never truly fixed, just masked. The given tests would have failed had they used `~fn()` and not `@fn()`. They now result in compilation errors. Fixes rust-lang#2978. Necessary first step for rust-lang#2202, rust-lang#2263.
This situation is not perfect but I am going to close the issue for now. It's working well enough for the time being. |
Update measureme to the latest version The major version number is different due to changes to the on-disk recording format but the core API is the same and miri continues to build on the latest version.
It occurs to me that our universal quantification step rather expects to know the type which is being universally quantified. But, in some cases, there may be variables present in this type. I am specifically concerned about inference of the parameter types for fn expressions. It's possible that we do something wrong there, though I can't say specifically what, so this issue is kind of a mental note to come back to this and think about it.
The text was updated successfully, but these errors were encountered: