-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Clarify names of QueryVTable functions for "executing" a query
#152434
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -457,7 +457,9 @@ fn try_load_from_on_disk_cache<'tcx, C: QueryCache, const FLAGS: QueryFlags>( | |
| panic!("Failed to recover key for {:?} with hash {}", dep_node, dep_node.hash) | ||
| }); | ||
| if query.will_cache_on_disk_for_key(tcx, &key) { | ||
| let _ = query.execute_query(tcx, key); | ||
| // Call `tcx.$query(key)` for its side-effect of loading the disk-cached | ||
| // value into memory. | ||
| query.call_query_method(tcx, key); | ||
| } | ||
| } | ||
|
|
||
|
|
@@ -625,14 +627,15 @@ macro_rules! define_queries { | |
| } | ||
| } | ||
|
|
||
| /// Defines a `compute` function for this query, to be used as a | ||
| /// function pointer in the query's vtable. | ||
| mod compute_fn { | ||
| /// Defines an `invoke_provider` function that calls the query's provider, | ||
| /// to be used as a function pointer in the query's vtable. | ||
| /// | ||
| /// To mark a short-backtrace boundary, the function's actual name | ||
| /// (after demangling) must be `__rust_begin_short_backtrace`. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is helpful, thanks. |
||
| mod invoke_provider_fn { | ||
| use super::*; | ||
| use ::rustc_middle::queries::$name::{Key, Value, provided_to_erased}; | ||
|
|
||
| /// This function would be named `compute`, but we also want it | ||
| /// to mark the boundaries of an omitted region in backtraces. | ||
| #[inline(never)] | ||
| pub(crate) fn __rust_begin_short_backtrace<'tcx>( | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (Pre-existing) This function has a strange name! Doesn't give any idea what it does, and is the same as the one from
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, this is probably very confusing if you don't already know how short backtraces work. The backtrace handler looks for pairs of functions named If an ICE occurs in a query provider, we typically want to omit all of the query plumbing between the query caller and the query provider, because it's dozens of lines of irrelevant noise. To make that work, the function that calls the provider has to be named
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To minimize runtime overhead and also make the short-backtraces more reliable, the specially-named functions are used in places where we were going to dynamically call a function pointer from a vtable anyway. The downside is that those functions have to have unhelpful names, because function names are what the short-backtrace machinery uses to do its work. To compensate for that as much as possible, we define the strangely-named functions in modules that have more helpful names, and use comments to (hopefully) explain what's going on. |
||
| tcx: TyCtxt<'tcx>, | ||
|
|
@@ -643,10 +646,13 @@ macro_rules! define_queries { | |
|
|
||
| // Call the actual provider function for this query. | ||
| let provided_value = call_provider!([$($modifiers)*][tcx, $name, key]); | ||
|
|
||
| rustc_middle::ty::print::with_reduced_queries!({ | ||
| tracing::trace!(?provided_value); | ||
| }); | ||
|
|
||
| // Erase the returned value, because `QueryVTable` uses erased values. | ||
| // For queries with `arena_cache`, this also arena-allocates the value. | ||
| provided_to_erased(tcx, provided_value) | ||
| } | ||
| } | ||
|
|
@@ -666,8 +672,12 @@ macro_rules! define_queries { | |
| } { | ||
| None | ||
| }), | ||
| execute_query: |tcx, key| erase::erase_val(tcx.$name(key)), | ||
| compute_fn: self::compute_fn::__rust_begin_short_backtrace, | ||
| call_query_method_fn: |tcx, key| { | ||
| // Call the query method for its side-effect of loading a value | ||
| // from disk-cache; the caller doesn't need the value. | ||
| let _ = tcx.$name(key); | ||
| }, | ||
| invoke_provider_fn: self::invoke_provider_fn::__rust_begin_short_backtrace, | ||
| try_load_from_disk_fn: if_cache_on_disk!([$($modifiers)*] { | ||
| Some(|tcx, key, prev_index, index| { | ||
| // Check the `cache_on_disk_if` condition for this key. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with the distinction between these functions, and the comments help but I'm still left wondering about the relationship between them. Especially given that they have the same signature. Does one call the other, or something?