no_std support

[rnbguy]

Hey. Thanks for this crate :pray:

It'd be useful if we had a no_std feature for lazy-regex, as regex already supports via no-default-features. This should be doable just by refactoring the feature list.

Currently, lazy-regex, with no-default-features, doesn't compile as it doesn't pull regex as it is an optional dependency.

$ cd lazy-regex
$ cargo build --no-default-features
...
error[E0432]: unresolved import `regex`
   --> src/lib.rs:184:9
    |
184 |         self,
    |         ^^^^ no external crate `regex`
...

[Canop]

This looks like two different problems.

1. Can you please prepare an example of no-std lib or program which doesn't compile with lazy-regex due to this std dependency ?

2. I'm not sure there's a way to have regex and regex-lite be mutually exclusive and allow compilation with --no-default-features. But how is that a problem ?

[rnbguy]

I didn't take a look at your source code before. Regarding point 2, it is possible to go around it.

[target.'cfg(all(not(feature = "default"), not(feature = "lite")))'.dependencies]
regex = {version = "1.9", default_features = false}

But it's not recommended since crate/feature has landed, so I agree with you. Also, Rust-Doc has a section about mutually exclusive features.

About point 1, I don't have any easy/good examples[^1]. But the changes should be something similar to the following.

  [dependencies]
  ...
- regex = {version = "1.9", default_features = false, features = ["std"], optional = true}
+ regex = {version = "1.9", default_features = false, optional = true}

  [features]
  ...
+ no_std = ["regex"]

But again, usually, no_std feature is also not recommended. But with mutually exclusive features - I don't think you have another choice.

[^1]: I was trying to use lazy-regex in our ibc crate. I tried to use my fixes, but one of our dependencies locked on to an older version of regex than lazy-regex :man_facepalming:

[Canop]

To be honest the features = ["std"] part in my regex import seems to be a forgotten relic and I think it has exactly no impact due to the rest but I may be missing some subtleties of dependencies computations.

[rnbguy]

I think it has exactly no impact due to the rest

Exactly. That's why I turned it off - so that no_std doesn't pull regex/std. You already pull regex/default (which includes regex/std) by your default feature.

Only some of the regex/perf* and regex/unicode* features may require std. So either users need to provide std with their required features accordingly or you have to update your cargo-toml as follows,

  [features]
  ...
  std = ["regex/std"]
  ...
- perf = ["regex/perf"]
+ perf = ["std", "regex/perf"]

PS. I understand that regex-lite requires std and doesn't support no_std. So no need to touch it for no_std.