Change:
#[cfg(parallel_compiler)] pub use rustc_query_system::query::{deadlock, QueryContext}; <del> use rustc_middle::query::Key; </del> pub use rustc_query_system::query::QueryConfig; pub(crate) use rustc_query_system::query::QueryVTable;

Discussion:
made a great start on this in , but it would be nice to explain the / distinction in the panic message; "unsupported by crate" is unhelpful. This is an ICE targeted at compiler developers so IMO it can be pretty much as long as we want. Currently the error looks like this: I wrote up this description while helping someone debug on discord, which may be a good start: If possible, we should say " unsupported by local crate" (or external as appropriate, selected at runtime), but if not, we should at least explain what's going wrong better. The link below has a lot of details about the code structure that may be helpful. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Claiming this. If someone could bring some color on whether is always a valid in this context as per the discussion on would be very helpful as this is the first issue I'm taking on. If is guaranteed to be a valid key, we could call as per the to figure if it's a local or external crate?
claim
yes, all keys must implement Key or they can't be used as the argument to a query in the first place. is already used in that macro :)
Awesome, thanks for the reply! This is what I have in place so far. The compiler, however, is not happy with me calling This is the macro definition, I noticed it uses for every argument of fn. Is it right to assume that the is due to the macro using to define the function arguments rather than as per your example? If so, could we use use/define a macro similar to the one you referenced on your comment above? Something like: EDIT: If key is always a valid key at runtime, this wouldn't cause harm I believe? Thanks in advance!
hmm, I think I was wrong before - the problem is that the key only needs to implement the trait if the macro has the modifier. Maybe you can add a new macro; that will give a better error anyway since it can distinguish "you a local provider but not an extern provider" from "you never a provider at all". vs isn't relevant, they expand to the same thing at expansion time.

Hi if I understood correctly, the key is not guaranteed to implement the trait on the code snippet I provided, so we can't reliably call due to that, which is fine. To your point on the new macro, I tried a few takes, since I'm not very knowledgeable on the macros, and haven't found many docs around them, I tried a few takes basing myself off of the macro you referenced above, and to come up with an implementation for the new macro. Since both macros I used as example have the , I thought this would help me figure out the new macro. I got to a point where I tried a few solutions (I can share them here, if you want to reference), but still end up with very similar compiler issues for all of them. and This one made me think I might be going to the right direction...I see a here, and we know we can tell the crate by looking at the DefId... This was my last take on getdefault_provider. Again, I'm not very knowledgeable on this, so my solutions were heavily based off of macros that were already present and doing similar things, so I'm afraid this might not be the way to solve it. If you could point me to the right direction here as it relates to this new macro, that would be super helpful!! Again, thanks for the great support on this one. Really having fun while trying to push my first contribution! :)
Hi After some digging, I couldn't find a way to reliably add / to the message based on the key - so I ended up just improving the message without it specifying which crate the error is referring to.
Hello I looked into this a little bit and to me it seems that all the keys do implement . The main problem with calling from is that cannot depend on and therefore cannot use the trait. I am new to contributing to rust. I don't know how feasible this is but maybe we can move to ? Every dependency used in is also available in .
claim
release-assignment