Tracking issue for RFC 2582, `&raw [mut | const] $place` (raw_ref_op)

[Centril]

This is a tracking issue for the RFC "an operator to take a raw reference" (rust-lang/rfcs#2582), feature(raw_ref_op).

Steps:

• Implement the RFC (see this comment for a detailed checklist)
• Adjust documentation (see instructions on rustc-guide): operator expressions: add &raw reference#1567
• Stabilization PR (see instructions on rustc-guide): Stabilize raw_ref_op (RFC 2582) #127679

Unresolved questions:

(None left here, since the lint was moved to #127724)

Implementation history:

• Initial implementation: Add a raw "address of" operator #64588

[matthewjasper]

I'll try to get a PR open for this soon.

[Centril]

I would suggest splitting the implementation work up into phases to make each part thoroughly reviewed and tested. However, think of this list as a bunch of tasks that need to be done at some point.

1. Implement &raw [mut | const] $expr in the parser and AST.
   • Ensure the unused_parens lint works alright.
   • Handle interactions in librustc_resolve.
2. Push things down from AST => HIR
   • Handle lowering
   • Handle type checking
3. Push things down from HIR => HAIR
4. Push things down from HAIR => MIR -- here, the actual MIR operation is introduced.
5. Introduce lints for statically detectable UB as per the RFC.
6. Make safe_packed_borrows a hard error when the feature gate is active, and make this the case as well for unsafe equivalents.

---

...but it seems @matthewjasper already has a PR heh.

[Aaron1011]

Make safe_packed_borrows a hard error when the feature gate is active, and make this the case as well for unsafe equivalents.

I'm not sure that this is a good idea. This would make it impossible to gradually migrate a codebase over to using raw references - once the feature gate is enabled, all references to packed structs must be fixed at once in order to get the crate building again.

[moshg]

I wonder why not &raw $expr but &raw const $expr. Is there a discussion about this?

[mjbshaw]

@moshg Yes, this was discussed. See here (and the following comments) for an initial discussion. And here (and the following comments) for a signoff from grammar-wg. And here for an example that &raw (expr) can be ambiguous.

I think it might be worth amending the RFC to state why &raw const $expr was chosen over &raw $expr.

[Ixrec]

The RFC thread noted a couple times (including in the FCP comment) that &raw expr without the const conflicts with existing syntax and would break real code. rust-lang/rfcs#2582 (comment) goes into some detail. My understanding is that it is still possible to migrate to &raw expr with breaking changes in an edition, and I didn't see much explicit discussion of that, but I think everyone agrees that there's enough urgency here that we definitely prefer making &raw const expr a thing over blocking any solution on waiting for another edition.

[moshg]

@mjbshaw @lxrec
Thank you for your explanations! I've understood why &raw $expr is breaking change.

[RalfJung]

I think it might be worth amending the RFC to state why &raw const $expr was chosen over &raw $expr.

rust-lang/rfcs#2764