Allow crates downstream of `rustc_middle` to define queries

[Zoxc]

Proposal

This proposes allowing crates downstream of rustc_middle to define their own queries. The crates defining queries still have to be upstream from rustc_interface.

This is useful as we can then define queries on types unavailable in rustc_middle or move types currently forced to be in rustc_middle to an appropriate location.

Crates will have a queries module listing queries, which uses macros to defined needed code like the current rustc_middle::queries.

Accessing queries will be done with an extension trait, so to use rustc_borrowck's queries you'd import rustc_borrowck::Queries, then you'd be able to call them on tcx.

Each crate defining queries will need their own state for the query system to use, so GlobalCtxt will have a rustc_borrowck: &'tcx dyn Any<'tcx> field per such crate (with some unsafe to make 'tcx work). That allows access to that state from TyCtxt. The state can be owned by rustc_interface.

Mentors or Reviewers

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Caution

Concerns (2 active)

• complexity
• fragmentation

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[oli-obk]

@rustbot concern complexity

Will write more on Zulip, but I don't see the value of this at this time. It adds extra complexity to the already complex system that others are trying to simplify right now. Also needs a little bit of extra indirection and dynamic operations, which may be a perf problem

[Zalathar]

@rustbot concern fragmentation

Right now all queries are declared in a single file (rustc_middle::queries), which has some drawbacks but also has big advantages for maintenance of the query system itself, because it's trivially easy to see a list of all queries with their types and modifiers, all in one place.

Allowing queries to be declared in downstream crates gives up that property, which shouldn't be done without a clear decision to accept the tradeoff.