A new proposal has been announced: Add a scheme to register functions from other crates with TyCtxt #395. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.
could we use this for shrinking rustc_middle even more? :)
Could we generalize the query subsystem to have queries that do not cache results and thus have lower overhead and don't require stablehash?
I think we already have a bunch of attributes on queries in that direction. I was mostly hoping for avoiding the query infrastructure entirely and just have a function pointer and a wrapper function that calls the pointer
Joshua Nelson said:
could we use this for shrinking rustc_middle even more? :smile:
I'm hoping for this to be a welcome side effect of such a system, yes
I think the rust language in general could benefit from 'header files' where you can declare the function separately from implementing it
I guess that's traits?
@oli what's the difference between your idea and an extension trait?
well... in my scheme, you can invoke the function on
rustc_middle and define the function in
an extension trait must be either defined in the extern crate, in which case it can't be used in
or defined in
rustc_middle to use it, in which case you can't externally implement it for
@T-compiler: Proposal #395 has been seconded, and will be approved in 10 days if no objections are raised.
Hmm, that makes sense
rust could benefit from "header files" or well, we could instead use extern functions
but that seems worse to me
This sort of sounds like #[global_allocator] where there should only be one implementation but you don't care where it is
which is pretty much how header files work
Yea, I'm looking for something that doesn't give linker errors ^^
c is a nice language because it hides it's ugliness
I think starting with traits or so is right, and if it gets too painful or performance cost is too high we can replace it with linker and compiler magic.
In my opinion, rustc_middle now essentially contains datatype definitions and the query system. Without the query system, it is essentially of the same size at rustc_typeck. This kind of forward declarations can make the call graph even more complex than it is now.
I think my only concern here is debuggability -- already with queries, it can be quite hard to figure out "which code is executed by this function call". Grepping for "the query implementation" is non-trivial. It would be good to consider this.
E.g., there could be some macro that is used for this such that one has some "key" to grep for.
This proposal has been accepted: #395.