It may be best to yank version 1.5.0
mulkieran opened this issue · 4 comments
What version of regex are you using?
We have a test system that forces the version back to the lowest compatible with our dependency specification. That was, briefly, 1.5.0.
Describe the bug at a high level.
regex seems not to compile with this error:
error[E0433]: failed to resolve: use of undeclared crate or module `syntax`
--> /home/.../.cargo/registry/src/github.com-1ecc6299db9ec823/regex-1.5.0/src/literal/mod.rs:9:9
|
9 | use syntax::hir::literal::Literals;
| ^^^^^^ use of undeclared crate or module `syntax`
What are the steps to reproduce the behavior?
Was briefly compiling HEAD of project stratisd w/ regex version spec set to "1.5.0".
Also, ran command:
cargo update --package=regex@1.7.0 --precise 1.5.0 to set actual version in Cargo.lock to 1.5.0.
Saw above error, which will also be visible at this URL: https://github.com/stratis-storage/stratisd/actions/runs/3567286163/jobs/5994792307 (scroll to bottom).
What is the actual behavior?
regex fails to compile w/ the error shown above.
What is the expected behavior?
regex compiles.
regex 1.5.0 compiles just fine for me:
$ cat Cargo.toml
[package]
name = "regex931"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
regex = "=1.5.0"
[[bin]]
name = "regex931"
path = "main.rs"
[andrew@frink regex931]$ cat main.rs
fn main() {
println!("{:?}", regex::Regex::new(r"\w").unwrap());
}
$ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Running `target/debug/regex931`
\w
Ah okay, looking at the compilation error, it looks you're trying to build regex without the perf-literal feature, which is a critical part of the reproduction here. (In the future, it would be super helpful to minimize bug reports so that someone else can run the same commands you provide with the same inputs and get the same result.)
So I can reproduce your problem by using this in my Cargo.toml:
regex = { version = "=1.5.0", default-features = false, features = ["std"] }
And then:
$ cargo run
Compiling regex-syntax v0.6.28
Compiling regex v1.5.0
error[E0433]: failed to resolve: use of undeclared crate or module `syntax`
--> /home/andrew/.cargo/registry/src/github.com-1ecc6299db9ec823/regex-1.5.0/src/literal/mod.rs:9:9
|
9 | use syntax::hir::literal::Literals;
| ^^^^^^ use of undeclared crate or module `syntax`
For more information about this error, try `rustc --explain E0433`.
error: could not compile `regex` due to previous error
warning: build failed, waiting for other jobs to finish...
This was fixed in the 1.5.1 release on the same day: 0c6dfbc
It may be best to yank version 1.5.0
The regex crate doesn't have a yank policy. (I can't recall when, or even if, I have ever yanked a regex release.) In general, I only reserve yanking as a tool of last resort. A compilation error when a default feature is disabled doesn't strike me as a good enough reason. If you wind up trying to build regex 1.5.0 under such a configuration and get an error, then the right thing to do there is to upgrade (in your case, upgrade your minimal dependency specification). Yanking doesn't change that. Even if it were yanked, you should still upgrade your dependency specification.
To me, yanking is useful when you wouldn't otherwise notice something was wrong but really really really should upgrade.
Of course, I'm happy to be pragmatic about such things. If yanking is a solution to a problem that is wreaking havoc, I'm happy to entertain it then too, whatever the reason may be. But I don't think this issue fits that criteria either.
That's unfortunate. The bindgen 0.69.1 (latest as of writing) crate sets 1.5.0 as its minimum version for the regex crate, and compiles with default-features = false causing this error to show up on a test with -Zminimal-versions. I guess they should use at least 1.5.1, but would yanking in theory cause that process to never select 1.5.0?
A yanked crate is only used when it's in a lock file. But if a yanked crate is not in a lock file, then Cargo should never put it in a lock file. At least, that is my understanding of how yanking works. Whether it applies to your bindgen example depends on whether regex 1.5.0 is in a lock file or not. It isn't clear whether it is or not.
bindgen should set a higher minimal version if it doesn't build with 1.5.0. That's the right fix here.
rust-lang/rust-bindgen#2714 fix is here.
The bindgen repository uses a Cargo.lock file, but it is of course of no use when the bindgen crate is used as a dependency of some other crate.
EDIT: As of writing they're locked to regex 1.7.1: