Refiling "#[repr(simd)] struct(isize, isize) not allowed"

[Centril]

Refiling rust-lang/rfcs#2513 here.

This probably does not require an RFC (according to me and @nrc).
However, we'd like @BurntSushi and @alexcrichton to sign off on this.

cc @rust-lang/compiler
cc @gnzlbg

Repro (playground: https://play.rust-lang.org/?gist=efa6e5caf752ccca651014ae5009feb8&version=nightly&mode=debug&edition=2015):

#![feature(repr_simd)] 

#[repr(simd)] struct A(isize, isize); // ERROR

#[cfg(target_pointer_width = "64")]
type isize_ = i64;

#[cfg(target_pointer_width = "32")]
type isize_ = i32;

#[repr(simd)] struct B(isize_, isize_); // Q: Is this ok?

produces

error[E0077]: SIMD vector element type should be machine type
 --> src/main.rs:3:15
  |
3 | #[repr(simd)] struct A(isize, isize);
  |               ^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

I am wondering why aren't isize and usize allowed ? I currently work around this to implement simd vectors of pointers, but maybe that's broken for reason I don't understand?

[Centril]

@rfcbot merge

[rfcbot]

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

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

Concerns:

• signoff-from-alex-and-andrew resolved by #55078 (comment)

Once a majority of reviewers approve (and none object), 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.

[Centril]

• signoff from @BurntSushi
• signoff from @alexcrichton

[Centril]

@rfcbot concern signoff-from-alex-and-andrew

[scottmcm]

This is just adding another type to a feature that isn't on the path to stabilization, right?

@rfcbot reviewed

[Centril]

@scottmcm yep :) (#27731 tracks repr(simd) in general)

[gnzlbg]

While #[repr(simd)] struct A(isize, isize); currently errors, #[repr(simd)] struct A<T>(T, T); type B = A<isize>; currently accidentally works on nightly.

The packed_simd crate has used this "bug" to export vectors of pointers and vectors of usize/isize/msize for a while and uses them in some of the examples (e.g. the examples/aobench tiled.rs algorithm).

Lifting the restriction makes something that's already possible and useful a bit easier to do. Also, the current plan is to never stabilize repr(simd), but to expose it through a std API. On stable, some of these are already exposed via std::arch (e.g. __m128), but none of them interact with isize/usize - so this does not interact with stable types at all.

Something like RFC2366 with support for packed SIMD vectors of pointers would need to be added to the language for this to land on stable.

[alexcrichton]

The #[repr(simd)] feature currently (and I can't forsee at least) have any path to stabilization. In that sense I would not personally recommend working on this feature as it's basically just a building block for std::arch, which we must expose to the language somehow.

I suspect, however, that fixing this is probably a few lines of a patch. While I wouldn't at all prioritize this I wouldn't stop it if someone were motivated.

[varkor]

I suspect, however, that fixing this is probably a few lines of a patch.

Namely, removing this line:

rust/src/librustc/ty/sty.rs

Line 1748 in 423d810

Int(ast::IntTy::Isize) | Uint(ast::UintTy::Usize) => false,

[Centril]

I'll interpret #55078 (comment) as "signoff" :)

@rfcbot resolve signoff-from-alex-and-andrew

[rfcbot]

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

[gnzlbg]

FWIW I actually had forgotten that I filled the RFC issue that resulted in this one being open.

I just wanted to know why did someone go through the trouble of preventing isize/usize in vector types. I couldn't find any reasons for this, the code has no comments, and we have been using them for a long time in packed_simd just fine. I just wanted to triple-check that we didn't miss anything.

I'd guess the answer is that no, we didn't miss anything.

Since this "bug" is easy to fix, maybe it should be E-Easy and mentoring available.

But I wasn't suggesting that we should fix this. It is trivial to work around (and fix), and it only impacts perma-unstable internal rustc APIs. Having an FCP about this feels extremely overkill.

[eddyb]

@gnzlbg It's possible the code used a categorization that dates back to when Rust had (or wanted to have?) bigints for int/uint and the types with numbers in them were "machine integers".

EDIT: nope, it was added in #6214, with no discussion in sight about int, uint and float.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[varkor]

Mentoring instructions:

1. Remove the line mentioned in #55078 (comment).
2. Add a test like the mentioned in the issue post: #55078 (comment).

[polybuildr]

Looks like this was fixed in PR #59201 and merged by bors. Should this issue be closed now?