-
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
[WIP] Move pointee_info_at to TyLayoutMethods. #57150
Conversation
The original implementation is still present at librustc_codegen_llvm/abi.rs, should be removed later to prevent code duplication.
Uh I'm sorry don't think I can review this. I don't know this code. r? @eddyb |
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.
Just a preliminary review.
Looks generally alright to me, can you start changing all the previous calls to pointee_info_at
to this method and remove the old one?
Co-Authored-By: wildarch <[email protected]>
An associated type ParamEnv has been added to TyLayoutMethods to facilitate this.
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Ping from triage @eddyb / @rust-lang/complier: This PR requires your review. |
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 comment
The reason will be displayed to describe this comment to others. Learn more.
Each method in this trait needs a "forwarding" wrapper in the impl
just below, the trait should never be used otherwise, only implemented.
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.
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 TyLayoutMethods
trait?
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.
Sure. We have to implement the trait on the Ty
(e.g. rustc::ty::Ty<'tcx>
), but the functionality should be available as method syntax on TyLayout<Ty>
.
If we make TyLayout<Ty>
Deref
to Ty
, we can use self
instead of this
and have the trait directly callable.
But it already Deref
s to LayoutDetails
, sadly.
My immediate reaction is that @oli-obk Note that we never pass rust/src/librustc/ty/layout.rs Lines 203 to 206 in f40aaa6
or: rust/src/librustc_mir/interpret/eval_context.rs Lines 168 to 169 in f40aaa6
So I think what is needed is to add a trait that contains rust/src/librustc/ty/layout.rs Lines 1599 to 1602 in f40aaa6
|
☔ The latest upstream changes (presumably #58254) made this pull request unmergeable. Please resolve the merge conflicts. |
ping from triage @wildarch you need to reply to the review and make necessary changes. Also you have conflicts to attend to. |
@Dylan-DPC I have been a bit preoccupied as of late 😅, but I should have some time this weekend to attend to this. Thanks for the heads-up! 😄 |
I feel like a trait just for pub trait HasParamEnv {
fn param_env(&self) -> ParamEnv
} And then put that as an additional bound on Then I think I should be able to remove the |
@@ -1497,6 +1499,7 @@ impl<'gcx, 'tcx, T: HasTyCtxt<'gcx>> HasTyCtxt<'gcx> for LayoutCx<'tcx, T> { | |||
pub trait MaybeResult<T> { |
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
, that Err
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
and to_result
for MaybeResult
?
And in
x.map_same(f) -> MaybeResult::from(x.to_result().map(f))
In this x
should have a to_result
method. But in our case TyLayout
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 a std::convert::From
impl.
to_result
should be a method, yes.
x.map_same(f) -> MaybeResult::from(x.to_result().map(f))
In this x should have a to_result method. But in our case TyLayout has no such method.
x
is a MaybeResult
, so it will have the to_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
for MaybeResult
like this:
impl From<TyLayout<'tcx>> for dyn MaybeResult<TyLayout<'tcx>, Item=!> {
fn from(ty: TyLayout<'tcx>) -> dyn MaybeResult<TyLayout<'tcx>, Item=!> {
ty
}
}
Getting some issues:
error[E0277]: the size for values of type `(dyn ty::layout::MaybeResult<rustc_target::abi::TyLayout<'tcx, &'tcx ty::TyS<'tcx>>, Item = !> + 'static)` cannot be known at compilation time
--> src/librustc/ty/layout.rs:1495:6
|
1495 | impl From<TyLayout<'tcx>> for dyn MaybeResult<TyLayout<'tcx>, Item=!> {
| ^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
|
= help: the trait `std::marker::Sized` is not implemented for `(dyn ty::layout::MaybeResult<rustc_target::abi::TyLayout<'tcx, &'tcx ty::TyS<'tcx>>, Item = !> + 'static)`
= note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
error[E0038]: the trait `ty::layout::MaybeResult` cannot be made into an object
--> src/librustc/ty/layout.rs:1495:6
|
1495 | impl From<TyLayout<'tcx>> for dyn MaybeResult<TyLayout<'tcx>, Item=!> {
| ^^^^^^^^^^^^^^^^^^^^ the trait `ty::layout::MaybeResult` cannot be made into an object
|
= note: method `from_ok` has no receiver
= note: method `map_same` references the `Self` type in its arguments or return type
error[E0038]: the trait `ty::layout::MaybeResult` cannot be made into an object
--> src/librustc/ty/layout.rs:1496:5
|
1496 | fn from(ty: TyLayout<'tcx>) -> dyn MaybeResult<TyLayout<'tcx>, Item=!> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `ty::layout::MaybeResult` cannot be made into an object
|
= note: method `from_ok` has no receiver
= note: method `map_same` references the `Self` type in its arguments or return type
error: aborting due to 3 previous errors
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 of MaybeResult
.
This will end up requiring that all implementors of MaybeResult
also implement From
, not sure how well that works with the T
impl
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 am trying something like this:
pub trait MaybeResult<'tcx, T>: From<TyLayout<'tcx>> {
type Item;
fn from_ok(x: T) -> Self;
fn map_same<F: FnOnce(T) -> T>(self, f: F) -> Self;
fn to_result(self) -> Result<T, Self::Item>;
}
impl<'tcx, T: From<TyLayout<'tcx>>> MaybeResult<'tcx, T> for T {
type Item = !;
fn from_ok(x: T) -> Self {
x
}
fn map_same<F: FnOnce(T) -> T>(self, f: F) -> Self {
f(self)
}
fn to_result(self) -> Result<T, !> {
Ok(self)
}
}
impl<'tcx, T, E> MaybeResult<'tcx, T> for Result<T, E> {
type Item = E;
fn from_ok(x: T) -> Self {
Ok(x)
}
fn map_same<F: FnOnce(T) -> T>(self, f: F) -> Self {
self.map(f)
}
fn to_result(self) -> Result<T, E> {
self
}
}
This is the fallout:
error[E0277]: the trait bound `std::result::Result<T, E>: std::convert::From<rustc_target::abi::TyLayout<'tcx, &'tcx ty::TyS<'tcx>>>` is not satisfied
--> src/librustc/ty/layout.rs:1517:18
|
1517 | impl<'tcx, T, E> MaybeResult<'tcx, T> for Result<T, E> {
| ^^^^^^^^^^^^^^^^^^^^ the trait `std::convert::From<rustc_target::abi::TyLayout<'tcx, &'tcx ty::TyS<'tcx>>>` is not implemented for `std::result::Result<T, E>`
error: aborting due to previous error
Should we implement From
for Result
? 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:
pub trait MaybeResult<T> {
type Err;
fn from(r: Result<T, Self::Err>) -> Self;
fn to_result(self) -> Result<T, Self::Err>;
}
We can't use the From
trait because T
doesn't implement From<Result<T, !>>
(nor does Result<T, !>
implement Into<T>
).
@wildarch Sure, either way should work fine. Note that |
Ping from triage @wildarch, any progress? |
@Centril I have been really busy lately, so I have not had much time to look at this. I will try to find more time to continue the PR, but honestly it might be better if someone else would take over the responsibility of finishing this. Sorry to keep you waiting 😢 |
I believe #60237 implemented this, so we can close the PR. Please reopen if I am wrong. |
Resolves #56166.
This moves the
pointee_info_at
fromrustc_codegen_llvm::type_of::LayoutLlvmExt
torustc::ty::layout::TyLayoutMethods
.This pull request is far from ready to be merged, and is only meant for an intermediate review. It will be expanded to a completely resolve #56166.
r? @eddyb