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.

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

Update ty::VariantDef to use IndexVec<FieldIdx, FieldDef> #109762

Merged
merged 1 commit into from
Mar 31, 2023

Conversation

scottmcm
Copy link
Member

And while doing the updates for that, also uses FieldIdx in ProjectionKind::Field and TypeckResults::field_indices.

There's more places that could use it (like rustc_const_eval and LayoutS), but I tried to keep this PR from exploding to even more places.

Part 2/? of rust-lang/compiler-team#606

@rustbot
Copy link
Collaborator

rustbot commented Mar 30, 2023

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Mar 30, 2023
@rustbot
Copy link
Collaborator

rustbot commented Mar 30, 2023

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Comment on lines 414 to 416
ty::Adt(def, substs) => def.variant(FIRST_VARIANT).fields
[FieldIdx::from_usize(i)]
.ty(tcx, substs),
Copy link
Contributor

@fbstj fbstj Mar 30, 2023

Choose a reason for hiding this comment

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

this seems like it might be a wonky formatting?

Copy link
Member Author

Choose a reason for hiding this comment

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

I agree, but this is what rustfmt did -- I didn't do any manual reformattings, just ran x.py fmt to make tidy happy.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, maybe I'll do some shadowing for these cases to try to get something less weird...

Copy link
Member

Choose a reason for hiding this comment

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

Sometimes rustfmt just does literally no formatting, for example when there are if-let-chains, maybe this is the case here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope, this is definitely rustfmt doing it -- all I did was add the FieldIdx::from_usize inline, without adding any newlines. Then tidy made me change it to that weirdness 🤷

Copy link
Member

@WaffleLapkin WaffleLapkin left a comment

Choose a reason for hiding this comment

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

r=me with formatting fixed (@fbstj's comment) and minor comments addressed.

I think one interesting thing for future work may be to search for FieldIdx::from_usize and FieldIdx::from_u32 (and maybe ::new and .index) and see if they can be removed via changing the caller.

@@ -2238,7 +2237,7 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> {
self.apply_adjustments(base, adjustments);
self.register_predicates(autoderef.into_obligations());

self.write_field_index(expr.hir_id, index);
self.write_field_index(expr.hir_id, FieldIdx::from_usize(index));
Copy link
Member

Choose a reason for hiding this comment

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

Makes me wonder why do we need such cruel string manipulation few lines above O_o

Copy link
Member Author

Choose a reason for hiding this comment

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

It looks like it's because field is an Ident. So I guess the fstr == index.to_string() is basically just checking that it's not tup.0001? (It has an as_u32, but that's the index in the string interner, so would be very, very wrong here.)

Copy link
Member Author

Choose a reason for hiding this comment

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

aha, found a little tweak that should be clearer and avoid the String for every .0, .1, through .9:

field.name == sym::integer(index) 

compiler/rustc_hir_typeck/src/upvar.rs Show resolved Hide resolved
TyMaybeWithLayout::Ty(def.variant(index).fields[i].ty(tcx, substs))
}
Variants::Single { index } => TyMaybeWithLayout::Ty(
def.variant(index).fields[FieldIdx::new(i)].ty(tcx, substs),
Copy link
Member

Choose a reason for hiding this comment

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

Why does this use ::new instead of ::from_usize?

Suggested change
def.variant(index).fields[FieldIdx::new(i)].ty(tcx, substs),
def.variant(index).fields[FieldIdx::from_usize(i)].ty(tcx, substs),

Copy link
Member Author

Choose a reason for hiding this comment

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

Because that file already had VariantIdx::new, apparently. I'll change it since I do like the concrete one better.

(It's kinda annoying that new (from Idx), from_usize and .into() (from newtype_index!) all exist and work so there's nothing pushing code to consistency.)

Comment on lines 414 to 416
let unique_ty = adt.non_enum_variant().fields[FieldIdx::new(0)].ty(self.tcx(), substs);
let nonnull_ty = unique_ty.ty_adt_def().unwrap().non_enum_variant().fields
[FieldIdx::new(0)]
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
let unique_ty = adt.non_enum_variant().fields[FieldIdx::new(0)].ty(self.tcx(), substs);
let nonnull_ty = unique_ty.ty_adt_def().unwrap().non_enum_variant().fields
[FieldIdx::new(0)]
let unique_ty = adt.non_enum_variant().fields[FieldIdx::from_u32(0)].ty(self.tcx(), substs);
let nonnull_ty = unique_ty.ty_adt_def().unwrap().non_enum_variant().fields
[FieldIdx::from_u32(0)]

Copy link
Member

Choose a reason for hiding this comment

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

Also [] on the new line looks a bit weird, is this rustfmt's formatting? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup, this is rustfmt's choice 🤷

@@ -1725,7 +1725,8 @@ impl<'a, 'tcx> TypeChecker<'a, 'tcx> {
AggregateKind::Adt(adt_did, variant_index, substs, _, active_field_index) => {
let def = tcx.adt_def(adt_did);
let variant = &def.variant(variant_index);
let adj_field_index = active_field_index.unwrap_or(field_index);
let adj_field_index =
FieldIdx::from_usize(active_field_index.unwrap_or(field_index));
Copy link
Member Author

Choose a reason for hiding this comment

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

This is the kind of place that will hopefully be temporary -- changing AggregateKind::Adt to hold a FieldIdx and the function to use field_index: FieldIdx instead of field_index: usize should get rid of this in an upcoming PR in this series, but I needed to stop the tendrils somewhere 🙃

And while doing the updates for that, also uses `FieldIdx` in `ProjectionKind::Field` and `TypeckResults::field_indices`.

There's more places that could use it (like `rustc_const_eval` and `LayoutS`), but I tried to keep this PR from exploding to *even more* places.

Part 2/? of rust-lang/compiler-team#606
@scottmcm
Copy link
Member Author

Added some extra lets to avoid the weird rustfmt formatting, and addressed comments
@bors r=WaffleLapkin

@bors
Copy link
Contributor

bors commented Mar 30, 2023

📌 Commit 4abb455 has been approved by WaffleLapkin

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 30, 2023
@bors
Copy link
Contributor

bors commented Mar 31, 2023

⌛ Testing commit 4abb455 with merge eb3e9c1...

@bors
Copy link
Contributor

bors commented Mar 31, 2023

☀️ Test successful - checks-actions
Approved by: WaffleLapkin
Pushing eb3e9c1 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 31, 2023
@bors bors merged commit eb3e9c1 into rust-lang:master Mar 31, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 31, 2023
@scottmcm scottmcm deleted the variantdef-indexvec branch March 31, 2023 06:10
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (eb3e9c1): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.5% [-0.6%, -0.5%] 3
Improvements ✅
(secondary)
-0.4% [-0.5%, -0.3%] 8
All ❌✅ (primary) -0.5% [-0.6%, -0.5%] 3

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

@lcnr lcnr removed the WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) label Apr 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants