-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
[WIP] Move pointee_info_at to TyLayoutMethods. #57150
Changes from 1 commit
15955b9
659ffb2
3d3d64f
e08d9cf
7cba55e
bb05cb8
3ce7a68
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -913,13 +913,40 @@ pub trait LayoutOf { | |
fn layout_of(&self, ty: Self::Ty) -> Self::TyLayout; | ||
} | ||
|
||
#[derive(Copy, Clone, PartialEq, Eq)] | ||
pub enum PointerKind { | ||
oli-obk marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/// Most general case, we know no restrictions to tell LLVM. | ||
Shared, | ||
|
||
/// `&T` where `T` contains no `UnsafeCell`, is `noalias` and `readonly`. | ||
Frozen, | ||
|
||
/// `&mut T`, when we know `noalias` is safe for LLVM. | ||
UniqueBorrowed, | ||
|
||
/// `Box<T>`, unlike `UniqueBorrowed`, it also has `noalias` on returns. | ||
UniqueOwned | ||
} | ||
|
||
#[derive(Copy, Clone)] | ||
pub struct PointeeInfo { | ||
pub size: Size, | ||
pub align: Align, | ||
pub safe: Option<PointerKind>, | ||
} | ||
|
||
pub trait TyLayoutMethods<'a, C: LayoutOf<Ty = Self>>: Sized { | ||
fn for_variant( | ||
this: TyLayout<'a, Self>, | ||
cx: &C, | ||
variant_index: VariantIdx, | ||
) -> TyLayout<'a, Self>; | ||
fn field(this: TyLayout<'a, Self>, cx: &C, i: usize) -> C::TyLayout; | ||
fn pointee_info_at( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Each method in this trait needs a "forwarding" wrapper in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, that should be easy to add 👍. As far as I could tell I am never actually using the trait directly, so that should be alright. Maybe you could give me some more details on the design decision here, so that I can leave it as a comment for the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure. We have to implement the trait on the If we make |
||
this: TyLayout<'a, Self>, | ||
cx: &C, | ||
offset: Size | ||
) -> Option<PointeeInfo>; | ||
} | ||
|
||
impl<'a, Ty> TyLayout<'a, Ty> { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize now that this is actually an isomorphism with
Result<T, Self::Err>
.In the case of
impl<T> MaybeResult<T> for T
, thatErr
associated type would be!
, which would make both conversions total.So the existing API could be replaced with:
MaybeResult::from_ok(x)
->MaybeResult::from(Ok(x))
x.map_same(f)
->MaybeResult::from(x.to_result().map(f))
x.ok()
->x.to_result().ok()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eddyb I am a bit confused here. Does this mean I have to create two methods
from
andto_result
forMaybeResult
?And in
In this
x
should have ato_result
method. But in our caseTyLayout
has no such method.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from
should be astd::convert::From
impl.to_result
should be a method, yes.x
is aMaybeResult
, so it will have theto_result
method.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oli-obk I am trying to implement
std::convert::From
forMaybeResult
like this:Getting some issues:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh... that was stupid of me. Sorry about that. It should suffice to add a
: From<TyLayout<'tcx>>
bound on the definition ofMaybeResult
.This will end up requiring that all implementors of
MaybeResult
also implementFrom
, not sure how well that works with theT
implThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oli-obk
I am trying something like this:
This is the fallout:
Should we implement
From
forResult
? Does not seem right.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not giving a full signature, I think I meant this:
We can't use the
From
trait becauseT
doesn't implementFrom<Result<T, !>>
(nor doesResult<T, !>
implementInto<T>
).