operator expressions: add &raw #1567

RalfJung · 2024-08-10T11:41:57Z

Accompanying PR for rust-lang/rust#127679.
Fixes rust-lang/rust#64490.

I reworded things to avoid the "address-of" terminology, since a pointer is not just an address.

RalfJung · 2024-08-10T11:42:24Z

src/expressions/operator-expr.md

@@ -101,14 +101,14 @@ struct Packed {

 let packed = Packed { f1: 1, f2: 2 };
 // `&packed.f2` would create an unaligned reference, and thus be Undefined Behavior!
-let raw_f2 = ptr::addr_of!(packed.f2);
+let raw_f2 = &raw const packed.f2;


I assume this will fail in CI since the operator is not stable yet. Not sure how you usually stage this.

Yea, CI will just be red until the stabilization PR hits nightly, after which point we can merge this.

ehuss

Thanks!

Should the last sentence of the section https://github.com/rust-lang/reference/blob/master/src/types/pointer.md#raw-pointers-const-and-mut be updated to use the new syntax instead of addr_of?

And in general, should all other uses of addr_of in the reference be changed to use the new syntax? My understanding is that is now the preferred style, is that correct?

src/expressions/operator-expr.md

RalfJung · 2024-08-12T08:41:36Z

And in general, should all other uses of addr_of in the reference be changed to use the new syntax? My understanding is that is now the preferred style, is that correct?

Yes I think that's right.

src/expressions/operator-expr.md

Stabilize `raw_ref_op` (RFC 2582) This stabilizes the syntax `&raw const $expr` and `&raw mut $expr`. It has existed unstably for ~4 years now, and has been exposed on stable via the `addr_of` and `addr_of_mut` macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro: - Being macros, `addr_of`/`addr_of_mut` could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below `&`/`&mut`, so we can make the subtle topic a lot more approachable by connecting to existing intuition. - The name `addr_of` is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is *not* just an address. Strict provenance has a method, `addr`, which extracts the address of a pointer; using the term `addr` in two different ways is quite unfortunate. That's why this PR soft-deprecates `addr_of` -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and `&raw` avoids that potential confusion. In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in. Possible questions to consider, based on the RFC and [this](rust-lang#64490 (comment)) great summary by `@CAD97:` - Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake: - Should `&raw const *mut_ref` give a read-only pointer? - Tracked at: rust-lang/unsafe-code-guidelines#257 - I think ideally the answer is "no". Stacked Borrows says that pointer is read-only, but Tree Borrows says it is mutable. - What exactly does `&raw const (*ptr).field` require? Answered in [the reference](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html): the arithmetic to compute the field offset follows the rules of `ptr::offset`, making it UB if it goes out-of-bounds. Making this a safe operation (using `wrapping_offset` rules) is considered too much of a loss for alias analysis. - Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is `&raw $place` instead of `&raw const $place`, which (IIUC) could be achieved by making `raw` a contextual keyword in a new edition. The type is named `*const T`, so the explicit `const` is consistent in that regard. `&raw expr` lacks the explicit indication of immutability. However, `&raw const expr` is quite a but longer than `addr_of!(expr)`. - Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with `addr_of!` mentioned above. (If we keep the `&raw $place` syntax free for this, we could use it in the future for that new type.) - What about the lint the RFC talked about? It hasn't been implemented yet. Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization. - I created an issue to track adding it: rust-lang#127724 - Other points from the "future possibilites of the RFC - "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint. - Encouraging / requiring `&raw` in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for `static mut` a lint suggesting raw pointers is being rolled out. - Lowering of casts: this has been implemented. (It's also an invisible implementation detail.) - `offsetof` woes: we now have native `offset_of` so this is not relevant any more. To be done before landing: - [x] Suppress `unused_parens` lint around `&raw {const|mut}` expressions - See bottom of rust-lang#127679 (comment) for rationale - Implementation: rust-lang#128782 - [ ] Update the Reference. - rust-lang/reference#1567 Fixes rust-lang#64490 cc `@rust-lang/lang` `@rust-lang/opsem` try-job: x86_64-msvc try-job: i686-mingw try-job: test-various try-job: dist-various-1 try-job: armhf-gnu try-job: aarch64-apple

src/expressions.md

traviscross

Otherwise this looks good to me. We'll merge this once the stabilization PR is merged.

Stabilize `raw_ref_op` (RFC 2582) This stabilizes the syntax `&raw const $expr` and `&raw mut $expr`. It has existed unstably for ~4 years now, and has been exposed on stable via the `addr_of` and `addr_of_mut` macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro: - Being macros, `addr_of`/`addr_of_mut` could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below `&`/`&mut`, so we can make the subtle topic a lot more approachable by connecting to existing intuition. - The name `addr_of` is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is *not* just an address. Strict provenance has a method, `addr`, which extracts the address of a pointer; using the term `addr` in two different ways is quite unfortunate. That's why this PR soft-deprecates `addr_of` -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and `&raw` avoids that potential confusion. In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in. Possible questions to consider, based on the RFC and [this](rust-lang#64490 (comment)) great summary by `@CAD97:` - Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake: - Should `&raw const *mut_ref` give a read-only pointer? - Tracked at: rust-lang/unsafe-code-guidelines#257 - I think ideally the answer is "no". Stacked Borrows says that pointer is read-only, but Tree Borrows says it is mutable. - What exactly does `&raw const (*ptr).field` require? Answered in [the reference](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html): the arithmetic to compute the field offset follows the rules of `ptr::offset`, making it UB if it goes out-of-bounds. Making this a safe operation (using `wrapping_offset` rules) is considered too much of a loss for alias analysis. - Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is `&raw $place` instead of `&raw const $place`, which (IIUC) could be achieved by making `raw` a contextual keyword in a new edition. The type is named `*const T`, so the explicit `const` is consistent in that regard. `&raw expr` lacks the explicit indication of immutability. However, `&raw const expr` is quite a but longer than `addr_of!(expr)`. - Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with `addr_of!` mentioned above. (If we keep the `&raw $place` syntax free for this, we could use it in the future for that new type.) - What about the lint the RFC talked about? It hasn't been implemented yet. Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization. - I created an issue to track adding it: rust-lang#127724 - Other points from the "future possibilites of the RFC - "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint. - Encouraging / requiring `&raw` in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for `static mut` a lint suggesting raw pointers is being rolled out. - Lowering of casts: this has been implemented. (It's also an invisible implementation detail.) - `offsetof` woes: we now have native `offset_of` so this is not relevant any more. To be done before landing: - [x] Suppress `unused_parens` lint around `&raw {const|mut}` expressions - See bottom of rust-lang#127679 (comment) for rationale - Implementation: rust-lang#128782 - [ ] Update the Reference. - rust-lang/reference#1567 Fixes rust-lang#64490 cc `@rust-lang/lang` `@rust-lang/opsem` // try-job: i686-mingw // `dump-ice-to-disk` is flaky try-job: x86_64-msvc try-job: test-various try-job: dist-various-1 try-job: armhf-gnu try-job: aarch64-apple

…,jieyouxu Stabilize `raw_ref_op` (RFC 2582) This stabilizes the syntax `&raw const $expr` and `&raw mut $expr`. It has existed unstably for ~4 years now, and has been exposed on stable via the `addr_of` and `addr_of_mut` macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro: - Being macros, `addr_of`/`addr_of_mut` could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below `&`/`&mut`, so we can make the subtle topic a lot more approachable by connecting to existing intuition. - The name `addr_of` is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is *not* just an address. Strict provenance has a method, `addr`, which extracts the address of a pointer; using the term `addr` in two different ways is quite unfortunate. That's why this PR soft-deprecates `addr_of` -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and `&raw` avoids that potential confusion. In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in. Possible questions to consider, based on the RFC and [this](rust-lang#64490 (comment)) great summary by `@CAD97:` - Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake: - Should `&raw const *mut_ref` give a read-only pointer? - Tracked at: rust-lang/unsafe-code-guidelines#257 - I think ideally the answer is "no". Stacked Borrows says that pointer is read-only, but Tree Borrows says it is mutable. - What exactly does `&raw const (*ptr).field` require? Answered in [the reference](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html): the arithmetic to compute the field offset follows the rules of `ptr::offset`, making it UB if it goes out-of-bounds. Making this a safe operation (using `wrapping_offset` rules) is considered too much of a loss for alias analysis. - Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is `&raw $place` instead of `&raw const $place`, which (IIUC) could be achieved by making `raw` a contextual keyword in a new edition. The type is named `*const T`, so the explicit `const` is consistent in that regard. `&raw expr` lacks the explicit indication of immutability. However, `&raw const expr` is quite a but longer than `addr_of!(expr)`. - Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with `addr_of!` mentioned above. (If we keep the `&raw $place` syntax free for this, we could use it in the future for that new type.) - What about the lint the RFC talked about? It hasn't been implemented yet. Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization. - I created an issue to track adding it: rust-lang#127724 - Other points from the "future possibilites of the RFC - "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint. - Encouraging / requiring `&raw` in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for `static mut` a lint suggesting raw pointers is being rolled out. - Lowering of casts: this has been implemented. (It's also an invisible implementation detail.) - `offsetof` woes: we now have native `offset_of` so this is not relevant any more. To be done before landing: - [x] Suppress `unused_parens` lint around `&raw {const|mut}` expressions - See bottom of rust-lang#127679 (comment) for rationale - Implementation: rust-lang#128782 - [ ] Update the Reference. - rust-lang/reference#1567 Fixes rust-lang#64490 cc `@rust-lang/lang` `@rust-lang/opsem` try-job: x86_64-msvc try-job: test-various try-job: dist-various-1 try-job: armhf-gnu try-job: aarch64-apple

Stabilize `raw_ref_op` (RFC 2582) This stabilizes the syntax `&raw const $expr` and `&raw mut $expr`. It has existed unstably for ~4 years now, and has been exposed on stable via the `addr_of` and `addr_of_mut` macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro: - Being macros, `addr_of`/`addr_of_mut` could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below `&`/`&mut`, so we can make the subtle topic a lot more approachable by connecting to existing intuition. - The name `addr_of` is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is *not* just an address. Strict provenance has a method, `addr`, which extracts the address of a pointer; using the term `addr` in two different ways is quite unfortunate. That's why this PR soft-deprecates `addr_of` -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and `&raw` avoids that potential confusion. In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in. Possible questions to consider, based on the RFC and [this](rust-lang#64490 (comment)) great summary by `@CAD97:` - Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake: - Should `&raw const *mut_ref` give a read-only pointer? - Tracked at: rust-lang/unsafe-code-guidelines#257 - I think ideally the answer is "no". Stacked Borrows says that pointer is read-only, but Tree Borrows says it is mutable. - What exactly does `&raw const (*ptr).field` require? Answered in [the reference](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html): the arithmetic to compute the field offset follows the rules of `ptr::offset`, making it UB if it goes out-of-bounds. Making this a safe operation (using `wrapping_offset` rules) is considered too much of a loss for alias analysis. - Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is `&raw $place` instead of `&raw const $place`, which (IIUC) could be achieved by making `raw` a contextual keyword in a new edition. The type is named `*const T`, so the explicit `const` is consistent in that regard. `&raw expr` lacks the explicit indication of immutability. However, `&raw const expr` is quite a but longer than `addr_of!(expr)`. - Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with `addr_of!` mentioned above. (If we keep the `&raw $place` syntax free for this, we could use it in the future for that new type.) - What about the lint the RFC talked about? It hasn't been implemented yet. Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization. - I created an issue to track adding it: rust-lang#127724 - Other points from the "future possibilites of the RFC - "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint. - Encouraging / requiring `&raw` in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for `static mut` a lint suggesting raw pointers is being rolled out. - Lowering of casts: this has been implemented. (It's also an invisible implementation detail.) - `offsetof` woes: we now have native `offset_of` so this is not relevant any more. To be done before landing: - [x] Suppress `unused_parens` lint around `&raw {const|mut}` expressions - See bottom of rust-lang#127679 (comment) for rationale - Implementation: rust-lang#128782 - [ ] Update the Reference. - rust-lang/reference#1567 Fixes rust-lang#64490 cc `@rust-lang/lang` `@rust-lang/opsem` try-job: x86_64-msvc try-job: test-various try-job: dist-various-1 try-job: armhf-gnu try-job: aarch64-apple

Rollup merge of rust-lang#127679 - RalfJung:raw_ref_op, r=jieyouxu Stabilize `raw_ref_op` (RFC 2582) This stabilizes the syntax `&raw const $expr` and `&raw mut $expr`. It has existed unstably for ~4 years now, and has been exposed on stable via the `addr_of` and `addr_of_mut` macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro: - Being macros, `addr_of`/`addr_of_mut` could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below `&`/`&mut`, so we can make the subtle topic a lot more approachable by connecting to existing intuition. - The name `addr_of` is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is *not* just an address. Strict provenance has a method, `addr`, which extracts the address of a pointer; using the term `addr` in two different ways is quite unfortunate. That's why this PR soft-deprecates `addr_of` -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and `&raw` avoids that potential confusion. In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in. Possible questions to consider, based on the RFC and [this](rust-lang#64490 (comment)) great summary by `@CAD97:` - Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake: - Should `&raw const *mut_ref` give a read-only pointer? - Tracked at: rust-lang/unsafe-code-guidelines#257 - I think ideally the answer is "no". Stacked Borrows says that pointer is read-only, but Tree Borrows says it is mutable. - What exactly does `&raw const (*ptr).field` require? Answered in [the reference](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html): the arithmetic to compute the field offset follows the rules of `ptr::offset`, making it UB if it goes out-of-bounds. Making this a safe operation (using `wrapping_offset` rules) is considered too much of a loss for alias analysis. - Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is `&raw $place` instead of `&raw const $place`, which (IIUC) could be achieved by making `raw` a contextual keyword in a new edition. The type is named `*const T`, so the explicit `const` is consistent in that regard. `&raw expr` lacks the explicit indication of immutability. However, `&raw const expr` is quite a but longer than `addr_of!(expr)`. - Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with `addr_of!` mentioned above. (If we keep the `&raw $place` syntax free for this, we could use it in the future for that new type.) - What about the lint the RFC talked about? It hasn't been implemented yet. Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization. - I created an issue to track adding it: rust-lang#127724 - Other points from the "future possibilites of the RFC - "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint. - Encouraging / requiring `&raw` in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for `static mut` a lint suggesting raw pointers is being rolled out. - Lowering of casts: this has been implemented. (It's also an invisible implementation detail.) - `offsetof` woes: we now have native `offset_of` so this is not relevant any more. To be done before landing: - [x] Suppress `unused_parens` lint around `&raw {const|mut}` expressions - See bottom of rust-lang#127679 (comment) for rationale - Implementation: rust-lang#128782 - [ ] Update the Reference. - rust-lang/reference#1567 Fixes rust-lang#64490 cc `@rust-lang/lang` `@rust-lang/opsem` try-job: x86_64-msvc try-job: test-various try-job: dist-various-1 try-job: armhf-gnu try-job: aarch64-apple

Stabilize `raw_ref_op` (RFC 2582) This stabilizes the syntax `&raw const $expr` and `&raw mut $expr`. It has existed unstably for ~4 years now, and has been exposed on stable via the `addr_of` and `addr_of_mut` macros since Rust 1.51 (released more than 3 years ago). I think it has become clear that these operations are here to stay. So it is about time we give them proper primitive syntax. This has two advantages over the macro: - Being macros, `addr_of`/`addr_of_mut` could in theory do arbitrary magic with the expression on which they work. The only "magic" they actually do is using the argument as a place expression rather than as a value expression. Place expressions are already a subtle topic and poorly understood by many programmers; having this hidden behind a macro using unstable language features makes this even worse. Conversely, people do have an idea of what happens below `&`/`&mut`, so we can make the subtle topic a lot more approachable by connecting to existing intuition. - The name `addr_of` is quite unfortunate from today's perspective, given that we have accepted provenance as a reality, which means that a pointer is *not* just an address. Strict provenance has a method, `addr`, which extracts the address of a pointer; using the term `addr` in two different ways is quite unfortunate. That's why this PR soft-deprecates `addr_of` -- we will wait a long time before actually showing any warning here, but we should start telling people that the "addr" part of this name is somewhat misleading, and `&raw` avoids that potential confusion. In summary, this syntax improves developers' ability to conceptualize the operational semantics of Rust, while making a fundamental operation frequently used in unsafe code feel properly built in. Possible questions to consider, based on the RFC and [this](rust-lang/rust#64490 (comment)) great summary by `@CAD97:` - Some questions are entirely about the semantics. The semantics are the same as with the macros so I don't think this should have any impact on this syntax PR. Still, for completeness' sake: - Should `&raw const *mut_ref` give a read-only pointer? - Tracked at: rust-lang/unsafe-code-guidelines#257 - I think ideally the answer is "no". Stacked Borrows says that pointer is read-only, but Tree Borrows says it is mutable. - What exactly does `&raw const (*ptr).field` require? Answered in [the reference](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html): the arithmetic to compute the field offset follows the rules of `ptr::offset`, making it UB if it goes out-of-bounds. Making this a safe operation (using `wrapping_offset` rules) is considered too much of a loss for alias analysis. - Choose a different syntax? I don't want to re-litigate the RFC. The only credible alternative that has been proposed is `&raw $place` instead of `&raw const $place`, which (IIUC) could be achieved by making `raw` a contextual keyword in a new edition. The type is named `*const T`, so the explicit `const` is consistent in that regard. `&raw expr` lacks the explicit indication of immutability. However, `&raw const expr` is quite a but longer than `addr_of!(expr)`. - Shouldn't we have a completely new, better raw pointer type instead? Yes we all want to see that happen -- but I don't think we should block stabilization on that, given that such a nicer type is not on the horizon currently and given the issues with `addr_of!` mentioned above. (If we keep the `&raw $place` syntax free for this, we could use it in the future for that new type.) - What about the lint the RFC talked about? It hasn't been implemented yet. Given that the problematic code is UB with or without this stabilization, I don't think the lack of the lint should block stabilization. - I created an issue to track adding it: rust-lang/rust#127724 - Other points from the "future possibilites of the RFC - "Syntactic sugar" extension: this has not been implemented. I'd argue this is too confusing, we should stick to what the RFC suggested and if we want to do anything about such expressions, add the lint. - Encouraging / requiring `&raw` in situations where references are often/definitely incorrect: this has been / is being implemented. On packed fields this already is a hard error, and for `static mut` a lint suggesting raw pointers is being rolled out. - Lowering of casts: this has been implemented. (It's also an invisible implementation detail.) - `offsetof` woes: we now have native `offset_of` so this is not relevant any more. To be done before landing: - [x] Suppress `unused_parens` lint around `&raw {const|mut}` expressions - See bottom of rust-lang/rust#127679 (comment) for rationale - Implementation: rust-lang/rust#128782 - [ ] Update the Reference. - rust-lang/reference#1567 Fixes rust-lang/rust#64490 cc `@rust-lang/lang` `@rust-lang/opsem` try-job: x86_64-msvc try-job: test-various try-job: dist-various-1 try-job: armhf-gnu try-job: aarch64-apple

Update books ## rust-lang/book 4 commits in 04bc1396bb857f35b5dda1d773c9571e1f253304..e7d217be2a75ef1753f0988d6ccaba4d7e376259 2024-08-14 01:19:47 UTC to 2024-08-13 16:51:00 UTC - Backport/forward port ch12 (rust-lang/book#4008) - Found some more things to fix in ch7; I forgot to update the snapshot (rust-lang/book#4007) - Remove redundant sentence. Send to nostarch (rust-lang/book#4006) - Fix: typo (rust-lang/book#4003) ## rust-lang/edition-guide 5 commits in aeeb287d41a0332c210da122bea8e0e91844ab3e..eeba2cb9c37ab74118a4fb5e5233f7397e4a91f8 2024-08-19 23:28:06 UTC to 2024-08-15 15:12:33 UTC - 2024: Add rustdoc combined doctests (rust-lang/edition-guide#320) - Update for unsafe attributes stabilization (rust-lang/edition-guide#319) - 2024: Add macro-fragment-specifiers. (rust-lang/edition-guide#312) - Fix deprecated_safe_2024 link (rust-lang/edition-guide#317) - Add 2024 unsafe functions (rust-lang/edition-guide#304) ## rust-embedded/book 1 commits in 019f3928d8b939ec71b63722dcc2e46330156441..ff5d61d56f11e1986bfa9652c6aff7731576c37d 2024-08-20 07:26:19 UTC to 2024-08-20 07:26:19 UTC - Use aligned address to demonstrate HardFault (rust-embedded/book#374) ## rust-lang/nomicon 1 commits in 6ecf95c5f2bfa0e6314dfe282bf775fd1405f7e9..14649f15d232d509478206ee9ed5105641aa60d0 2024-08-14 14:49:09 UTC to 2024-08-14 14:49:09 UTC - CI: Switch to merge queue (rust-lang/nomicon#459) ## rust-lang/reference 14 commits in 62cd0df95061ba0ac886333f5cd7f3012f149da1..0668397076da350c404dadcf07b6cbc433ad3743 2024-08-11 21:06:12 +0000 to 2024-08-27 21:47:20 +0000 - Update enum.md (rust-lang/reference#1354) - Be consistent about how "Edition differences" is capitalized (rust-lang/reference#1586) - Sync denied lints with upstream (rust-lang/reference#1589) - const_eval: update for const-fn float stabilization (rust-lang/reference#1566) - Add spec identifier syntax to destructors.md (rust-lang/reference#1571) - Say that `pub(in path)` can't depend on `use` statements (rust-lang/reference#1559) - bytes inside implicitly const-promoted expressions are immutable (rust-lang/reference#1554) - Tweak `repr(transparent)` to mention requiring *at most* one non-1-ZST (rust-lang/reference#1568) - operator expressions: add &raw (rust-lang/reference#1567) - Rewrite the automatic std link translation, and switch to automatic links (rust-lang/reference#1578) - Add some basic docs for unsafe attrs (rust-lang/reference#1539) - don't capitalize Undefined Behavior (rust-lang/reference#1575) - add the `const` operand to docs for inline assembly (rust-lang/reference#1556) - Typo: 'a' to 'an' in type-coercions.md (rust-lang/reference#1572) ## rust-lang/rust-by-example 1 commits in 8f94061936e492159f4f6c09c0f917a7521893ff..859786c5bc99301bbc22fc631a5c2b341860da08 2024-08-26 10:30:48 UTC to 2024-08-26 10:30:48 UTC - Update primitives.md with examples (rust-lang/rust-by-example#1878) ## rust-lang/rustc-dev-guide 7 commits in 43d8378..fa928a6 2024-08-26 14:46:50 UTC to 2024-08-12 21:07:49 UTC - Fix x.py reference (rust-lang/rustc-dev-guide#2049) - Update `stabilization_guide.md` (rust-lang/rustc-dev-guide#2034) - Explain the internal `#[rustc_*]` TEST attributes used for debugging and inside tests (rust-lang/rustc-dev-guide#2046) - missing char (rust-lang/rustc-dev-guide#2047) - Replace direct http links to rustc-dev-guide.rust-lang.org (rust-lang/rustc-dev-guide#2044) - Update index.html, 39. The MIR: fix typo (rust-lang/rustc-dev-guide#2043) - Update LLVM docs (rust-lang/rustc-dev-guide#2039)

Rollup merge of rust-lang#129617 - rustbot:docs-update, r=ehuss Update books ## rust-lang/book 4 commits in 04bc1396bb857f35b5dda1d773c9571e1f253304..e7d217be2a75ef1753f0988d6ccaba4d7e376259 2024-08-14 01:19:47 UTC to 2024-08-13 16:51:00 UTC - Backport/forward port ch12 (rust-lang/book#4008) - Found some more things to fix in ch7; I forgot to update the snapshot (rust-lang/book#4007) - Remove redundant sentence. Send to nostarch (rust-lang/book#4006) - Fix: typo (rust-lang/book#4003) ## rust-lang/edition-guide 5 commits in aeeb287d41a0332c210da122bea8e0e91844ab3e..eeba2cb9c37ab74118a4fb5e5233f7397e4a91f8 2024-08-19 23:28:06 UTC to 2024-08-15 15:12:33 UTC - 2024: Add rustdoc combined doctests (rust-lang/edition-guide#320) - Update for unsafe attributes stabilization (rust-lang/edition-guide#319) - 2024: Add macro-fragment-specifiers. (rust-lang/edition-guide#312) - Fix deprecated_safe_2024 link (rust-lang/edition-guide#317) - Add 2024 unsafe functions (rust-lang/edition-guide#304) ## rust-embedded/book 1 commits in 019f3928d8b939ec71b63722dcc2e46330156441..ff5d61d56f11e1986bfa9652c6aff7731576c37d 2024-08-20 07:26:19 UTC to 2024-08-20 07:26:19 UTC - Use aligned address to demonstrate HardFault (rust-embedded/book#374) ## rust-lang/nomicon 1 commits in 6ecf95c5f2bfa0e6314dfe282bf775fd1405f7e9..14649f15d232d509478206ee9ed5105641aa60d0 2024-08-14 14:49:09 UTC to 2024-08-14 14:49:09 UTC - CI: Switch to merge queue (rust-lang/nomicon#459) ## rust-lang/reference 14 commits in 62cd0df95061ba0ac886333f5cd7f3012f149da1..0668397076da350c404dadcf07b6cbc433ad3743 2024-08-11 21:06:12 +0000 to 2024-08-27 21:47:20 +0000 - Update enum.md (rust-lang/reference#1354) - Be consistent about how "Edition differences" is capitalized (rust-lang/reference#1586) - Sync denied lints with upstream (rust-lang/reference#1589) - const_eval: update for const-fn float stabilization (rust-lang/reference#1566) - Add spec identifier syntax to destructors.md (rust-lang/reference#1571) - Say that `pub(in path)` can't depend on `use` statements (rust-lang/reference#1559) - bytes inside implicitly const-promoted expressions are immutable (rust-lang/reference#1554) - Tweak `repr(transparent)` to mention requiring *at most* one non-1-ZST (rust-lang/reference#1568) - operator expressions: add &raw (rust-lang/reference#1567) - Rewrite the automatic std link translation, and switch to automatic links (rust-lang/reference#1578) - Add some basic docs for unsafe attrs (rust-lang/reference#1539) - don't capitalize Undefined Behavior (rust-lang/reference#1575) - add the `const` operand to docs for inline assembly (rust-lang/reference#1556) - Typo: 'a' to 'an' in type-coercions.md (rust-lang/reference#1572) ## rust-lang/rust-by-example 1 commits in 8f94061936e492159f4f6c09c0f917a7521893ff..859786c5bc99301bbc22fc631a5c2b341860da08 2024-08-26 10:30:48 UTC to 2024-08-26 10:30:48 UTC - Update primitives.md with examples (rust-lang/rust-by-example#1878) ## rust-lang/rustc-dev-guide 7 commits in 43d8378..fa928a6 2024-08-26 14:46:50 UTC to 2024-08-12 21:07:49 UTC - Fix x.py reference (rust-lang/rustc-dev-guide#2049) - Update `stabilization_guide.md` (rust-lang/rustc-dev-guide#2034) - Explain the internal `#[rustc_*]` TEST attributes used for debugging and inside tests (rust-lang/rustc-dev-guide#2046) - missing char (rust-lang/rustc-dev-guide#2047) - Replace direct http links to rustc-dev-guide.rust-lang.org (rust-lang/rustc-dev-guide#2044) - Update index.html, 39. The MIR: fix typo (rust-lang/rustc-dev-guide#2043) - Update LLVM docs (rust-lang/rustc-dev-guide#2039)

Update books ## rust-lang/book 4 commits in 04bc1396bb857f35b5dda1d773c9571e1f253304..e7d217be2a75ef1753f0988d6ccaba4d7e376259 2024-08-14 01:19:47 UTC to 2024-08-13 16:51:00 UTC - Backport/forward port ch12 (rust-lang/book#4008) - Found some more things to fix in ch7; I forgot to update the snapshot (rust-lang/book#4007) - Remove redundant sentence. Send to nostarch (rust-lang/book#4006) - Fix: typo (rust-lang/book#4003) ## rust-lang/edition-guide 5 commits in aeeb287d41a0332c210da122bea8e0e91844ab3e..eeba2cb9c37ab74118a4fb5e5233f7397e4a91f8 2024-08-19 23:28:06 UTC to 2024-08-15 15:12:33 UTC - 2024: Add rustdoc combined doctests (rust-lang/edition-guide#320) - Update for unsafe attributes stabilization (rust-lang/edition-guide#319) - 2024: Add macro-fragment-specifiers. (rust-lang/edition-guide#312) - Fix deprecated_safe_2024 link (rust-lang/edition-guide#317) - Add 2024 unsafe functions (rust-lang/edition-guide#304) ## rust-embedded/book 1 commits in 019f3928d8b939ec71b63722dcc2e46330156441..ff5d61d56f11e1986bfa9652c6aff7731576c37d 2024-08-20 07:26:19 UTC to 2024-08-20 07:26:19 UTC - Use aligned address to demonstrate HardFault (rust-embedded/book#374) ## rust-lang/nomicon 1 commits in 6ecf95c5f2bfa0e6314dfe282bf775fd1405f7e9..14649f15d232d509478206ee9ed5105641aa60d0 2024-08-14 14:49:09 UTC to 2024-08-14 14:49:09 UTC - CI: Switch to merge queue (rust-lang/nomicon#459) ## rust-lang/reference 14 commits in 62cd0df95061ba0ac886333f5cd7f3012f149da1..0668397076da350c404dadcf07b6cbc433ad3743 2024-08-11 21:06:12 +0000 to 2024-08-27 21:47:20 +0000 - Update enum.md (rust-lang/reference#1354) - Be consistent about how "Edition differences" is capitalized (rust-lang/reference#1586) - Sync denied lints with upstream (rust-lang/reference#1589) - const_eval: update for const-fn float stabilization (rust-lang/reference#1566) - Add spec identifier syntax to destructors.md (rust-lang/reference#1571) - Say that `pub(in path)` can't depend on `use` statements (rust-lang/reference#1559) - bytes inside implicitly const-promoted expressions are immutable (rust-lang/reference#1554) - Tweak `repr(transparent)` to mention requiring *at most* one non-1-ZST (rust-lang/reference#1568) - operator expressions: add &raw (rust-lang/reference#1567) - Rewrite the automatic std link translation, and switch to automatic links (rust-lang/reference#1578) - Add some basic docs for unsafe attrs (rust-lang/reference#1539) - don't capitalize Undefined Behavior (rust-lang/reference#1575) - add the `const` operand to docs for inline assembly (rust-lang/reference#1556) - Typo: 'a' to 'an' in type-coercions.md (rust-lang/reference#1572) ## rust-lang/rust-by-example 1 commits in 8f94061936e492159f4f6c09c0f917a7521893ff..859786c5bc99301bbc22fc631a5c2b341860da08 2024-08-26 10:30:48 UTC to 2024-08-26 10:30:48 UTC - Update primitives.md with examples (rust-lang/rust-by-example#1878) ## rust-lang/rustc-dev-guide 7 commits in 43d83780db545a1ed6d45773312fc578987e3968..fa928a6d19e1666d8d811dfe3fd35cdad3b4e459 2024-08-26 14:46:50 UTC to 2024-08-12 21:07:49 UTC - Fix x.py reference (rust-lang/rustc-dev-guide#2049) - Update `stabilization_guide.md` (rust-lang/rustc-dev-guide#2034) - Explain the internal `#[rustc_*]` TEST attributes used for debugging and inside tests (rust-lang/rustc-dev-guide#2046) - missing char (rust-lang/rustc-dev-guide#2047) - Replace direct http links to rustc-dev-guide.rust-lang.org (rust-lang/rustc-dev-guide#2044) - Update index.html, 39. The MIR: fix typo (rust-lang/rustc-dev-guide#2043) - Update LLVM docs (rust-lang/rustc-dev-guide#2039)

This was missed in rust-lang#1567

RalfJung commented Aug 10, 2024

View reviewed changes

RalfJung force-pushed the raw-ptr-op branch from c1ec2bc to 631b808 Compare August 10, 2024 11:46

ehuss reviewed Aug 11, 2024

View reviewed changes

src/expressions/operator-expr.md Outdated Show resolved Hide resolved

src/expressions/operator-expr.md Outdated Show resolved Hide resolved

RalfJung force-pushed the raw-ptr-op branch from 631b808 to 3661765 Compare August 12, 2024 08:45

RalfJung commented Aug 12, 2024

View reviewed changes

src/expressions/operator-expr.md Outdated Show resolved Hide resolved

traviscross mentioned this pull request Aug 12, 2024

Stabilize raw_ref_op (RFC 2582) rust-lang/rust#127679

Merged

2 tasks

RalfJung force-pushed the raw-ptr-op branch 2 times, most recently from 9125538 to 8595e16 Compare August 15, 2024 09:30

RalfJung mentioned this pull request Aug 15, 2024

Tracking issue for RFC 2582, &raw [mut | const] $place (raw_ref_op) rust-lang/rust#64490

Closed

3 tasks

RalfJung force-pushed the raw-ptr-op branch from 8595e16 to 1c221c6 Compare August 15, 2024 16:51

traviscross reviewed Aug 18, 2024

View reviewed changes

src/expressions.md Outdated Show resolved Hide resolved

traviscross approved these changes Aug 18, 2024

View reviewed changes

traviscross added the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Aug 18, 2024

RalfJung added 3 commits August 20, 2024 08:17

operator expressions: add &raw

f73f6d6

use &raw instead of addr_of macros

060d2b3

markdown anchor tweaks

60ccf42

ehuss force-pushed the raw-ptr-op branch from 36d8fdf to 60ccf42 Compare August 20, 2024 15:17

ehuss added this pull request to the merge queue Aug 20, 2024

Merged via the queue into rust-lang:master with commit b1fced7 Aug 20, 2024
4 checks passed

RalfJung deleted the raw-ptr-op branch August 21, 2024 18:59

rustbot mentioned this pull request Aug 26, 2024

Update books rust-lang/rust#129617

Merged

ehuss added a commit to ehuss/reference that referenced this pull request Nov 25, 2024

Add raw weak keyword

1dd1c64

This was missed in rust-lang#1567

ehuss mentioned this pull request Nov 25, 2024

Fix weak keywords #1685

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

operator expressions: add &raw #1567

operator expressions: add &raw #1567

RalfJung commented Aug 10, 2024 •

edited

Loading

RalfJung Aug 10, 2024

ehuss Aug 11, 2024

ehuss left a comment

RalfJung commented Aug 12, 2024

traviscross left a comment

operator expressions: add &raw #1567

operator expressions: add &raw #1567

Conversation

RalfJung commented Aug 10, 2024 • edited Loading

RalfJung Aug 10, 2024

Choose a reason for hiding this comment

ehuss Aug 11, 2024

Choose a reason for hiding this comment

ehuss left a comment

Choose a reason for hiding this comment

RalfJung commented Aug 12, 2024

traviscross left a comment

Choose a reason for hiding this comment

RalfJung commented Aug 10, 2024 •

edited

Loading