Skip to content

Semver compatibility failure #985

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

Closed
hashedone opened this issue Apr 21, 2023 · 1 comment
Closed

Semver compatibility failure #985

hashedone opened this issue Apr 21, 2023 · 1 comment

Comments

@hashedone
Copy link

What version of regex are you using?

1.8.1, tried 1.8.0 as well

Describe the bug at a high level.

The 1.8.0 is semver incompatible with 1.7.0.

The tracing-subscriber crate is depending on regex (when env-filter is enabled) to parse the env config string. It is depending on the ^1 version, so it picks 1.8.1 right now. Any trail of creating EnvFilter ends in a panic due to an error in some regex parsing.

What are the steps to reproduce the behavior?

The minimal example (this output is literally from this one): https://github.com/hashedone/regex-incompat-failure

This behaves the same when I fix the regex version to 1.8.0 with cargo update -p regex --precise 1.8.0, but is "fixed" when I go to 1.7.3: `cargo update -p regex --precise 1.7.3"

What is the actual behavior?

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Syntax(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
regex parse error:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1: (?x)
 2:             ^(?P<global_level>(?i:trace|debug|info|warn|error|off|[0-5]))$ |
                                      ^
 3:                 #                 ^^^.
 4:                 #                     `note: we match log level names case-insensitively
 5:             ^
 6:             (?: # target name or span name
 7:                 (?P<target>[\w:-]+)|(?P<span>\[[^\]]*\])
 8:             ){1,2}
 9:             (?: # level or nothing
10:                 =(?P<level>(?i:trace|debug|info|warn|error|off|[0-5]))?
11:                     #          ^^^.
12:                     #              `note: we match log level names case-insensitively
13:             )?
14:             $
15:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: Unicode-aware case insensitivity matching is not available (make sure the unicode-case feature is enabled)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
)', /home/hashed/.cargo/registry/src/gb.xjqchip.workers.dev-1ecc6299db9ec823/tracing-subscriber-0.3.16/src/filter/env/directive.rs:140:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

What is the expected behavior?

No panic should occur. Some functionality got changed, causing regex to be previously accepted and now be refused, which seems like a breaking change.

@BurntSushi
Copy link
Member

Duplicate of #982

This isn't a semver issue but a result of tracing-subscriber under specifying their dependency on regex. It "happened" to work in regex 1.7 because of Cargo feature unification.

See my comment here: #982 (comment)

@BurntSushi BurntSushi closed this as not planned Won't fix, can't repro, duplicate, stale Apr 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants