forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rollup merge of rust-lang#62585 - pnkfelix:issue-60431-make-struct-ta…
…il-normalize-when-possible, r=eddyb Make struct_tail normalize when possible As noted in commit message: this replaces the existing methods to extract the struct tail(s) with new entry points that make the handling of normalization explicit. Most of the places that call `struct_tail` are during codegen, post type-checking, and therefore they can get away with using `tcx.normalize_erasing_regions` (this is the entry point `struct_tail_erasing_lifetimes`) For other cases that may arise, one can use the core method, which is parameterized over the normalization `Ty -> Ty` closure (`struct_tail_with_normalize`). Or one can use the trivial entry point that does not normalization (`struct_tail_without_normalization`) ---- I spent a little while trying to make a test that exposed the bug via `impl Trait` rather than a projection, but I failed to find something that tripped up the current nightly `rustc`. * I have *not* spent any time trying to make tests that trip up the other places where `struct_tail` was previously being called. While I do think the task of making such tests could be worthwhile, I am simply running out of time. (Its also possible that the layout code is always the first point called, and thus it may be pointless to try to come up with such tests.) I also spent a little time discussing with @eddyb where this code should live. They suggested moving `struct_tail` and its sibling `struct_lockstep_tails` to the `LayoutCx`. But in the interest of time, I have left that refactoring (which may be questionable at this point) to a follow-up task. ---- Fix rust-lang#60431
- Loading branch information
Showing
11 changed files
with
151 additions
and
22 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
35 changes: 35 additions & 0 deletions
35
src/test/ui/layout/issue-60431-unsized-tail-behind-projection.rs
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
// rust-lang/rust#60431: This is a scenario where to determine the size of | ||
// `&Ref<Obstack>`, we need to know the concrete type of the last field in | ||
// `Ref<Obstack>` (i.e. its "struct tail"), and determining that concrete type | ||
// requires normalizing `Obstack::Dyn`. | ||
// | ||
// The old "struct tail" computation did not perform such normalization, and so | ||
// the compiler would ICE when trying to figure out if `Ref<Obstack>` is a | ||
// dynamically-sized type (DST). | ||
|
||
// run-pass | ||
|
||
use std::mem; | ||
|
||
pub trait Arena { | ||
type Dyn : ?Sized; | ||
} | ||
|
||
pub struct DynRef { | ||
_dummy: [()], | ||
} | ||
|
||
pub struct Ref<A: Arena> { | ||
_value: u8, | ||
_dyn_arena: A::Dyn, | ||
} | ||
|
||
pub struct Obstack; | ||
|
||
impl Arena for Obstack { | ||
type Dyn = DynRef; | ||
} | ||
|
||
fn main() { | ||
assert_eq!(mem::size_of::<&Ref<Obstack>>(), mem::size_of::<&[()]>()); | ||
} |