-
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
Make accesses to fields of packed structs unsafe #44884
Conversation
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
r? @eddyb |
LGTM. cc @rust-lang/compiler |
CI failure is due to The relevant Dependency tree:
|
The error is correct - calling |
@arielb1 do you know if the now merged update to kuchiki mean we should re-do a travis run on this? |
51e8c00
to
4ec62e4
Compare
Code is green. Can we have a crater run to see whether we break the world before I go make this a future-compat warning? |
@bors try |
[WIP] make accesses to fields of packed structs unsafe To handle packed structs with destructors (which you'll think are a rare case, but the `#[repr(packed)] struct Packed<T>(T);` pattern is ever-popular, which requires handling packed structs with destructors to avoid monomorphization-time errors), drops of subfields of packed structs should drop a local move of the field instead of the original one. That's it, I think I'll use a strategy suggested by @Zoxc, where this mir ``` drop(packed_struct.field) ``` is replaced by ``` tmp0 = packed_struct.field; drop tmp0 ``` cc #27060 - this should deal with that issue after codegen of drop glue is updated. The new errors need to be changed to future-compatibility warnings, but I'll rather do a crater run first with them as errors to assess the impact. cc @eddyb Things which still need to be done for this: - [ ] - handle `repr(packed)` structs in `derive` the same way I did in `Span`, and use derive there again - [ ] - implement the "fix packed drops" pass and call it in both the MIR shim and validated MIR pipelines - [ ] - do a crater run - [ ] - convert the errors to compatibility warnings
☀️ Test successful - status-travis |
Cargobomb run started. |
@Mark-Simulacrum has the cargobomb run completed on this? |
Cargobomb complete: http://cargobomb-reports.s3.amazonaws.com/pr-44884/index.html |
This appears to be quite a problem, we have 31 root regressions. Summary: |
There are a few common types of regressions: One easily-fixed case is The other annoying one is #[derive(Clone, Copy, Default)]
#[repr(C, packed)]
struct HashmapEntry<V> {
// 1 bit occupied and 63 bit hash
state: u64,
value: V,
} The Debug & Clone impls are currently UB, and I don't see a good way of fixing them except for either removing the |
I think the |
☔ The latest upstream changes (presumably #45013) made this pull request unmergeable. Please resolve the merge conflicts. |
r? @eddyb - the last commit is new and non-trivial |
Rustfmt is fixed by #46144, I was waiting for this to land, but it looks like it is taking longer than expected. Since 46144 is ready to go and fixes the RLS which is currently broken, I want to land it sooner rather than later. Assuming it lands first (which it should) could you remove the 'mark rustfmt as broken' commit here since it shouldn't be needed. |
@bors r=nikomatsakis,eddyb |
📌 Commit f3b2d7f has been approved by |
Make accesses to fields of packed structs unsafe To handle packed structs with destructors (which you'll think are a rare case, but the `#[repr(packed)] struct Packed<T>(T);` pattern is ever-popular, which requires handling packed structs with destructors to avoid monomorphization-time errors), drops of subfields of packed structs should drop a local move of the field instead of the original one. That's it, I think I'll use a strategy suggested by @Zoxc, where this mir ``` drop(packed_struct.field) ``` is replaced by ``` tmp0 = packed_struct.field; drop tmp0 ``` cc #27060 - this should deal with that issue after codegen of drop glue is updated. The new errors need to be changed to future-compatibility warnings, but I'll rather do a crater run first with them as errors to assess the impact. cc @eddyb Things which still need to be done for this: - [ ] - handle `repr(packed)` structs in `derive` the same way I did in `Span`, and use derive there again - [ ] - implement the "fix packed drops" pass and call it in both the MIR shim and validated MIR pipelines - [ ] - do a crater run - [ ] - convert the errors to compatibility warnings
☀️ Test successful - status-appveyor, status-travis |
That commit had accidentally snuck in into rust-lang#44884. Revert it. This reverts commit c48650e.
To handle packed structs with destructors (which you'll think are a rare
case, but the
#[repr(packed)] struct Packed<T>(T);
pattern isever-popular, which requires handling packed structs with destructors to
avoid monomorphization-time errors), drops of subfields of packed
structs should drop a local move of the field instead of the original
one.
That's it, I think I'll use a strategy suggested by @Zoxc, where this mir
is replaced by
cc #27060 - this should deal with that issue after codegen of drop glue
is updated.
The new errors need to be changed to future-compatibility warnings, but
I'll rather do a crater run first with them as errors to assess the
impact.
cc @eddyb
Things which still need to be done for this:
repr(packed)
structs inderive
the same way I did inSpan
, and use derive there again