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

Fix MemCategorization and ExprUse visitors for new solver (this time it's better) #124902

Merged
merged 8 commits into from
May 12, 2024

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented May 8, 2024

Best reviewed by each commit. Supersedes #124859.

r? lcnr

@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 May 8, 2024
@rustbot
Copy link
Collaborator

rustbot commented May 8, 2024

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@compiler-errors
Copy link
Member Author

@bors try @rust-timer queue

since i am using RefCell over a mut ref to simplify mixing self access and delegate calls

@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 May 8, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request May 8, 2024
…r=<try>

Fix MemCategorization and ExprUse visitors for new solver (this time it's better)

Best reviewed by each commit. Supersedes rust-lang#124859.

r? lcnr
@bors
Copy link
Contributor

bors commented May 8, 2024

⌛ Trying commit 9af26d0 with merge 4544086...

@@ -1,774 +0,0 @@
//! # Categorization
Copy link
Member Author

Choose a reason for hiding this comment

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

Goodbye to this comment. I could possibly pull all of the fn cat_* that I moved into expr_use_visitor.rs into a separate impl and copy this comment over. Let me know if necessary.

Copy,
/// reference to x where x has a type that moves
Move,
impl<'tcx, D: Delegate<'tcx>> Delegate<'tcx> for &mut D {
Copy link
Member Author

Choose a reason for hiding this comment

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

All call sites pass in &mut Delegate but I don't want to store a lifetime in the ExprUseVisitor struct lol

}

pub trait TypeInformationCtxt<'tcx> {
type TypeckResults<'a>: Deref<Target = ty::TypeckResults<'tcx>>
Copy link
Member Author

Choose a reason for hiding this comment

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

Need to abstract over &'tcx TypeckResults (clippy) and RefCell<TypeckResults> (typeck)

}
}

impl<'tcx> TypeInformationCtxt<'tcx> for (&LateContext<'tcx>, LocalDefId) {
Copy link
Member Author

Choose a reason for hiding this comment

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

We store the body id separately rather than trying to get it from the LateContext because although that stores the body, we're often calling the ExprUseVisitor on an inner closure, so the def id would be wrong (which affects upvar analysis!)

Copy link
Member Author

Choose a reason for hiding this comment

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

Too lazy to make this into a separate type but I could be convinced otherwise.

@compiler-errors
Copy link
Member Author

@bors try

@bors
Copy link
Contributor

bors commented May 8, 2024

⌛ Trying commit 8b060ab with merge 74abdbd...

bors added a commit to rust-lang-ci/rust that referenced this pull request May 8, 2024
…r=<try>

Fix MemCategorization and ExprUse visitors for new solver (this time it's better)

Best reviewed by each commit. Supersedes rust-lang#124859.

r? lcnr
@bors
Copy link
Contributor

bors commented May 8, 2024

☀️ Try build successful - checks-actions
Build commit: 74abdbd (74abdbd697099bb2e629f4379d23c9b8fe26d919)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (74abdbd): comparison URL.

Overall result: no relevant changes - 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 benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

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

Cycles

Results

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)
4.1% [4.1%, 4.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 675.856s -> 674.94s (-0.14%)
Artifact size: 316.00 MiB -> 315.97 MiB (-0.01%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label May 8, 2024
Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

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

nits

compiler/rustc_hir_typeck/src/expr_use_visitor.rs Outdated Show resolved Hide resolved
compiler/rustc_hir_typeck/src/expr_use_visitor.rs Outdated Show resolved Hide resolved
compiler/rustc_hir_typeck/src/expr_use_visitor.rs Outdated Show resolved Hide resolved
/// Like `pat_ty`, but ignores implicit `&` patterns.
#[instrument(level = "debug", skip(self), ret)]
fn pat_ty_unadjusted(&self, pat: &hir::Pat<'_>) -> McResult<Ty<'tcx>> {
let base_ty = self.node_ty(pat.hir_id)?;
Copy link
Contributor

Choose a reason for hiding this comment

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

does that ICE?

Suggested change
let base_ty = self.node_ty(pat.hir_id)?;
let base_ty = self.typeck_results.pat_ty(pat);

Copy link
Member Author

Choose a reason for hiding this comment

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

We need to call resolve_type_vars_or_error still

compiler/rustc_hir_typeck/src/expr_use_visitor.rs Outdated Show resolved Hide resolved
@rust-log-analyzer

This comment has been minimized.

@@ -7,6 +7,7 @@
#![feature(never_type)]
#![feature(rustc_private)]
#![feature(assert_matches)]
#![feature(unwrap_infallible)]
Copy link
Member Author

Choose a reason for hiding this comment

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

Hi @rust-lang/clippy; I'm pinging you to let y'all know I added a new #![feature(..)] for Result::into_ok() to make the ExprUseVisitor that's being employed by clippy a bit more resilient to error reporting.

None of this error reporting matters for clippy, since we've typechecked the function we're visiting already, so it needs to handle Result<(), !> everywhere and into_ok() is the easiest way to do this.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented May 10, 2024

☔ The latest upstream changes (presumably #124972) made this pull request unmergeable. Please resolve the merge conflicts.

@compiler-errors
Copy link
Member Author

Ok I understand why this change has fixed #123901.

We used to silently swallow errors when recursing here:

fn walk_local<F>(
&mut self,
expr: &hir::Expr<'_>,
pat: &hir::Pat<'_>,
els: Option<&hir::Block<'_>>,
mut f: F,
) where
F: FnMut(&mut Self),
{
self.walk_expr(expr);
let expr_place = return_if_err!(self.mc.cat_expr(expr));

Which now we propagate as an error all the way up the stack. I believe this is totally fine to do.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@lcnr
Copy link
Contributor

lcnr commented May 12, 2024

@bors r+ rollup=iffy

@bors
Copy link
Contributor

bors commented May 12, 2024

📌 Commit c697ec4 has been approved by lcnr

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 May 12, 2024
@bors
Copy link
Contributor

bors commented May 12, 2024

⌛ Testing commit c697ec4 with merge 852a78e...

@bors
Copy link
Contributor

bors commented May 12, 2024

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 852a78e to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 12, 2024
@bors bors merged commit 852a78e into rust-lang:master May 12, 2024
7 checks passed
@rustbot rustbot added this to the 1.80.0 milestone May 12, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (852a78e): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)
- - 0
Improvements ✅
(primary)
-2.4% [-2.4%, -2.4%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.4% [-2.4%, -2.4%] 1

Cycles

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

Binary size

Results

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.2% [0.2%, 0.2%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.2% [0.2%, 0.2%] 1

Bootstrap: 676.904s -> 676.465s (-0.06%)
Artifact size: 316.08 MiB -> 316.13 MiB (0.01%)

Copy link
Member

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

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

Thanks for the extra ping to the Clippy team. But I got here late anyway. All of this looks fine, only one question for better understanding.

Comment on lines +253 to +255
pub fn for_clippy(cx: &'a LateContext<'tcx>, body_def_id: LocalDefId, delegate: D) -> Self {
Self::new((cx, body_def_id), delegate)
}
Copy link
Member

Choose a reason for hiding this comment

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

Late to the party: Why does Clippy require special treatment?

Copy link
Member Author

@compiler-errors compiler-errors May 17, 2024

Choose a reason for hiding this comment

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

Because I want to hide the the Self::new constructor so clippy users won't be tempted to either 1. implementa a manual TypeInformationContext and/or FnCtxt, and 2. so that users will know exactly what data to pass to make a ExprUseVisitor.

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 could've equally called it for_lint, or from_late_ctxt, or something instead.

Copy link
Member Author

Choose a reason for hiding this comment

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

Clippy was fundamentally using ExprUseVisitor differently from the only usage in the compiler, though, so that's why the separate constructor exists.

Copy link
Member

@flip1995 flip1995 May 21, 2024

Choose a reason for hiding this comment

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

I see, thanks for the explanation. Generally naming a function for_clippy or for_<tool> gives me the impression, that the function is a hack that only exists because Clippy/the tool doesn't use it as intended. This is also why I asked this question.

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