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

cleanup TypeVerifier #134465

Merged
merged 5 commits into from
Dec 23, 2024
Merged

cleanup TypeVerifier #134465

merged 5 commits into from
Dec 23, 2024

Conversation

lcnr
Copy link
Contributor

@lcnr lcnr commented Dec 18, 2024

We should merge it with the TypeChecker as we no longer bail in cases where it encounters an error since #111863.

It's quite inconsistent whether a check lives in the verifier or the TypeChecker, so this feels like a quite impactful cleanup. I expect that for this we may want to change the TypeChecker to also be a MIR visitor 🤔 this is non-trivial so I didn't fully do it in this PR.

Best reviewed commit by commit.

r? @compiler-errors feel free to reassign however

@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. labels Dec 18, 2024
| ProjectionElem::Subslice { .. }
| ProjectionElem::Downcast(..) => {}
ProjectionElem::Field(field, fty) => {
let fty = self.typeck.normalize(fty, location);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

you'd think this normalize call is unnecessary, but no, it's not :3

cc #93141 :< I dislike that we end up normalizing here again instead of during writeback.

Copy link
Member

Choose a reason for hiding this comment

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

we wouldn't be normalizing during writeback bc we create this field projection ty during mir build, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From what I can tell we do use types from the HIR here, so the issue in the following test is:

pub trait Fooey: Sized {
    type Context<'c> where Self: 'c;
}

pub struct Handle<E: Fooey>(Option<Box<dyn for<'c> Fn(&mut E::Context<'c>)>>);

fn tuple<T>() -> (Option<T>,) { (Option::None,) }

pub struct FooImpl {}
impl Fooey for FooImpl {
    type Context<'c> = &'c ();
}

fn fail1() -> Handle<FooImpl> {
    let (tx,) = tuple();
    Handle(tx)
}
  • tx starts as Option<?x>
  • constructing handle infers ?x to Box<dyn for<'c> Fn(&mut <?y as Fooey::Context<'c>)> (we keep the projection as it contains bound vars)
  • returning Handle<?y> then constrains ?y to FooImpl
  • we don't normalize the type of tx again.
  • without the assert, borrowck fails when equating the unnormalized with the normalized projection.

@lcnr
Copy link
Contributor Author

lcnr commented Dec 18, 2024

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 18, 2024
@bors
Copy link
Contributor

bors commented Dec 18, 2024

⌛ Trying commit 5bced14 with merge 231855a...

bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 18, 2024
cleanup `TypeVerifier`

We should merge it with the `TypeChecker` as we no longer bail in cases where it encounters an error since rust-lang#111863.

It's quite inconsistent whether a check lives in the verifier or the `TypeChecker`, so this feels like a quite impactful cleanup. I expect that for this we may want to change the `TypeChecker` to also be a MIR visitor 🤔 this is non-trivial so I didn't fully do it in this PR.

Best reviewed commit by commit.

r? `@compiler-errors` feel free to reassign however
@bors
Copy link
Contributor

bors commented Dec 18, 2024

☀️ Try build successful - checks-actions
Build commit: 231855a (231855a63277f08e2be544002ae9583be4e222a1)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (231855a): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.1% [0.1%, 0.1%] 1
Improvements ✅
(primary)
-0.3% [-0.4%, -0.2%] 8
Improvements ✅
(secondary)
-0.4% [-0.5%, -0.3%] 14
All ❌✅ (primary) -0.3% [-0.4%, -0.2%] 8

Max RSS (memory usage)

Results (secondary -1.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.1% [3.1%, 3.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.3% [-4.4%, -2.3%] 2
All ❌✅ (primary) - - 0

Cycles

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

Binary size

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

Bootstrap: 771.888s -> 769.352s (-0.33%)
Artifact size: 330.28 MiB -> 330.19 MiB (-0.03%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 18, 2024
| ProjectionElem::Subslice { .. }
| ProjectionElem::Downcast(..) => {}
ProjectionElem::Field(field, fty) => {
let fty = self.typeck.normalize(fty, location);
Copy link
Member

Choose a reason for hiding this comment

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

we wouldn't be normalizing during writeback bc we create this field projection ty during mir build, right?

/// not carry a `Ty` for `T`.)
/// `place_ty.field_ty(tcx, f)` computes the type of a given field.
///
/// Most clients of `PlaceTy` can instead just extract the relevant type
Copy link
Member

Choose a reason for hiding this comment

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

"clients" 💀

@compiler-errors
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Dec 21, 2024

📌 Commit 5bced14 has been approved by compiler-errors

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 Dec 21, 2024
@bors
Copy link
Contributor

bors commented Dec 23, 2024

⌛ Testing commit 5bced14 with merge 0eca4dd...

@bors
Copy link
Contributor

bors commented Dec 23, 2024

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 0eca4dd to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 23, 2024
@bors bors merged commit 0eca4dd into rust-lang:master Dec 23, 2024
7 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Dec 23, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (0eca4dd): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.3% [-0.4%, -0.2%] 6
Improvements ✅
(secondary)
-0.4% [-0.5%, -0.1%] 16
All ❌✅ (primary) -0.3% [-0.4%, -0.2%] 6

Max RSS (memory usage)

Results (primary -0.8%, secondary 3.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.8% [0.8%, 0.8%] 1
Regressions ❌
(secondary)
3.5% [3.5%, 3.5%] 1
Improvements ✅
(primary)
-1.6% [-2.2%, -1.0%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.8% [-2.2%, 0.8%] 3

Cycles

Results (secondary 3.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.3% [2.9%, 3.7%] 5
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 765.462s -> 763.42s (-0.27%)
Artifact size: 330.55 MiB -> 330.55 MiB (-0.00%)

@lcnr lcnr deleted the type-verifier branch December 23, 2024 08:34
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.

5 participants