Stream: t-compiler/major changes

Topic: Add a scheme to register functions from o… compiler-team#395


triagebot (Dec 30 2020 at 20:35, on Zulip):

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.

Joshua Nelson (Dec 30 2020 at 20:36, on Zulip):

could we use this for shrinking rustc_middle even more? :)

nagisa (Dec 30 2020 at 20:41, on Zulip):

Could we generalize the query subsystem to have queries that do not cache results and thus have lower overhead and don't require stablehash?

oli (Dec 30 2020 at 20:44, on Zulip):

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

oli (Dec 30 2020 at 20:44, on Zulip):

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

Joshua Nelson (Dec 30 2020 at 20:44, on Zulip):

I think the rust language in general could benefit from 'header files' where you can declare the function separately from implementing it

Joshua Nelson (Dec 30 2020 at 20:44, on Zulip):

I guess that's traits?

Joshua Nelson (Dec 30 2020 at 20:44, on Zulip):

@oli what's the difference between your idea and an extension trait?

oli (Dec 30 2020 at 20:45, on Zulip):

well... in my scheme, you can invoke the function on TyCtxt in rustc_middle and define the function in rustc_mir

lcnr (Dec 30 2020 at 20:45, on Zulip):

an extension trait must be either defined in the extern crate, in which case it can't be used in rustc_middle

lcnr (Dec 30 2020 at 20:46, on Zulip):

or defined in rustc_middle to use it, in which case you can't externally implement it for TyCtxt

triagebot (Dec 30 2020 at 20:46, on Zulip):

@T-compiler: Proposal #395 has been seconded, and will be approved in 10 days if no objections are raised.

Joshua Nelson (Dec 30 2020 at 20:47, on Zulip):

Hmm, that makes sense

lcnr (Dec 30 2020 at 20:47, on Zulip):

rust could benefit from "header files" or well, we could instead use extern functions

lcnr (Dec 30 2020 at 20:47, on Zulip):

and use #[no_mangle]

lcnr (Dec 30 2020 at 20:47, on Zulip):

but that seems worse to me

Joshua Nelson (Dec 30 2020 at 20:47, on Zulip):

This sort of sounds like #[global_allocator] where there should only be one implementation but you don't care where it is

lcnr (Dec 30 2020 at 20:47, on Zulip):

which is pretty much how header files work

oli (Dec 30 2020 at 20:48, on Zulip):

Yea, I'm looking for something that doesn't give linker errors ^^

lcnr (Dec 30 2020 at 20:49, on Zulip):

c is a nice language because it hides it's ugliness

simulacrum (Dec 30 2020 at 20:49, on Zulip):

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.

cjgillot (Dec 30 2020 at 23:32, on Zulip):

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.

RalfJ (Dec 31 2020 at 12:47, on Zulip):

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.

RalfJ (Dec 31 2020 at 12:47, on Zulip):

E.g., there could be some macro that is used for this such that one has some "key" to grep for.

triagebot (Jan 14 2021 at 13:29, on Zulip):

This proposal has been accepted: #395.

Last update: May 07 2021 at 07:45UTC