Why does perf-literal requires std?

[Palkovsky]

Enabling perf-literal (and hence perf) indirectly enables std. This seems to be caused by two factors:

1. aho-corasick and memchr in the regex crate don't come with default-features = false
2. perf-literal-multistring in the regex-automata crate turns on std

First part should be fairly easy to fix. My question is - why does perf-literal-multistring depend on the std? Would it possible to keep the desired behavior without the std dependency?

[BurntSushi]

I created a PR for (1): #1148

For (2), that is an interesting question. The purpose of the perf-literal-* features is to enable the use of SIMD when searching. And for the aho-corasick crate, it needs to depend on std to enable SIMD. The reason is that CPU feature detection is only available in std, and that's needed to introspect (at least on x86-64) whether the necessary ISA extensions are available to employ SIMD. If std isn't enabled, then probably there isn't much point in enabling perf-literal-multistring.

But why doesn't perf-literal-substring also enable std? Well, in that case, the crate providing SIMD is memchr. And in that case, the algorithms are sufficiently simple enough that even when std isn't available, memchr can still fallback to SSE2, which is available is part of x86-64 and not an extension. So in that case, you don't need to depend on std to get SIMD.

But still, I think one could make the argument that features like perf-literal-multisubstring are generally orthogonal to whether a dependency on std should be introduced. Indeed, that feature does enable optimizations other than SIMD. So it seems perfectly cromulent to me that one might want to enable it without dependency on std.

I think the main issue here is that this is one giant cluster fuck and it's overall very difficult for end users to know which features to enable. Still, the problem is hardly confined to perf-literal-multisubstring.

So I think here is what I propose:

• Remove the std feature from perf-literal-multisubstring.
• Add a new section to the crate features docs prominently calling out that some of the SIMD optimizations require a dependency on std. And that most features, including perf-* features, will not also implicitly add a dependency on std. Instead, it is expected that users configuring the features for the crate will do that.

[Palkovsky]

Thank you for the explanation. The proposed solution solves the problem I'm having. Actually, I ended up doing the same thing on my fork.

[Palkovsky]

I created a PR for (2): #1150