Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ensure BuildError impls std::error::Error #8

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

scottlamb
Copy link

Some usage in tracing expects this impl, as mentioned here: tokio-rs/tracing#3033 (review) It's provided when regex-automata has its std feature enabled. As matchers uses std itself, no reason not to allow regex-automata to do so also. Seems like the most straightforward way to address the problem:

  • avoids the need to create a wrapper type.
  • less fragile than bumping tracing-subscriber's regex dependency to 1.9.0 and hoping that all semver-compatible versions will continue depending on regex-automata with this std feature enabled.

Some usage in tracing expects this impl, as mentioned here:
<tokio-rs/tracing#3033 (review)>
It's provided when `regex-automata` has its `std` feature enabled.
As `matchers` uses `std` itself, no reason not to allow `regex-automata`
to do so also. Seems like the most straightforward way to address the
problem:

* avoids the need to create a wrapper type.
* less fragile than bumping `tracing-subscriber`'s `regex` dependency
  to 1.9.0 and hoping that all semver-compatible versions will continue
  depending on `regex-automata` with this `std` feature enabled.
@w4
Copy link

w4 commented Jan 8, 2025

@hawkw light bump on this, seems to be blocking moving tracing to matchers-0.2. thanks 🙏

@w4
Copy link

w4 commented Jan 8, 2025

@scottlamb to make this more digestible, it might be better to add a std = ["regex-automata/std"] feature instead?

@scottlamb
Copy link
Author

@scottlamb to make this more digestible, it might be better to add a std = ["regex-automata/std"] feature instead?

Why? Are you under the impression matchers was previously not using std or did so conditionally? Take a look at the very first non-comment line in the crate:

use std::{fmt, io, str::FromStr};

Making the crate no_std is not necessary to solve this problem, and I'm not interested in doing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants