Skip to content

Raw handle macros for field projection experiments - #164627

Open
dingxiangfei2009 wants to merge 2 commits into
rust-lang:mainfrom
dingxiangfei2009:raw-handle-macros
Open

dingxiangfei2009 wants to merge 2 commits into
rust-lang:mainfrom
dingxiangfei2009:raw-handle-macros

Conversation

@dingxiangfei2009

@dingxiangfei2009 dingxiangfei2009 commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

🐉 Highly experimental field projection primitive raw_handle!

r? @oli-obk

cc @ShaddyDC
cc @ojeda
cc @BennoLossin

We would like to submit this patch to start the experiment with the LocalHandle and PlaceHandle. We intend to continue polishing it in a patch series following this initial patch.

We know that the following items are not working.

  • Closure capture is still hanging in the air, this will be another major work.
  • Library trait wording. Field projection design in general is still shifting landscape, so many pieces as presented here would change. We will continue submitting patches to match the design.

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue. labels Oct 20, 2026
@rust-log-analyzer

This comment has been minimized.

Comment thread compiler/rustc_ast/src/ast.rs Resolved
@rust-log-analyzer

This comment has been minimized.

@rust-bors

This comment has been minimized.

Signed-off-by: Xiangfei Ding <dingxiangfei2009@protonmail.ch>
@oli-obk oli-obk added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. A-repr Area: the `#[repr(stuff)]` attribute and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 9, 2026
@dingxiangfei2009

Copy link
Copy Markdown
Contributor Author

@rustbot ready

@dingxiangfei2009
dingxiangfei2009 marked this pull request as ready for review November 9, 2026 15:23
@rustbot

rustbot commented Nov 9, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

HIR ty lowering was modified

cc @fmease

rustfmt is developed in its own repository. If possible, consider making this change to rust-lang/rustfmt instead.

cc @rust-lang/rustfmt

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

@BennoLossin

Copy link
Copy Markdown
Contributor

hey @oli-obk it would be great if we could get this merged before the cutoff for 1.102. we have some further additions that we'll want to make, but those can be done in separate PRs. I'd also really like to get to a more incremental dev cycle here.

one note on this PR, Ding and I were in a meeting just now and we noticed that we don't yet have a Deref variant in FieldProjectKind. Ding will add that later today.

@rust-log-analyzer

This comment has been minimized.

@dingxiangfei2009
dingxiangfei2009 force-pushed the raw-handle-macros branch 3 times, most recently from bd6ca0b to aeca9e4 Compare November 10, 2026 14:38
Co-authored-by: Xiangfei Ding <dingxiangfei2009protonmail.ch>
Signed-off-by: Rasmus Piorr <piorr@google.com>
Signed-off-by: Xiangfei Ding <dingxiangfei2009@protonmail.ch>
@rust-bors

rust-bors Bot commented Nov 10, 2026

Copy link
Copy Markdown
Contributor

☔ The latest upstream changes (presumably #165760) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

@oli-obk oli-obk left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First review round

View changes since this review

let place_with_id = self.cat_res(opr.hir_id, opr.span, root_ty, res)?;
// NOTE(dingxiangfei2009,shaddydc): Technically we should capture the root
// local **via LocalHandle**, but upvar does not understand this yet.
// We shall come back and add a new upvar capture just for this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the effect of the current capture system? overcapturing? document the current behaviour and what changing it would mean

}
}

fn lower_raw_handle_step(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move these functions and everything else field projection related into a seprate module

Comment on lines 106 to 108
pub macro raw_handle($place:expr) {
k#raw_handle($place)
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw, why does this go through the custom syntax scheme instead of just having a builtin macro expand directly to the right ast without having the parser handle it?

@fmease fmease Nov 13, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per MCP 580 | Add builtin# for compiler-intrinsic syntax, built-in macros should not expand to syntactic constructs that cannot be otherwise named in the surface language since it would blur the line between macros and "language extensions" as the MCP calls it.

So for example a built-in macro like line is fine because it it expands to a string literal which can be named in the surface language.

Expanding to internal syntax isn't necessarily done to write less code in the compiler, it's mainly just a matter of principle.

OffsetOf(&'hir Ty<'hir>, &'hir [Ident]),

/// Raw place handle (`raw_handle!`)
RawHandle(&'hir FieldProject<'hir>),

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need this as a hir::Node anywhere? It's always part of an expression, so it could just not have its own HirId and just live in the ExprKind

self.pclose();
}
ast::ExprKind::RawHandle(expr) => {
self.word("k#raw_handle");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may be better to print as the macro, and probably should add a rustfmt test now, too, otherwise you may get funny things like rustfmt changing your raw_handle!(...) call into k#raw_handle(...)

fn visit_expr(&mut self, ex: &'v Expr<'v>) -> Self::Result {
walk_expr(self, ex)
}
fn visit_field_project(&mut self, fp: &'v FieldProject<'v>) -> Self::Result {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need this for anything? Could only add it once needed

#[derive(Debug, Clone, Copy, StableHash)]
pub struct FieldProject<'hir> {
#[stable_hash(ignore)]
pub hir_id: HirId,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't really need this id afaict, the surrounding expression always already has an id. Or is this its own node because you wanna store sth per nested FieldProject?

I wonder if we should just have prefix: &[FieldProjectKind] and path: QPath fields instead of having a nested enum structure that always terminates with Path.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 11, 2026
@rustbot

rustbot commented Nov 11, 2026

Copy link
Copy Markdown
Collaborator

Reminder, once the PR becomes ready for a review, use @rustbot ready.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-repr Area: the `#[repr(stuff)]` attribute S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants