Skip to content

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Aug 25, 2021

This is a bit strange (potentially an ergonomic disaster, especially around errors, see below), but I decided to try and use the trait TyAbiInterface from #88337 to provide a single implementation of layout_of, tied to Ty<'tcx>, and usable with any context that provides:

  • TyCtxt, via HasTyCtxt
  • ParamEnv, via HasParamEnv
  • a way to transform LayoutErrors into the desired error type
    • an error type of ! can be paired with having cx.layout_of(...) return TyAndLayout without Result<...> around it, such as used by codegen
    • this is done through a new IsLayoutCx trait (and so is specifying the type of cx.layout_of(...))

Sadly, because of the generics involved, and Rust type-checking/inference limitations (mostly around autoderef and coercions), certain things that we took for granted change:

  • cx: &mut C doesn't autoderef in cx.layout_of(...), if only C: LayoutOf
    • I worked around this with blanket impls of the relevant traits on &mut _
  • cx.layout_of(ty: &Ty) doesn't coerce &Ty to Ty
    • theoretically I could've worked around this by implementing TyAbiInterface on &Ty, but I decided to fix the callsites instead

I doubt this change can be landed in its initial state (or at all), but since I did get it to work, I wanted to put it up.

@rust-highfive
Copy link
Contributor

Some changes occured to rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

@rust-highfive
Copy link
Contributor

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 25, 2021
eddyb referenced this pull request in eddyb/rust Aug 25, 2021
@nagisa
Copy link
Member

nagisa commented Aug 26, 2021

r? @nagisa

@rust-highfive rust-highfive assigned nagisa and unassigned cjgillot Aug 26, 2021
@bors

This comment has been minimized.

@eddyb eddyb force-pushed the layout-of-rerouting branch 2 times, most recently from a87e3c2 to 4cbc291 Compare August 29, 2021 21:48
@eddyb
Copy link
Member Author

eddyb commented Aug 30, 2021

Closing as superseded by #88499, which doesn't have the ergonomic downsides.

@eddyb eddyb closed this Aug 30, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 5, 2021
Provide `layout_of` automatically (given tcx + param_env + error handling).

After rust-lang#88337, there's no longer any uses of `LayoutOf` within `rustc_target` itself, so I realized I could move the trait to `rustc_middle::ty::layout` and redesign it a bit.

This is similar to rust-lang#88338 (and supersedes it), but at no ergonomic loss, since there's no funky `C: LayoutOf<Ty = Ty>` -> `Ty: TyAbiInterface<C>` generic `impl` chain, and each `LayoutOf` still corresponds to one `impl` (of `LayoutOfHelpers`) for the specific context.

After this PR, this is what's needed to get `trait LayoutOf` (with the `layout_of` method) implemented on some context type:
* `TyCtxt`, via `HasTyCtxt`
* `ParamEnv`, via `HasParamEnv`
* a way to transform `LayoutError`s into the desired error type
  * an error type of `!` can be paired with having `cx.layout_of(...)` return `TyAndLayout` *without* `Result<...>` around it, such as used by codegen
  * this is done through a new `LayoutOfHelpers` trait (and so is specifying the type of `cx.layout_of(...)`)

When going through this path (and not bypassing it with a manual `impl` of `LayoutOf`), the end result is that only the error case can be customized, the query itself and the success paths are guaranteed to be uniform.

(**EDIT**: just noticed that because of the supertrait relationship, you cannot actually implement `LayoutOf` yourself, the blanket `impl` fully covers all possible context types that could ever implement it)

Part of the motivation for this shape of API is that I've been working on querifying `FnAbi::of_*`, and what I want/need to introduce for that looks a lot like the setup in this PR - in particular, it's harder to express the `FnAbi` methods in `rustc_target`, since they're much more tied to `rustc` concepts.

r? `@nagisa` cc `@oli-obk` `@bjorn3`
flip1995 pushed a commit to flip1995/rust that referenced this pull request Sep 8, 2021
Provide `layout_of` automatically (given tcx + param_env + error handling).

After rust-lang#88337, there's no longer any uses of `LayoutOf` within `rustc_target` itself, so I realized I could move the trait to `rustc_middle::ty::layout` and redesign it a bit.

This is similar to rust-lang#88338 (and supersedes it), but at no ergonomic loss, since there's no funky `C: LayoutOf<Ty = Ty>` -> `Ty: TyAbiInterface<C>` generic `impl` chain, and each `LayoutOf` still corresponds to one `impl` (of `LayoutOfHelpers`) for the specific context.

After this PR, this is what's needed to get `trait LayoutOf` (with the `layout_of` method) implemented on some context type:
* `TyCtxt`, via `HasTyCtxt`
* `ParamEnv`, via `HasParamEnv`
* a way to transform `LayoutError`s into the desired error type
  * an error type of `!` can be paired with having `cx.layout_of(...)` return `TyAndLayout` *without* `Result<...>` around it, such as used by codegen
  * this is done through a new `LayoutOfHelpers` trait (and so is specifying the type of `cx.layout_of(...)`)

When going through this path (and not bypassing it with a manual `impl` of `LayoutOf`), the end result is that only the error case can be customized, the query itself and the success paths are guaranteed to be uniform.

(**EDIT**: just noticed that because of the supertrait relationship, you cannot actually implement `LayoutOf` yourself, the blanket `impl` fully covers all possible context types that could ever implement it)

Part of the motivation for this shape of API is that I've been working on querifying `FnAbi::of_*`, and what I want/need to introduce for that looks a lot like the setup in this PR - in particular, it's harder to express the `FnAbi` methods in `rustc_target`, since they're much more tied to `rustc` concepts.

r? `@nagisa` cc `@oli-obk` `@bjorn3`
bjorn3 pushed a commit to bjorn3/rust that referenced this pull request Sep 19, 2021
Provide `layout_of` automatically (given tcx + param_env + error handling).

After rust-lang#88337, there's no longer any uses of `LayoutOf` within `rustc_target` itself, so I realized I could move the trait to `rustc_middle::ty::layout` and redesign it a bit.

This is similar to rust-lang#88338 (and supersedes it), but at no ergonomic loss, since there's no funky `C: LayoutOf<Ty = Ty>` -> `Ty: TyAbiInterface<C>` generic `impl` chain, and each `LayoutOf` still corresponds to one `impl` (of `LayoutOfHelpers`) for the specific context.

After this PR, this is what's needed to get `trait LayoutOf` (with the `layout_of` method) implemented on some context type:
* `TyCtxt`, via `HasTyCtxt`
* `ParamEnv`, via `HasParamEnv`
* a way to transform `LayoutError`s into the desired error type
  * an error type of `!` can be paired with having `cx.layout_of(...)` return `TyAndLayout` *without* `Result<...>` around it, such as used by codegen
  * this is done through a new `LayoutOfHelpers` trait (and so is specifying the type of `cx.layout_of(...)`)

When going through this path (and not bypassing it with a manual `impl` of `LayoutOf`), the end result is that only the error case can be customized, the query itself and the success paths are guaranteed to be uniform.

(**EDIT**: just noticed that because of the supertrait relationship, you cannot actually implement `LayoutOf` yourself, the blanket `impl` fully covers all possible context types that could ever implement it)

Part of the motivation for this shape of API is that I've been working on querifying `FnAbi::of_*`, and what I want/need to introduce for that looks a lot like the setup in this PR - in particular, it's harder to express the `FnAbi` methods in `rustc_target`, since they're much more tied to `rustc` concepts.

r? `@nagisa` cc `@oli-obk` `@bjorn3`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants