Uh oh!
There was an error while loading. Please reload this page.
Make accesses to fields of packed structs unsafe - #44884
Conversation
rust-highfive
commented
Sep 27, 2017
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
arielb1
commented
Sep 27, 2017
r? @eddyb |
eddyb
commented
Sep 27, 2017
LGTM. cc @rust-lang/compiler |
CI failure is due to The relevant Dependency tree:
Details |
arielb1
commented
Sep 27, 2017
The error is correct - calling |
pnkfelix
commented
Oct 2, 2017
@arielb1 do you know if the now merged update to kuchiki mean we should re-do a travis run on this? |
51e8c00 to
4ec62e4Comparearielb1
commented
Oct 2, 2017
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? |
arielb1
commented
Oct 2, 2017
@bors try |
bors
commented
Oct 2, 2017
[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
bors
commented
Oct 2, 2017
☀️ Test successful - status-travis |
Mark-Simulacrum
commented
Oct 3, 2017
Cargobomb run started. |
carols10cents
commented
Oct 9, 2017
@Mark-Simulacrum has the cargobomb run completed on this? |
Mark-Simulacrum
commented
Oct 10, 2017
Cargobomb complete: http://cargobomb-reports.s3.amazonaws.com/pr-44884/index.html |
arielb1
commented
Oct 12, 2017
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)]structHashmapEntry<V>{// 1 bit occupied and 63 bit hashstate: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 |
arielb1
commented
Oct 12, 2017
I think the |
bors
commented
Oct 13, 2017
☔ The latest upstream changes (presumably #45013) made this pull request unmergeable. Please resolve the merge conflicts. |
arielb1
commented
Nov 26, 2017
r? @eddyb - the last commit is new and non-trivial |
nrc
commented
Nov 26, 2017
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. |
eddyb
commented
Nov 27, 2017
@bors r=nikomatsakis,eddyb |
bors
commented
Nov 27, 2017
📌 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
bors
commented
Nov 27, 2017
bors
commented
Nov 27, 2017
☀️ 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 inderivethe same way I did inSpan, and use derive there again