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

miri: accept extern types in structs if they are the only field #55672

Merged
merged 6 commits into from
Nov 19, 2018
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions src/librustc_mir/interpret/eval_context.rs
Original file line number Diff line number Diff line change
Expand Up @@ -371,8 +371,19 @@ impl<'a, 'mir, 'tcx: 'mir, M: Machine<'a, 'mir, 'tcx>> EvalContext<'a, 'mir, 'tc
// the last field). Can't have foreign types here, how would we
// adjust alignment and size for them?
let field = layout.field(self, layout.fields.count() - 1)?;
let (unsized_size, unsized_align) = self.size_and_align_of(metadata, field)?
.expect("Fields cannot be extern types");
let (unsized_size, unsized_align) = match self.size_and_align_of(metadata, field)? {
Some(size_and_align) => size_and_align,
None => {
// A field with extern type. If this field is at offset 0 and the sized
// part makes no alignment constraints, we behave like the underlying
// extern type.
if sized_size == Size::ZERO && sized_align.abi() == 1 {
return Ok(None)
} else {
bug!("Fields cannot be extern types, unless they are at offset 0")
}
}
};

// FIXME (#26403, #27023): We should be adding padding
// to `sized_size` (to accommodate the `unsized_align`
Expand Down
3 changes: 2 additions & 1 deletion src/librustc_mir/interpret/place.rs
Original file line number Diff line number Diff line change
Expand Up @@ -354,7 +354,8 @@ where
let (meta, offset) = if field_layout.is_unsized() {
// re-use parent metadata to determine dynamic field layout
let (_, align) = self.size_and_align_of(base.meta, field_layout)?
.expect("Fields cannot be extern types");
// If this is an extern type, we fall back to its static size and alignment.
.unwrap_or_else(|| base.layout.size_and_align());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interestingly, we can make size_and_align_of error, but have a separate align_of that works even for extern type. Only the alignment is used here, anyway!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, you can also just move the Option to be around the size, but not the alignment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could, but I'd rather wait for the decision to treat the size_of_val and align_of_val intrinsics asymmetrically before doing that.

extern type will likely get alignment 1 currently, which is likely not actually correct for the type they are opaquely representing, so I am a bit worried about unilaterally implementing such behavior.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't access that alignment without first having a reference, so having it too high would be a problem (the assumption might not be guaranteed by what you're FFI-ing to), but having it too low wouldn't break anything (other than field offsets).

So the way I see it, the alignment is only a lower bound, and 1 is fine, unless you want to use it as an aligned field in a struct.

Anyway, my concern is also kind of a confusing code thing.
You could also add a .map(|(_, align)| align) before unwrap_or_else, which would mean the code and the comment wouldn't mention the "size" of the extern type.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't access that alignment without first having a reference, so having it too high would be a problem (the assumption might not be guaranteed by what you're FFI-ing to), but having it too low wouldn't break anything (other than field offsets).

Oh that's a good point. We cannot create such references ourselves anyway as we cannot have data of that type.

Still I think miri shouldn't move ahead of the rest of the decision process here.

I will implement your map suggestion.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I implemented what you suggested.

(base.meta, offset.abi_align(align))
} else {
// base.meta could be present; we might be accessing a sized field of an unsized
Expand Down
21 changes: 21 additions & 0 deletions src/test/ui/consts/const-eval/issue-55541.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
// compile-pass

// Test that we can handle newtypes wrapping extern types

#![feature(extern_types, const_transmute)]

extern "C" {
pub type ExternType;
}
unsafe impl Sync for ExternType {}

#[repr(transparent)]
pub struct Wrapper(ExternType);
RalfJung marked this conversation as resolved.
Show resolved Hide resolved

static MAGIC_FFI_STATIC: u8 = 42;

pub static MAGIC_FFI_REF: &'static Wrapper = unsafe {
std::mem::transmute(&MAGIC_FFI_STATIC)
};

fn main() {}