re-land #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) #62825

ishitatsuyuki · 2019-07-20T14:18:06Z

#62150 got reverted to give users some time to migrate; we should re-land it.

Original issue:

#62150 has changed the behavior of mem::uninitialized() (and zeroed()), causing a few popular crates to be killed by SIGILL. A writeup can be found here.

There are cases where outdated (EOL) versions of downstream dependencies have this issue. In that case, the upstream crate will have to migrate to a newer major version of the dependency, which means it will have to deal with those breaking changes.

Therefore, I suggest we back out the change for at least one stable release, providing the community with the time to upgrade.

cc @RalfJung

The text was updated successfully, but these errors were encountered:

RalfJung · 2019-07-20T15:19:44Z

Note that (to my knowledge) this change is in nightly only currently, and won't become stable until 1.38 (released in late September). But it causes trouble already now e.g. by making CI fail, I suppose.

Nominating for lang team discussion. I hope I am doing this right.^^

RalfJung · 2019-07-20T15:23:51Z

Some more relevant discussion:

Creating a reference with std::mem::zeroed generates a SIGILL #52898 (comment) is an old issue about mem::zeroed causing SIGILLs when used incorrectly.
I proposed to eventually make zeroed (and uninitialized) panic deterministically for some more cases that we can detect statically, likely including the ones causing issues here. But we should probably wait a bit with this.

joshtriplett · 2019-07-25T19:31:05Z

Rather than panicking at runtime, could we detect this at compile-time, and issue a compile-time warning about calling mem::uninitialized or mem::zeroed with a type of &T or a function type or similar?

I think we need some kind of compile-time warning that people can start fixing, so that people know they need to fix this. Otherwise, we'll be in the same boat when we un-revert this.

joshtriplett · 2019-07-25T19:35:53Z

Based on discussion in the lang team: we'd be fine with backing this out, but we do need a lint or similar mechanism to make sure people notice and fix code.

RalfJung · 2019-07-25T19:37:04Z

@joshtriplett

Rather than panicking at runtime, could we detect this at compile-time, and issue a compile-time warning about calling mem::uninitialized or mem::zeroed with a type of &T or a function type or similar?

I assume you are responding to this proposal?

For some cases yes, but not reliably in generic contexts.

joshtriplett · 2019-07-26T00:09:43Z

On July 25, 2019 12:38:13 PM PDT, Ralf Jung ***@***.***> wrote: @joshtriplett > Rather than panicking at runtime, could we detect this at compile-time, and issue a compile-time warning about calling mem::uninitialized or mem::zeroed with a type of &T or a function type or similar? I assume you are responding to [this proposal](https://internals.rust-lang.org/t/make-mem-uninitialized-and-mem-zeroed-panic-for-some-types-where-0-is-a-niche/10605)? For some cases yes, but not reliably in generic contexts.

Doesn't have to be perfect. If we can detect common cases like `&T` and function types, that would help people know they need to migrate.

RalfJung · 2019-07-26T08:26:04Z

Agreed. I think we can do something that traverses the type as far as we see it, and complains when it finds a reference, fn, NonNull or NonZero*.

We should probably stop looking when encountering an enum, or else we'd have to figure out which variant would be picked by the all-0 bit pattern and then look at the fields of that.

RalfJung · 2019-08-03T13:25:12Z

@ishitatsuyuki beta branches in 12 days. If you want this to be backed out, someone has to do it before that.

ishitatsuyuki · 2019-08-05T12:20:32Z

Is the lint a requirement for backing out? If so, we may want to reach a consensus on how to implement the check.

RalfJung · 2019-08-05T13:31:17Z

Is the lint a requirement for backing out?

No, I don't think so. @joshtriplett could you clarify?

joshtriplett · 2019-08-06T21:17:05Z

Definitely not a requirement for backing out. More a requirement to happen well in advance of re-adding.

RalfJung · 2019-08-06T21:38:04Z

I'm working on a lint, should have a PR ready tomorrow.

RalfJung · 2019-08-07T08:16:25Z

Lint PR up at #63346

RalfJung · 2019-08-07T08:32:20Z

@joshtriplett what is the timeline you had in mind for putting the change back in place? uninit and init are two rather questionable intrinsics, so I'd like to get rid of them for good as soon as we can.

To my knowledge, the only crates that we know got broken by this are x11-rs (the broken part of which is "one giant hack" in the words of the maintainer) and old versions of crossbeam::queue (version 0.4 is reported to be broken; 0.5 has been released 9 months ago but I do not know if that one is fixed but crossbeam-queue 0.1 released 7 months ago and it is fixed).

Lint on some incorrect uses of mem::zeroed / mem::uninitialized Cc rust-lang#62825 and https://internals.rust-lang.org/t/make-mem-uninitialized-and-mem-zeroed-panic-for-some-types-where-0-is-a-niche/10605 This does not yet handle `NonNull`/`NonZero*`, but it is a start. I also improved some doc issues I hit on the way, and added a useful helper to `TyS`.

@RalfJung

Back out #62150 Ref: #62825 cc @RalfJung

Lint on some incorrect uses of mem::zeroed / mem::uninitialized Cc rust-lang#62825 and https://internals.rust-lang.org/t/make-mem-uninitialized-and-mem-zeroed-panic-for-some-types-where-0-is-a-niche/10605 This does not yet handle `NonNull`/`NonZero*`, but it is a start. I also improved some doc issues I hit on the way, and added a useful helper to `TyS`. EDIT: I added the relnotes label mostly as a proposal -- I think this is worth mentioning, but leave the decision up to the release team.

Centril · 2019-08-26T19:14:41Z

@joshtriplett what is the timeline you had in mind for putting the change back in place? uninit and init are two rather questionable intrinsics, so I'd like to get rid of them for good as soon as we can.

We discussed a one version grace period in this issue (see OP) and in the language team meeting. The lint has also been implemented (and then some...) so I think we should go ahead and revert the revert.

RalfJung · 2019-08-26T19:55:20Z

Okay. I personally would prefer to have a dynamic check in place as well on top of the static check that we have, just to be sure.

But either way I won't have time to work on this for this release cycle.

RalfJung · 2019-11-03T21:50:24Z

Status update: I filed #66059 to add some run-time protection on top of the static lint that we already have (a first version of that lint is stable for 5 weeks already; a stronger version will become stable in a week).

Once the run-time protection lands, my plan is to wait a week to see if there's a big outcry like there was when #62150 landed. If not, I'll submit a PR to re-implement #62150 and kill the init and uninit intrinsics.

@eddyb

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc #62825

@eddyb

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc #62825

@eddyb

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc #62825

@eddyb

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc #62825

@eddyb

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc rust-lang#62825 Also see [this summary comment](rust-lang#66059 (comment))

@eddyb

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc rust-lang#62825 Also see [this summary comment](rust-lang#66059 (comment))

RalfJung · 2020-03-11T13:35:15Z

Re-landing PR is up at #69922.

implement zeroed and uninitialized with MaybeUninit This is the second attempt of doing such a change (first PR: rust-lang#62150). The last change [got reverted](rust-lang#63343) because it [caused](rust-lang#62825) some [issues](rust-lang#52898 (comment)) in [code that incorrectly used these functions](AltF02/x11-rs#99). Since then, the [problematic code has been fixed](AltF02/x11-rs#101), and rustc [gained a lint](rust-lang#63346) that is able to detect many misuses of these functions statically and a [dynamic check that panics](rust-lang#66059) instead of causing UB for some incorrect uses. Fixes rust-lang#62825

RalfJung added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Jul 20, 2019

RalfJung changed the title ~~#62150 should be backed out~~ #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) should be backed out Jul 20, 2019

Centril removed the I-nominated label Jul 25, 2019

ishitatsuyuki mentioned this issue Aug 7, 2019

Back out #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) #63343

Merged

RalfJung mentioned this issue Aug 7, 2019

Lint on some incorrect uses of mem::zeroed / mem::uninitialized #63346

Merged

bors added a commit that referenced this issue Aug 11, 2019

Auto merge of #63343 - ishitatsuyuki:revert-62150, r=RalfJung

2b78e10

Back out #62150 Ref: #62825 cc @RalfJung

RalfJung mentioned this issue Aug 26, 2019

fix nounwind attribute logic #63909

Closed

RalfJung changed the title ~~#62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) should be backed out~~ re-land #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) Oct 31, 2019

RalfJung mentioned this issue Nov 3, 2019

mem::zeroed/uninit: panic on types that do not permit zero-initialization #66059

Merged

bors added a commit that referenced this issue Nov 5, 2019

Auto merge of #66059 - RalfJung:panic-on-non-zero, r=<try>

8045dc6

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc #62825

bors added a commit that referenced this issue Nov 9, 2019

Auto merge of #66059 - RalfJung:panic-on-non-zero, r=<try>

267085f

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc #62825

bors added a commit that referenced this issue Nov 15, 2019

Auto merge of #66059 - RalfJung:panic-on-non-zero, r=<try>

e72b4a3

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc #62825

bors added a commit that referenced this issue Dec 23, 2019

Auto merge of #66059 - RalfJung:panic-on-non-zero, r=<try>

7446ed3

mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc #62825

RalfJung mentioned this issue Feb 29, 2020

Creating a reference with std::mem::zeroed generates a SIGILL #52898

Closed

RalfJung mentioned this issue Mar 11, 2020

implement zeroed and uninitialized with MaybeUninit #69922

Merged

bors closed this as completed in 7a7ca82 Mar 17, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

re-land #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) #62825

re-land #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) #62825

ishitatsuyuki commented Jul 20, 2019 •

edited by RalfJung

Loading

RalfJung commented Jul 20, 2019 •

edited

Loading

RalfJung commented Jul 20, 2019 •

edited

Loading

joshtriplett commented Jul 25, 2019 •

edited

Loading

joshtriplett commented Jul 25, 2019

RalfJung commented Jul 25, 2019

joshtriplett commented Jul 26, 2019 via email

RalfJung commented Jul 26, 2019

RalfJung commented Aug 3, 2019

ishitatsuyuki commented Aug 5, 2019

RalfJung commented Aug 5, 2019

joshtriplett commented Aug 6, 2019

RalfJung commented Aug 6, 2019 •

edited

Loading

RalfJung commented Aug 7, 2019

RalfJung commented Aug 7, 2019

Centril commented Aug 26, 2019

RalfJung commented Aug 26, 2019

RalfJung commented Nov 3, 2019

RalfJung commented Mar 11, 2020

re-land #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) #62825

re-land #62150 (Implement mem::{zeroed,uninitialized} in terms of MaybeUninit) #62825

Comments

ishitatsuyuki commented Jul 20, 2019 • edited by RalfJung Loading

RalfJung commented Jul 20, 2019 • edited Loading

RalfJung commented Jul 20, 2019 • edited Loading

joshtriplett commented Jul 25, 2019 • edited Loading

joshtriplett commented Jul 25, 2019

RalfJung commented Jul 25, 2019

joshtriplett commented Jul 26, 2019 via email

RalfJung commented Jul 26, 2019

RalfJung commented Aug 3, 2019

ishitatsuyuki commented Aug 5, 2019

RalfJung commented Aug 5, 2019

joshtriplett commented Aug 6, 2019

RalfJung commented Aug 6, 2019 • edited Loading

RalfJung commented Aug 7, 2019

RalfJung commented Aug 7, 2019

Centril commented Aug 26, 2019

RalfJung commented Aug 26, 2019

RalfJung commented Nov 3, 2019

RalfJung commented Mar 11, 2020

ishitatsuyuki commented Jul 20, 2019 •

edited by RalfJung

Loading

RalfJung commented Jul 20, 2019 •

edited

Loading

RalfJung commented Jul 20, 2019 •

edited

Loading

joshtriplett commented Jul 25, 2019 •

edited

Loading

RalfJung commented Aug 6, 2019 •

edited

Loading