-
Notifications
You must be signed in to change notification settings - Fork 13k
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
base: master
Are you sure you want to change the base?
Conversation
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.
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 |
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? |
I don't like So I was looking at whether |
Anecdotally, the one time that I have added a hook, having to deal with the unwanted |
Well, it just means that we get more @bors r+ rollup |
… 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`
All hooks receive a
TyCtxtAt
argument.Currently hooks can be called through
TyCtxtAt
orTyCtxt
. In the latter case, aTyCtxtAt
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 theTyCtxtAt
code path panic and running all the tests.)This commit removes all the
TyCtxtAt
machinery for hooks. All hooks now receiveTyCtxt
instead ofTyCtxtAt
. There are two existing hooks that useTyCtxtAt::span
:const_caller_location_provider
andtry_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