Regex is failing in nightly

1

I don't generally work with nightly, but I do have travis compiling and checking my code against that. Has anyone noice that?

Compiling regex v0.1.43
Running rustc /home/travis/.cargo/registry/src/github.com-88ac128001ac3a9a/regex-0.1.43/src/lib.rs --crate-name regex --crate-type lib -C codegen-units=1 -g -C metadata=ca23fbfc498b741a -C extra-filename=-ca23fbfc498b741a --out-dir /home/travis/build/bluejekyll/trust-dns/target/debug/deps --emit=dep-info,link -L dependency=/home/travis/build/bluejekyll/trust-dns/target/debug/deps -L dependency=/home/travis/build/bluejekyll/trust-dns/target/debug/deps --extern regex_syntax=/home/travis/build/bluejekyll/trust-dns/target/debug/deps/libregex_syntax-695a6c2a2c33e892.rlib --extern aho_corasick=/home/travis/build/bluejekyll/trust-dns/target/debug/deps/libaho_corasick-32050201217e44e8.rlib --extern memchr=/home/travis/build/bluejekyll/trust-dns/target/debug/deps/libmemchr-940d9877eaa7970c.rlib --cap-lints allow
/home/travis/.cargo/registry/src/github.com-88ac128001ac3a9a/regex-0.1.43/src/prefix.rs:46:12: 46:24 error: private type in public interface [E0446]
/home/travis/.cargo/registry/src/github.com-88ac128001ac3a9a/regex-0.1.43/src/prefix.rs:46 Single(SingleSearch),
^~~~~~~~~~~~
/home/travis/.cargo/registry/src/github.com-88ac128001ac3a9a/regex-0.1.43/src/prefix.rs:46:12: 46:24 help: run rustc --explain E0446 to see a detailed explanation
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
Could not compile regex.
Caused by:
Process didn't exit successfully: rustc /home/travis/.cargo/registry/src/github.com-88ac128001ac3a9a/regex-0.1.43/src/lib.rs --crate-name regex --crate-type lib -C codegen-units=1 -g -C metadata=ca23fbfc498b741a -C extra-filename=-ca23fbfc498b741a --out-dir /home/travis/build/bluejekyll/trust-dns/target/debug/deps --emit=dep-info,link -L dependency=/home/travis/build/bluejekyll/trust-dns/target/debug/deps -L dependency=/home/travis/build/bluejekyll/trust-dns/target/debug/deps --extern regex_syntax=/home/travis/build/bluejekyll/trust-dns/target/debug/deps/libregex_syntax-695a6c2a2c33e892.rlib --extern aho_corasick=/home/travis/build/bluejekyll/trust-dns/target/debug/deps/libaho_corasick-32050201217e44e8.rlib --extern memchr=/home/travis/build/bluejekyll/trust-dns/target/debug/deps/libmemchr-940d9877eaa7970c.rlib --cap-lints allow (exit code: 101)

2

You're building 0.1.43, but https://crates.io/crates/regex says the latest is 0.1.53. Maybe update?

1 Like
3

It's not a direct dependency for me, hasn't needed to be touched in a while. I'll update my Cargo.lock file. Looks like it's probably being pulled in from docopt. Funny, I just got so used to things always working and never needing upgrades.

Do you have any recommendations on upgrading dependencies? I generally don't do it unless there's something I need, but obviously things like this will break as new changes are coming down the pipe from Rust nightly.

4

I think what happened here was a combination of two things:

  1. regex was exposing something in its private API by accident. (This probably sounds strange, but it needs to expose part of its internals for the regex! compiler plugin.)
  2. There was a bug in Rust that was actually letting that happen. The bug was fixed, which breaks any code that had been relying on that bug. (To be clear, regex wasn't relying on it, it was an oversight.)

A cargo update will do the trick. If you have your versions specified in Cargo.toml, then cargo update shouldn't bring in any semver-incompatible updates. Of course, this relies on all your transitive dependencies actually adhering to semver, but I can at least vouch for docopt and regex. :slight_smile:

1 Like
5

Which are both great projects btw.

What I was getting at more is recommendations on when to run cargo update... b/c I know I'm not doing it regularly now, was seeing if others follow some rule. Like always updating before pushing to a remote branch, always updating before publishing a new version, etc.

I'm curious about other people's guidelines on that...

7

It depends on your project and its goals. On projects I've worked on, there's been a few different philosophies:

  1. Whenever someone feels like doing it.
  2. As part of a general "cleanup, refactor, bugfix" sprint rather than a "new features" sprint
  3. When you need a bugfix that's in a version newer than the version you're in.
8

btw, cargo update did fix this.

1 Like