Change:
<del> Subproject commit dea57529b3695605909e7d327bb6551d7a10c788 </del> <ins> Subproject commit abe96ca3b87fcca6aa1dfcefd40d8c8d92d2e673 </ins>

Discussion:
The following program builds and runs on stable but fails to build on nightly: Here's the build error on : But note that if I replace with , the error goes away. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Here's the output of : searched nightlies: from nightly-2020-01-02 to nightly-2020-02-10 regressed nightly: nightly-2020-02-06 searched commits: from to regressed commit: That points to , which is a large merge of stdarch. When I bisect stdarch, I find the error was introduced in , possibly intentionally. Is it the case that AVX-512 feature detection was never intended to be stabilized? Or maybe it got caught up in a larger group of unstable features? Prior to this regression, it did in fact work :)
A quick search through turns up at least one other crate besides BLAKE3 that fails to build on nightly for this reason: git clone cd scavenger cargo check --features=simd # succeeds cargo +nightly check --features=simd # fails
this might be a hi-pri regression. (Though of course I'm biased cause it affects my crate.) If isn't available to evaluate it, could we pull in someone else?
cc To be honest I'm not even entirely sure where this macro is implemented...
Caused by , which started enforcing stability on individual features.
It looks like a crater run was done in September, but the and crates were published in January. The crate relies on std to detect AVX-512 support, but the actual AVX-512 implementation code is in C or assembly. Also the crate I mentioned above hides its use of AVX-512 detection behind its feature, so I don't think crater would've caught it.
Seems like there was no discussion done of whether this would break folks (or at least I can't find it). Clearly this is "permitted" under a strict interpretation of our stability rules, though is not documented on the macro at all; list avx512f with no warning that it is unstable. That at least sounds like a bug. I guess someone (libs team?)

needs to make a call on whether this is a bug, and whether we should fix it.
Considering that this broke two crates on stable, I think we should just go ahead and stabilize the avx512 features. I don't think there is any particular reason for holding back on them.
(nominating to try to ensure T-libs resolves this in some manner before this hits stable.)
Even if we don't want to stabilize the intrinsics themselves for whatever reason, it seems fine to allow detection of avx512 support via the macro.
Could someone on T-libs fcp a stabilization for the following x86 features, which have been destabilized in nightly: mmx sse4a avx512f avx512cd avx512er avx512pf avx512bw avx512dq avx512vl avx512ifma avx512vbmi avx512vpopcntdq tbm Once we get the ball rolling on that, I can work on trying to fix whatever the root cause of this destabilization is.
(Or, if we don't want to stabilize all of them, and want to say "oh well breaking change", then that would be helpful too).
Also see : there was an approved FCP to stabilize adx, tbm and sse4a but it got closed because the PR author was inactive.
According to , it seems that a lot of AVX512 intrinsics are missing from . As such I don't think it really makes sense to stabilize the AVX512 feature. I think the best approach would be to stabilize avx512 only for , since it was already (accidentally) stable and code is relying on it. Any thoughts I will write up a PR for stdarch if there are no objections.
It seems to me that stabilizing just as a parameter to should be fine? As in, I don't think there's any hazard of us never stabilizing it. I'd be more skeptical of blanket stabilizing a bunch of parameters to though. For example, we might want to never stabilize anything to do with . Definitely agree here.
To be clear, stable today has the list in stabilized, which includes mmx -- we can technically say "woops" I guess and revert that to being unstable, but that seems not great. (Though if there are good reasons to do so, then perhaps we should.)
There are good reasons to forbid MMX.

It's the only instruction from the list above which can cause misoptimization (breaking otherwise sound code). It's removal is discussed in
Is it important to get fixes in before the next beta is tagged in a couple weeks?
It would be good, but I think it's not critical. We can always backport.
I've opened as a first stab at an upstream fix. That one only re-stabilizes the AVX-512 features (that were stable before), leaving , , and as they are. It sounds like we specifically don't want to include , though I'm not sure what to do with the other two.
Upstream topic about and :
We discussed this in the language team meeting. We agreed that we should stabilize processor feature detection even if we don't have intrinsics for a given feature. So, in particular, we should re-stabilize support in for any feature we know how to detect, even those we don't have stable intrinsics for. (That includes , even though it doesn't sound like anyone is likely to care about it.) poll lang Re-stabilize isx86featuredetected for any processor feature we know how to detect?
Team member has asked teams: T-lang, for consensus on: [x] [x] [x] [x] [ ] [x] [x] [ ]
The following workaround can be used to detect AVX512F and AVX512VL (which is what BLAKE3 uses) without depending on any unstable features: Considering that these features were accidentally stabilized and that only 2 crates are depending on them I would propose that: We do not stabilize the avx512 detection flags. BLAKE3 and scavenger switch to using the above detection function.
We have no concrete evidence it's just two crates though, right? I myself was pretty convinced by argument in the lang team meeting that there's not really any reason to not stabilize detection for anything that we can reliably detect; the intrinsics themselves are a different story. IIRC, one key benefit of the macro is that it globally caches the results, whereas your function would need additional work to do so, I think?
(Not that this changes my view per the poll above, but I think we should not consider "absence of evidence is not evidence of absence" as a good argument.

I think we should assume, for practical purposes, that there are no regressed crates until there's positive empirical evidence for something.)
I would avoid any kind of handcrafted cpudetection code scattered around. (I have a patch pending in rav1e waiting for the avx512 cpu detection support to stabilize and probably other projects are in a similar situation)
Here's another affected crate: I've reconsidered my position: since is already stable for all feature flags (stable or unstable), I don't think it makes sense to block the same flag names for runtime feature detection.
To me, the phrase "We should assume there are no regressed crates  (But maybe I'm just someone who does think that the "absence of evidence" maxim is worth raising from time to time.)
triage: After spending a while explaining this bug to , I figured I should take the plunge and mark this as P-high. (I'm not 100% sure if it is a release blocker per se, but my interpretation of the is that we would prefer to either land a fix for this before beta is cut or, failing that, prioritize a backport to the beta branch, so that the bug itself never hits stable.)
OK, let's try to make some progress on this. I'd like to propose stabilizing the following features for feature detection only: mmx sse4a tbm avx512f avx512cd avx512er avx512pf avx512bw avx512dq avx512vl The SSE4a and TBM features were already scheduled to be stabilized in , but the PR got abandoned. Only a subset of the AVX512 features are listed here because there is some uncertainty with the newer ones as to whether they should contain an underscore: vs . Finally MMX, while not supported by LLVM, is a well known feature name. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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 for info about what commands tagged team members can give me.
is now up to speed with proposal above.
:bell: This is now entering its final comment period, as per the . :bell:
As of the 1.42 release today, is failing. This fix will need to be backported.
assign
PR to update the submodule is here: It will need to be backported to beta.