-
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
Cell is unsound around variance #11385
Comments
part of #3598 |
this is the surprising function, really:
Clearly this function ought not to type check. I'm not sure if this is due to some interaction with variance inference or something else, though I seem to recall another similar bug. I'll try to find some time to dig into this a bit. |
i attempted converting this to not use cell:
and, as @pcwalton predicted, it wouldn't compile:
but i don't understand why changing the mutability affects how the lifetime inference behaves. |
Accepted for 1.0, P-backcompat-lang. |
Indeed inference is incorrect yielding contravariant for |
Ah! I understand why. Interesting. Actually the inference is CORRECT, but it is being fed incorrect information. It does not know that cell mutates its value and thus is invariant. I had assumed this would be ok as we are generally invariant (right now, anyway) with respect to all type parameters, but the inference in fact computes variance correctly, and thus infers that Option and Cell are covariant with respect to their type parameter. It's just that the type system enforces a stricter standard. I remember thinking that this would be sound, but of course it's not when we haven't added proper variance notations to types like Cell. That is work which is overdue and fairly straightforward, so I'll try to do it. In some sense this is thus a dup of #10834 but I will leave it open since it reflects a specific failure we should test for. |
skip float_cmp check if lhs is a custom type *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: [`float_cmp`]: allow float eq comparison when lhs is a custom type that implements PartialEq<f32/f64> If the lhs of a comparison is not float, it means there is a user implemented PartialEq, and the caller is invoking that custom version of `==`, instead of the default floating point equal comparison. People may wrap f32 with a struct (say `MyF32`) and implement its PartialEq that will do the `is_close()` check, so that `MyF32` can be compared with either f32 or `MyF32`.
The following creates a dangling pointer to an outer stack frame:
This manifested as a rustc segfault.
The text was updated successfully, but these errors were encountered: