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

Remove hook calling via TyCtxtAt. #136464

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nnethercote
Copy link
Contributor

All hooks receive a TyCtxtAt argument.

Currently hooks can be called through TyCtxtAt or TyCtxt. In the latter case, a TyCtxtAt is constructed with a dummy span and passed to the hook.

However, in practice hooks are never called through TyCtxtAt, and always receive a dummy span. (I confirmed this via code inspection, and double-checked it by temporarily making the TyCtxtAt code path panic and running all the tests.)

This commit removes all the TyCtxtAt machinery for hooks. All hooks now receive TyCtxt instead of TyCtxtAt. There are two existing hooks that use TyCtxtAt::span: const_caller_location_provider and try_destructure_mir_constant_for_user_output. For both hooks the span is always a dummy span, probably unintentionally. This dummy span use is now explicit. If a non-dummy span is needed for these two hooks it would be easy to add it as an extra argument because hooks are less constrained than queries.

r? @oli-obk

All hooks receive a `TyCtxtAt` argument.

Currently hooks can be called through `TyCtxtAt` or `TyCtxt`. In the
latter case, a `TyCtxtAt` is constructed with a dummy span and passed to
the hook.

However, in practice hooks are never called through `TyCtxtAt`, and
always receive a dummy span. (I confirmed this via code inspection, and
double-checked it by temporarily making the `TyCtxtAt` code path panic
and running all the tests.)

This commit removes all the `TyCtxtAt` machinery for hooks. All hooks
now receive `TyCtxt` instead of `TyCtxtAt`. There are two existing hooks
that use `TyCtxtAt::span`: `const_caller_location_provider` and
`try_destructure_mir_constant_for_user_output`. For both hooks the span
is always a dummy span, probably unintentionally. This dummy span use is
now explicit. If a non-dummy span is needed for these two hooks it would
be easy to add it as an extra argument because hooks are less
constrained than queries.
@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) 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 Feb 3, 2025
@rustbot
Copy link
Collaborator

rustbot commented Feb 3, 2025

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

@oli-obk
Copy link
Contributor

oli-obk commented Feb 3, 2025

Hmm... I would have tried going the other way first and using spans at the call sites more often.

Is this refactoring really a useful cleanup or simplification?

@nnethercote
Copy link
Contributor Author

I don't like TyCtxtAt much, because it's often confusing what span you have. E.g. look at this PR, where there are two hooks that are using a tcx.span that is always a dummy span.

So I was looking at whether TyCtxtAt is needed at all. It seems hard to remove in general, but was pretty easy here and made things simpler, IMO.

@Zalathar
Copy link
Contributor

Zalathar commented Feb 3, 2025

Anecdotally, the one time that I have added a hook, having to deal with the unwanted TyCtxtAt was confusing and unhelpful.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 3, 2025

Well, it just means that we get more span arguments in random places when people want better ICE locations. I don't really feel strongly about it so

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Feb 3, 2025

📌 Commit e661514 has been approved by oli-obk

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 Feb 3, 2025
@Zalathar Zalathar mentioned this pull request Feb 3, 2025
12 tasks
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Feb 3, 2025
… r=oli-obk

Remove hook calling via `TyCtxtAt`.

All hooks receive a `TyCtxtAt` argument.

Currently hooks can be called through `TyCtxtAt` or `TyCtxt`. In the latter case, a `TyCtxtAt` is constructed with a dummy span and passed to the hook.

However, in practice hooks are never called through `TyCtxtAt`, and always receive a dummy span. (I confirmed this via code inspection, and double-checked it by temporarily making the `TyCtxtAt` code path panic and running all the tests.)

This commit removes all the `TyCtxtAt` machinery for hooks. All hooks now receive `TyCtxt` instead of `TyCtxtAt`. There are two existing hooks that use `TyCtxtAt::span`: `const_caller_location_provider` and `try_destructure_mir_constant_for_user_output`. For both hooks the span is always a dummy span, probably unintentionally. This dummy span use is now explicit. If a non-dummy span is needed for these two hooks it would be easy to add it as an extra argument because hooks are less constrained than queries.

r? `@oli-obk`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) 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