Skip to content
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

Fix `-Z print-type-sizes`'s handling of zero-sized fields. #67215

Merged

Conversation

@nnethercote
Copy link
Contributor

nnethercote commented Dec 11, 2019

Currently, the type struct S { x: u32, y: u32, tag: () } is
incorrectly described like this:

print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size     field `.x`: 4 bytes
print-type-size     field `.tag`: 0 bytes, offset: 0 bytes, alignment: 1 bytes
print-type-size     padding: 4 bytes
print-type-size     field `.y`: 4 bytes, alignment: 4 bytes

Specifically:

  • The padding line is wrong. (There is no padding.)
  • The offset and alignment on the .tag line shouldn't be printed.

The problem is that multiple fields can end up with the same offset, and
the printing code doesn't handle this correctly.

This commit fixes it by adjusting the field sorting so that zero-sized fields
are dealt with before non-zero-sized fields. With that in place, the
printing code works correctly.

The commit also corrects the "something is very wrong" comment.

The new output looks like this:

print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size     field `.tag`: 0 bytes
print-type-size     field `.x`: 4 bytes
print-type-size     field `.y`: 4 bytes

r? @pnkfelix

Currently, the type `struct S { x: u32, y: u32, tag: () }` is
incorrectly described like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size     field `.x`: 4 bytes
print-type-size     field `.tag`: 0 bytes, offset: 0 bytes, alignment: 1 bytes
print-type-size     padding: 4 bytes
print-type-size     field `.y`: 4 bytes, alignment: 4 bytes
```
Specifically:
- The `padding` line is wrong. (There is no padding.)
- The `offset` and `alignment` on the `.tag` line shouldn't be printed.

The problem is that multiple fields can end up with the same offset, and
the printing code doesn't handle this correctly.

This commit fixes it by adjusting the field sorting so that zero-sized fields
are dealt with before non-zero-sized fields. With that in place, the
printing code works correctly.

The commit also corrects the "something is very wrong" comment.

The new output looks like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size     field `.tag`: 0 bytes
print-type-size     field `.x`: 4 bytes
print-type-size     field `.y`: 4 bytes
```
@nnethercote

This comment has been minimized.

Copy link
Contributor Author

nnethercote commented Dec 11, 2019

The real-world type that I encountered this on was Pointer. I mistakenly thought it was 24 bytes until just now; it's really 16 bytes.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Dec 11, 2019

great catch!

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Dec 11, 2019

@bors r+ rollup

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 11, 2019

📌 Commit c681841 has been approved by pnkfelix

JohnTitor added a commit to JohnTitor/rust that referenced this pull request Dec 12, 2019
…ro-sized-fields, r=pnkfelix

Fix `-Z print-type-sizes`'s handling of zero-sized fields.

Currently, the type `struct S { x: u32, y: u32, tag: () }` is
incorrectly described like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size     field `.x`: 4 bytes
print-type-size     field `.tag`: 0 bytes, offset: 0 bytes, alignment: 1 bytes
print-type-size     padding: 4 bytes
print-type-size     field `.y`: 4 bytes, alignment: 4 bytes
```
Specifically:
- The `padding` line is wrong. (There is no padding.)
- The `offset` and `alignment` on the `.tag` line shouldn't be printed.

The problem is that multiple fields can end up with the same offset, and
the printing code doesn't handle this correctly.

This commit fixes it by adjusting the field sorting so that zero-sized fields
are dealt with before non-zero-sized fields. With that in place, the
printing code works correctly.

The commit also corrects the "something is very wrong" comment.

The new output looks like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size     field `.tag`: 0 bytes
print-type-size     field `.x`: 4 bytes
print-type-size     field `.y`: 4 bytes
```
r? @pnkfelix
bors added a commit that referenced this pull request Dec 12, 2019
Rollup of 8 pull requests

Successful merges:

 - #62514 (Clarify `Box<T>` representation and its use in FFI)
 - #66983 (Fix `unused_parens` triggers on macro by example code)
 - #67215 (Fix `-Z print-type-sizes`'s handling of zero-sized fields.)
 - #67230 (Remove irelevant comment on `register_dtor`)
 - #67236 (resolve: Always resolve visibilities on impl items)
 - #67237 (Some small readability improvements)
 - #67238 (Small std::borrow::Cow improvements)
 - #67239 (Make TinyList::remove iterate instead of recurse)

Failed merges:

r? @ghost
@bors bors merged commit c681841 into rust-lang:master Dec 12, 2019
4 checks passed
4 checks passed
pr #20191211.5 succeeded
Details
pr (Linux mingw-check) Linux mingw-check succeeded
Details
pr (Linux x86_64-gnu-llvm-7) Linux x86_64-gnu-llvm-7 succeeded
Details
pr (Linux x86_64-gnu-tools) Linux x86_64-gnu-tools succeeded
Details
@nnethercote nnethercote deleted the nnethercote:fix-Zprint-type-size-zero-sized-fields branch Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.