Stop using unsized_const_parameters in core/std

[BoxyUwU]

feature(unsized_const_parameters) is an incomplete feature and should not be used by core/std as it makes it can make it significantly harder to evolve the feature. It also just generally opens the possibility of introducing bugs on stable through std's backdoor.

The only usage of this feature in std is the simd_shuffle_intrinsic added in #119213. It doesn't seem to be used anywhere as far as I can tell so it is removed in this PR. All tests and codegen logic etc have been kept however.

r? @workingjubilee

[rustbot]

Some changes occurred to the platform-builtins intrinsics. Make sure the
LLVM backend as well as portable-simd gets adapted for the changes.

cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Oh that's clever, basically using a (pre-existing!) macro to enable the feature just in a tiny scope. :D

However... will this actually suffice? if you remove the allow(incomplete_features), doesn't the warning trigger on that macro?

[BoxyUwU]

Actually it seems like the complete opposite thing is true, we can remove allow(incomplete_features) from core now with this PR lol. I was expecting there to be a pile of warnings I'd have to look through to see if the macro was triggering it but apparently not there is none (other than adt_const_params which is still marked incomplete in the beta compiler).

[RalfJung]

Isn't it a bug that you can bypass incomplete_features via allow_internal_unstable?

[workingjubilee]

is there supposed to be an intrinsics and core_intrinsics feature here?

[BoxyUwU]

intrinsics seems to be necessary to define the extern block for simd_shuffle_generic.

[workingjubilee]

huh.

[BoxyUwU]

@RalfJung yeah I don't think thats necessarily ideal, it would probably be good to lint on allow_internal_unstable that uses incomplete stuff atleast so that it's clear that something incomplete is being used.

[workingjubilee]

#[allow_internal_unstable]
#[really_allow_internal_unstable]
#[really_allow_internal_really_unstable]
#[really_allow_it_please_I_swear_boxy_I_wont_let_this_leak_into_user_code]

[workingjubilee]

huh.

[BoxyUwU]

this would be a lot more convenient if I knew how to run Miri tests locally lol

[ChrisDenton]

Have you tried x test miri?

[BoxyUwU]

Oh yeah that works thanks :-)

[RalfJung]

I filed an issue for the incomplete_features lint bypass you found: #128175.

IMO we shouldn't rely on this bypass, as that will make fixing it a lot harder.

[workingjubilee]

well, okay, but I am pretty sure the way to do that and make it work is to be very silly and place trait UnsizedConstParams under its own feature gate (as a library feature and not a compiler/lang feature).

[BoxyUwU]

It is not possible to have multiple unstable attributes on an item so I do not think there is really any good alternative here. We could try and special case stability checking but I tried that before and it seemed error prone. Alternatively we could only gate the trait under some third feature gate but then it would require three feature gates just for someone to write T: UnsizedConstParamTy and that feels really excessive to me.

The worst case here is that if somebody fixes the allow_internal_unstable thing they just add allow(incomplete_features) to the module to workaround this, and honestly that seems perfectly fine to me as a stop-gap. I don't think this will make it that much harder to fix. To me the value gained from being able to remove allow(incomplete_features) and feature(unsized_const_params) from core is significantly higher than someone having to potentially allow incomplete features in this one module one day.

I think I agree that ideally we wouldn't rely on this "hack", maybe instead we would have some kind of allow_internal_incomplete_feature(...) and lint on incomplete features in allow_internal_unstable though.

---

Given that I feel a degree of time pressure here (avoiding things landing using unsized const params) and that I don't think it will actually be all that difficult to handle this when fixing allow_internal_unstable (if that even happens) I would like to land this anyway. @RalfJung do you think this is reasonable? Hopefully I've understood your concerns adequately.

I've also left out removing allow(incomplete_features) from this PR since I think we ought to have a separate PR where we have proper team signoff on a policy of not using incomplete features, then we should explicitly deny the lint.

[RalfJung]

Allowing the lint on the macro is a reasonable work-around for when #128175 gets fixed.

[workingjubilee]

Okay, my understanding of the previous discussion is that we're continuing on here... it seems to me that regardless of what we might want to do in the future, this contains the possible problems back down from across std to this one spot. It's true someone might hypothetically reuse this pattern and it might hypothetically be approved in review, because they mistakenly assume any given thing should be immediately generalized in all places, but we have ripgrep and dev guides for solving that.

@bors r+ rollup

[bors]

📌 Commit 8174f9b has been approved by workingjubilee

It is now in the queue for this repository.