From 6a09e54876b302feb4f66e055c39fa4007755a5c Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 22 Aug 2024 09:54:09 +0200 Subject: [PATCH 1/1] clarify how 'let _' relates to the grammar above --- personal/_posts/2024-08-14-places.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/personal/_posts/2024-08-14-places.md b/personal/_posts/2024-08-14-places.md index 8f3532c..813bfc9 100644 --- a/personal/_posts/2024-08-14-places.md +++ b/personal/_posts/2024-08-14-places.md @@ -126,10 +126,16 @@ let _ = *ptr; // This is fine! let _val = *ptr; // This is UB. ``` -The reason for this is that the `_` pattern does *not* incur a place-to-value coercion. +Note that the grammar above cannot represent this program: in the full grammar of Rust, the `let` syntax is something like "`let` _Pattern_ `=` _PlaceExpr_ `;`", +and then pattern desugaring decides what to do with that place expression. +If the pattern is a binder (the common case), a `load` gets inserted to compute the initial value for the local variable that this binder refers to. +However, if the pattern is `_`, then the place expression still gets evaluated---but the result of that evaluation is simply discarded. +MIR uses a `PlaceMention` statement to indicate these semantics. + +In particular, this means that the `_` pattern does *not* incur a place-to-value coercion! The desugared form of the relevant part of this code is: ```rust -let _ = *(load ptr); // This is fine! +PlaceMention(*(load ptr)); // This is fine! let _val = load *(load ptr); // This is UB. ``` As you can see, the first line does not actually load from the pointer (the only `load` is there to load the pointer itself from the local variable that stores it). -- 2.30.2