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.

Sign up for GitHub

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

Normalize MIR locals' types for generator layout computation. #70957

Merged
merged 1 commit into from
Apr 11, 2020
Merged

Normalize MIR locals' types for generator layout computation. #70957

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
5 changes: 4 additions & 1 deletion src/librustc_mir/transform/generator.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -720,15 +720,18 @@ fn compute_layout<'tcx>(
_ => bug!(),
};

let param_env = tcx.param_env(source.def_id());

for (local, decl) in body.local_decls.iter_enumerated() {
// Ignore locals which are internal or not live
if !live_locals.contains(local) || decl.internal {
continue;
}
let decl_ty = tcx.normalize_erasing_regions(param_env, decl.ty);
Copy link
Member

Choose a reason for hiding this comment

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

Do you think maybe we should be normalizing during typeck? (i.e. have typeck's to_const call .eval(self.param_env) on the constant it creates)

Check out the commit titled "borrow_check/type_check: normalize Aggregate and Call operands.", required to fix #70773, from my PR #70452. Maybe we could fix that issue and this one by just normalizing early.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was wondering where else to do this if not here. Since normalization is just a best-effort thing (at least around constants), doing it earlier is fine, as long as the param_env at the earlier site has the same bounds as this one here. Since generator expansion happens happens after inlining, I'm not so sure about that. For this specific ICE it should be fine though.


// Sanity check that typeck knows about the type of locals which are
// live across a suspension point
if !allowed.contains(&decl.ty) && !allowed_upvars.contains(&decl.ty) {
if !allowed.contains(&decl_ty) && !allowed_upvars.contains(&decl_ty) {
span_bug!(
body.span,
"Broken MIR: generator contains type {} in MIR, \
Expand Down
10 changes: 10 additions & 0 deletions src/test/ui/repeat_count_const_in_async_fn.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
// check-pass
// edition:2018
// compile-flags: --crate-type=lib

pub async fn test() {
const C: usize = 4;
foo(&mut [0u8; C]).await;
}

async fn foo(_: &mut [u8]) {}