added core::mem::reshape #130849

hazelwiss · 2024-09-25T18:50:22Z

tracking issue: #130848

rustbot · 2024-09-25T18:50:30Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @workingjubilee (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

rust-log-analyzer · 2024-09-25T19:19:15Z

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#16 2.838 Building wheels for collected packages: reuse
#16 2.839   Building wheel for reuse (pyproject.toml): started
#16 3.090   Building wheel for reuse (pyproject.toml): finished with status 'done'
#16 3.091   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132715 sha256=dfa09868353292d98f811d3efdb0d54d07389e808efc71d68e3b93c514bf8bec
#16 3.091   Stored in directory: /tmp/pip-ephem-wheel-cache-fnbbmtkz/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#16 3.094 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#16 3.485 Successfully installed attrs-23.2.0 binaryornot-0.4.4 boolean-py-4.0 chardet-5.2.0 jinja2-3.1.4 license-expression-30.3.0 markupsafe-2.1.5 python-debian-0.1.49 reuse-4.0.3 tomlkit-0.13.0
#16 3.486 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#16 DONE 3.6s

Noratrieb · 2024-09-25T19:20:52Z

library/core/src/mem/mod.rs

+        let result = ptr::read(dest);
+        ptr::write(dest, f(result));


this is not sound if f unwinds, as the value will be dropped twice. see https://docs.rs/replace_with/latest/replace_with/ for details. the design space here is nontrivial, as there are many possible behaviors to do on unwind. this should at least go through an ACP, but probably better for more general discussion on internals.rust-lang.org. i'd also suggesting searching there for previous discussion about "replace_with", which is what this function is generally called

yeah I just detected that myself and ran into a wall. Sounds good 👍

has there been any discussion about a feature to ensure a closure does not panic?

hm. this has probably come up in vague ways in many places but nothing concrete.

either way it's definitely both that will arrive any time soon, so it probably makes sense to close the PR and tracking issue for now

thank you for it anyways :3

Could you execute the closure inside an extern "C" wrapper func that would abort on unwind? I think I recently saw a PR on a helper that exposed abort on unwind (mirroring the catch_unwind function) using that technique

You're thinking of #130339

narpfel · 2024-09-26T19:18:35Z

library/core/src/mem/mod.rs

+///
+/// let mut v: Vec<i32> = vec![1, 2];
+///
+/// mem::replace(&mut v, |mut v| { v.push(3); v });


Suggested change

/// mem::replace(&mut v, |mut v| { v.push(3); v });

/// mem::reshape(&mut v, |mut v| { v.push(3); v });

Should this be reshape?

bjorn3 · 2024-09-27T13:36:13Z

library/core/src/mem/mod.rs

+/// ```
+#[inline]
+#[unstable(feature = "mem_reshape", issue = "130848")]
+pub fn reshape<T>(dest: &mut T, f: impl FnOnce(T) -> T) {


I don't think this is a good name. When I first came across the tracking issue in the issue list, I though this was something transmute related.

Dylan-DPC · 2024-11-27T14:49:14Z

@hazelwiss do you still want to go ahead with this? this needs an ACP which hasn't been return and i think above some folks aren't happy with the naming and other things

hazelwiss · 2024-11-27T15:25:29Z

@Dylan-DPC Yes! I was under the impression people wanted to close this PR in favour of something else, but I would gladly go ahead with this. I can fix both the naming and look into making an ACP for this.

workingjubilee · 2024-11-27T21:02:07Z

This needs a better motivation that is not easily replaced by the mutable reference.

workingjubilee · 2024-11-29T19:05:38Z

It also probably needs to be named something similar to replace_with, because that's what this is.

clarfonthey · 2024-11-29T20:26:01Z

I was under the impression that there were concerns that this kind of function cannot be sound, and that's why it isn't offered, but I could be wrong. The main problem is that you have to ensure that you can never observe the value while it's been moved out of the reference, which requires ensuring that the closure either cannot panic or cannot return after panicking, i.e. aborts on panic.

This could potentially be an option on &mut MaybeUninit<T> though, returning &mut T on a successful call.

workingjubilee · 2024-11-30T00:55:49Z

Yes, this is RFC 1736 all over again.

workingjubilee · 2024-11-30T01:03:32Z

@Dylan-DPC Yes! I was under the impression people wanted to close this PR in favour of something else, but I would gladly go ahead with this. I can fix both the naming and look into making an ACP for this.

What I want is to either

not close this PR until I am sure you have been given the best opportunity to understand why it will be closed, as I'd rather you not leave with an impression
see this undergo the changes needed to make it something that will not be rejected, which will probably not be a minor edit here and there

Which path you wish to go down is your choice.

You did not respond to the recommendation to close this issue, so I was not certain you had read the latest comments or if you had a question about them. I thus mostly focused on advancing the other PRs in my queue.

hazelwiss · 2024-11-30T11:48:44Z

@workingjubilee I don't have a problem closing this issue/pr especially if it's a duplicate! Whichever you guys think is the best decision! I have no particular impression, all the feedback makes sense.

workingjubilee · 2024-11-30T23:53:36Z

I don't believe this is what I would call a duplicate. A duplicate implies that the previous issue fully encompasses the current one, but it has been some time since replace_with was first proposed, and Rust has evolved as a language since then. It's not clear the same soundness problems would matter as much now to Rust, or what mitigations would be acceptable, or how opsem differences matter, or if a changed type like clarfonthey proposes would be enough to carry it, or etc.

However, one would need to first absorb why replace_with failed in 2016 before they could make it succeed in 2025. You'd need to identify which of the grounds it was effectively rejected on could now themselves be dismissed.

We can help you do so, but that's a nontrivial task, and I don't believe it's the sort of thing that will happen over a single PR of iterations, so I am closing this for now.

added core::mem::reshape

6882205

rustbot assigned workingjubilee Sep 25, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 25, 2024

This comment has been minimized.

Sign in to view

hazelwiss added 2 commits September 25, 2024 20:59

added simple documentation

ef3048e

added tracking issue

d1169fd

hazelwiss mentioned this pull request Sep 25, 2024

Tracking Issue for mem_reshape #130848

Open

3 tasks

This comment has been minimized.

Sign in to view

removed unused variable in test

9bd7cbe

Noratrieb reviewed Sep 25, 2024

View reviewed changes

workingjubilee added S-waiting-on-ACP Status: PR has an ACP and is waiting for the ACP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 26, 2024

narpfel reviewed Sep 26, 2024

View reviewed changes

bjorn3 reviewed Sep 27, 2024

View reviewed changes

workingjubilee closed this Nov 30, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

added core::mem::reshape #130849

added core::mem::reshape #130849

hazelwiss commented Sep 25, 2024

rustbot commented Sep 25, 2024

This comment has been minimized.

This comment has been minimized.

rust-log-analyzer commented Sep 25, 2024

Noratrieb Sep 25, 2024

hazelwiss Sep 25, 2024

hazelwiss Sep 25, 2024

Noratrieb Sep 25, 2024

Noratrieb Sep 25, 2024

Noratrieb Sep 25, 2024

hazelwiss Sep 25, 2024

juntyr Sep 26, 2024

workingjubilee Sep 26, 2024

narpfel Sep 26, 2024

bjorn3 Sep 27, 2024

Dylan-DPC commented Nov 27, 2024

hazelwiss commented Nov 27, 2024

workingjubilee commented Nov 27, 2024

workingjubilee commented Nov 29, 2024

clarfonthey commented Nov 29, 2024 •

edited

Loading

workingjubilee commented Nov 30, 2024

workingjubilee commented Nov 30, 2024 •

edited

Loading

hazelwiss commented Nov 30, 2024

workingjubilee commented Nov 30, 2024

	/// mem::replace(&mut v, \|mut v\| { v.push(3); v });
	/// mem::reshape(&mut v, \|mut v\| { v.push(3); v });

added core::mem::reshape #130849

added core::mem::reshape #130849

Conversation

hazelwiss commented Sep 25, 2024

rustbot commented Sep 25, 2024

This comment has been minimized.

This comment has been minimized.

rust-log-analyzer commented Sep 25, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Dylan-DPC commented Nov 27, 2024

hazelwiss commented Nov 27, 2024

workingjubilee commented Nov 27, 2024

workingjubilee commented Nov 29, 2024

clarfonthey commented Nov 29, 2024 • edited Loading

workingjubilee commented Nov 30, 2024

workingjubilee commented Nov 30, 2024 • edited Loading

hazelwiss commented Nov 30, 2024

workingjubilee commented Nov 30, 2024

clarfonthey commented Nov 29, 2024 •

edited

Loading

workingjubilee commented Nov 30, 2024 •

edited

Loading