Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add raw_ref macros #72279

Merged
merged 2 commits into from
Jun 19, 2020
Merged

add raw_ref macros #72279

merged 2 commits into from
Jun 19, 2020

Conversation

RalfJung
Copy link
Member

In #64490, various people were in favor of exposing &raw as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.

I'll create the tracking issue if we're okay moving forward with this.

@rust-highfive
Copy link
Collaborator

r? @LukasKalbertodt

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 16, 2020
@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented May 18, 2020

This was discussed again in the @rust-lang/lang team meeting, and the general consensus in #64490 (comment) has not changed. The question of whether some form of rust-lang/rfcs#2919 before stabilizing these macros was briefly discussed but not conclusively answered.

AFAIK, all this needs is sign-off from T-libs on the precise syntax and the implementation.

@nikomatsakis nikomatsakis added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label May 18, 2020
@nikomatsakis
Copy link
Contributor

@rfcbot fcp merge

Proposal

Introduce two macros

  • raw_ref!(path)
  • raw_ref_mut!(path)

which borrow the contents at path and produce (respectively) *const T and *mut T raw pointers.

Motivation for exposing these capabilities

Unlike the & syntax, no "safe reference" is created. This means that the resulting raw pointer can be misaligned
or invalid to dereference and that is not UB until the pointer is actually dereferenced. For more details see RFC 2582.

Motivation for using macro-based syntax

This is an alternative to the previous syntax specified in RFC 2582, which was &raw const and &raw mut.

The motivations for making this change is that the syntax &raw const and &raw mut is not seen as particularly ideal. Among its downsides:

  • It is verbose and wordy.
  • It introduces a fresh contextual keyword raw.
  • It breaks the symmetry that we previously have had, where &foo creates a &T type (and &mut foo creates a &mut T) type.

Further, we think that there may be an opportunity to revisit raw-pointer ergonomics in a bigger way that could improve the language overall (some background available in these three messages, particularly the final one). We don't feel ready to decide if that opportunity is worth the resulting churn, but we don't feel the need to commit to syntax like &raw const that may become deprecated.

Future possibilities

The raw_ref and raw_ref_mut macros would be stable and hence usable in perpetuity. If we do wind up adopting a larger "raw pointer reform" than these macros might be deprecated in favor of the newer types and operators.

On the other hand, if we wind up deciding that larger "raw pointer reform" doesn't make sense, we might add some more "builtin" syntax than the raw_ref macros. Alternatively, we might simply keep the macros as they are, as they address a somewhat niche concern (creating raw pointers to invalid or unaligned memory, where the rules for a standard reference would be invalid).

@rfcbot
Copy link

rfcbot commented May 19, 2020

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels May 19, 2020
@Dylan-DPC-zz
Copy link

r? @cramertj

@nikomatsakis
Copy link
Contributor

Nominating for next lang-team meeting to draw attention these checkboxes.

bors bot added a commit to rust-lang/rust-analyzer that referenced this pull request May 29, 2020
4648: Support raw_ref_op's raw reference operator r=matklad a=robojumper

Fixes #4642.

This syntax (and its semantics) are implemented in rustc behind the `raw_ref_op` feature.

It is not entirely clear whether this is the syntax that will become stable, but [it seems like](rust-lang/rust#72279) rust-analyzer must still support this unstable syntax to support future stable rust.

Also fixes a random inference failure involving a direct coercion from `&[T, _]` to `*const [T]`.

Co-authored-by: robojumper <[email protected]>
@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jun 1, 2020
@rfcbot
Copy link

rfcbot commented Jun 1, 2020

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jun 1, 2020
@scottmcm
Copy link
Member

scottmcm commented Jun 1, 2020

@rfcbot reviewed

Definitely no concerns with this as unstable.

@mystor
Copy link
Contributor

mystor commented Jun 4, 2020

Due to the const provenance issues @Gankra mentioned in #64490 (comment), I would think that we'd want people to prefer using *mut over *const when they can, as it probably produces the expected behaviour wrt stacked borrows. If that's still the case, it seems a bit unfortunate that the proposed macro names make the mut variant less ergonomic to write then the const variant, encouraging the use of raw_ref! by default.

Perhaps raw_const_ref! and raw_mut_ref! (or raw_ref_const!/raw_ref_mut!) would be better names?

@brain0
Copy link

brain0 commented Jun 4, 2020

Perhaps raw_const_ref! and raw_mut_ref! (or raw_ref_const!/raw_ref_mut!) would be better names?

The usual Rust naming convention would be raw_ref! and raw_mut! (same as the as_raw() and as_mut() methods).

Another alternative would be raw_const! and raw_mut! to be consistent with *const and *mut. Since the result is not actually a reference, but a raw pointer, I would personally prefer this syntax.

@RalfJung
Copy link
Member Author

RalfJung commented Jun 5, 2020

I can change the name to anything as long as there's consensus. :) Don't really care myself.

@withoutboats
Copy link
Contributor

maybe even raw_const_ptr / raw_mut_ptr. These are exposed from the root of std, right?

@RalfJung
Copy link
Member Author

RalfJung commented Jun 5, 2020

These are exposed from the root of std, right?

Yes, but I can also make them "macro 2.0" macros and put them into some module -- I was not sure if that is already acceptable to do.

@nikomatsakis
Copy link
Contributor

I don't have a strong opinion about the names we use, and I would love @rust-lang/libs feedback on the best way to expose them. I think something like std::ptr::raw!(...) or something might be nice, if we are doing that.

@sfackler
Copy link
Member

sfackler commented Jun 6, 2020

I'd definitely prefer to have them be located in ptr rather than the crate root personally.

@withoutboats
Copy link
Contributor

I think having them available only at the paths std::ptr::raw_const and std::ptr::raw_mut would be ideal, but I think this is the first time std would expose macros that way, and I'm not sure what the bigger picture of doing that is (does it work in 2015 edition / do we care? are we comfortable starting to do this with std macros in general? etc)

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jun 16, 2020

📌 Commit 0265e4e has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 16, 2020
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 16, 2020
…akis

add raw_ref macros

In rust-lang#64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.

I'll create the tracking issue if we're okay moving forward with this.
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 16, 2020
…akis

add raw_ref macros

In rust-lang#64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.

I'll create the tracking issue if we're okay moving forward with this.
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 16, 2020
…akis

add raw_ref macros

In rust-lang#64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.

I'll create the tracking issue if we're okay moving forward with this.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jun 17, 2020
…akis

add raw_ref macros

In rust-lang#64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.

I'll create the tracking issue if we're okay moving forward with this.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jun 17, 2020
…akis

add raw_ref macros

In rust-lang#64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.

I'll create the tracking issue if we're okay moving forward with this.
tmandry added a commit to tmandry/rust that referenced this pull request Jun 17, 2020
…akis

add raw_ref macros

In rust-lang#64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.

I'll create the tracking issue if we're okay moving forward with this.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 19, 2020
…arth

Rollup of 17 pull requests

Successful merges:

 - rust-lang#70551 (Make all uses of ty::Error delay a span bug)
 - rust-lang#71338 (Expand "recursive opaque type" diagnostic)
 - rust-lang#71976 (Improve diagnostics for `let x += 1`)
 - rust-lang#72279 (add raw_ref macros)
 - rust-lang#72628 (Add tests for 'impl Default for [T; N]')
 - rust-lang#72804 (Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position)
 - rust-lang#72814 (remove visit_terminator_kind from MIR visitor)
 - rust-lang#72836 (Complete the std::time documentation to warn about the inconsistencies between OS)
 - rust-lang#72968 (Only highlight doc search results via mouseover if mouse has moved)
 - rust-lang#73034 (Export `#[inline]` fns with extern indicators)
 - rust-lang#73315 (Clean up some weird command strings)
 - rust-lang#73320 (Make new type param suggestion more targetted)
 - rust-lang#73361 (Tweak "non-primitive cast" error)
 - rust-lang#73425 (Mention functions pointers in the documentation)
 - rust-lang#73428 (Fix typo in librustc_ast docs)
 - rust-lang#73447 (Improve document for `Result::as_deref(_mut)` methods)
 - rust-lang#73476 (Added tooltip for should_panic code examples)

Failed merges:

r? @ghost
@bors bors merged commit 49ab0ca into rust-lang:master Jun 19, 2020
@RalfJung RalfJung deleted the raw-ref-macros branch June 20, 2020 10:07
fbq added a commit to fbq/memoffset that referenced this pull request Mar 8, 2021
Since Rust 1.51.0, support for macro addr_of!() has been stabilized[1],
and this provides a way to get a raw pointer without potential UB in
some cases.

Memoffset alreadly uses the feature at the pre-stablilized stage (the
macro was named as raw_const then). Therefore, switch to use the
stablilized version (and name) and remove the out-dated version, also
remove the related feature gate.

[1]: rust-lang/rust#72279

Signed-off-by: Boqun Feng <[email protected]>
fbq added a commit to fbq/memoffset that referenced this pull request Mar 8, 2021
Since Rust 1.51.0, support for macro addr_of! has been stabilized[1],
and this provides a way to get a raw pointer without potential UB in
some cases.

Memoffset alreadly uses the feature at the pre-stablilized stage (the
macro was named as raw_const! then). Therefore, switch to use the
stablilized version (and name) if Rust 1.51.0 and above is used,
otherwise use the original fallback version, which works in a less
technically correct way.

[1]: rust-lang/rust#72279

Signed-off-by: Boqun Feng <[email protected]>
fbq added a commit to fbq/memoffset that referenced this pull request Mar 8, 2021
Since Rust 1.51.0, support for macro addr_of! has been stabilized[1],
and this provides a way to get a raw pointer without potential UB in
some cases.

Memoffset alreadly uses the feature at the pre-stablilized stage (the
macro was named as raw_const! then). Therefore, switch to use the
stablilized version (and name) if Rust 1.51.0 and above is used,
otherwise use the original fallback version, which works in a less
technically correct way.

[1]: rust-lang/rust#72279

Signed-off-by: Boqun Feng <[email protected]>
RalfJung pushed a commit to Gilnaa/memoffset that referenced this pull request Mar 8, 2021
Since Rust 1.51.0, support for macro addr_of! has been stabilized[1],
and this provides a way to get a raw pointer without potential UB in
some cases.

Memoffset alreadly uses the feature at the pre-stablilized stage (the
macro was named as raw_const! then). Therefore, switch to use the
stablilized version (and name) if Rust 1.51.0 and above is used,
otherwise use the original fallback version, which works in a less
technically correct way.

[1]: rust-lang/rust#72279

Signed-off-by: Boqun Feng <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.