pest: pest_generator 2.5.6 does not compile

Describe the bug

We depend on json5 in our project which, in turn, depends on pest. A fresh cargo build, i.e. after a cargo clean, fails because of a non-exhaustive pattern on pest_meta::optimizer::OptimizedExpr::NodeTag(_, _).

To Reproduce

  1. cd /tmp && git clone https://github.com/eclipse-zenoh/zenoh-flow.git --depth 1
  2. cd zenoh-flow && cargo build

Expected behavior

We would expect pest_generator to compile.

Additional context

The json5 crate includes pest as following:

pest = "2.0"

The full error is as following:

error[E0004]: non-exhaustive patterns: `pest_meta::optimizer::OptimizedExpr::NodeTag(_, _)` not covered
   --> /Users/julien/.cargo/registry/src/github.com-1ecc6299db9ec823/pest_generator-2.5.6/src/generator.rs:378:11
    |
378 |     match expr {
    |           ^^^^ pattern `pest_meta::optimizer::OptimizedExpr::NodeTag(_, _)` not covered
    |
note: `pest_meta::optimizer::OptimizedExpr` defined here
   --> /Users/julien/.cargo/registry/src/github.com-1ecc6299db9ec823/pest_meta-2.6.0/src/optimizer/mod.rs:142:5
    |
114 | pub enum OptimizedExpr {
    | ----------------------
...
142 |     NodeTag(Box<OptimizedExpr>, String),
    |     ^^^^^^^ not covered
    = note: the matched value is of type `pest_meta::optimizer::OptimizedExpr`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
519 ~         }
520 +         pest_meta::optimizer::OptimizedExpr::NodeTag(_, _) => todo!()
    |

error[E0004]: non-exhaustive patterns: `pest_meta::optimizer::OptimizedExpr::NodeTag(_, _)` not covered
   --> /Users/julien/.cargo/registry/src/github.com-1ecc6299db9ec823/pest_generator-2.5.6/src/generator.rs:524:11
    |
524 |     match expr {
    |           ^^^^ pattern `pest_meta::optimizer::OptimizedExpr::NodeTag(_, _)` not covered
    |
note: `pest_meta::optimizer::OptimizedExpr` defined here
   --> /Users/julien/.cargo/registry/src/github.com-1ecc6299db9ec823/pest_meta-2.6.0/src/optimizer/mod.rs:142:5
    |
114 | pub enum OptimizedExpr {
    | ----------------------
...
142 |     NodeTag(Box<OptimizedExpr>, String),
    |     ^^^^^^^ not covered
    = note: the matched value is of type `pest_meta::optimizer::OptimizedExpr`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
651 ~         }
652 +         pest_meta::optimizer::OptimizedExpr::NodeTag(_, _) => todo!()
    |

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 17 (8 by maintainers)

Commits related to this issue

Most upvoted comments

@turboMaCk can you try adding pest = { version = "=2.5.6" } (or potentially tweaking other crates, such as pest_meta and pest_generator, that may be mismatched to 2.6.0) to your dependencies to pin the version? Releasing a new version may need a bit of work, because reverting the new grammar feature isn’t ideal… we can perhaps find a middle ground with some feature-guarding. One more alternative may be to yank 2.6.0 and publish it as 2.6.0-something (I think Cargo won’t be resolving to versions with dashes / “pre-releases”, so it’ll stay at the latest one without dashes). But yanking is a bit disruptive as well.

Sorry @tomtau I got distracted. I can confirm that 2.7.0 works for my project also. Thanks for the fix.

Thanks @tomtau I can confirm this works as expected in my project.

@jlyonsmith @turboMaCk @J-Loudet @liukun4515 2.7.0 was published and it seems to work ok when mixed with the pest_generator 2.5.6 under default features, so I yanked 2.6.X crates. You can try if it works for you now when you remove pest = { version = "=2.5.6" } and perhaps cargo update?

Hi @liukun4515, we put a warning in the release notes: https://github.com/pest-parser/pest/releases/tag/v2.6.0 There was a similar semver-breaking change in 2.5 and noone reported any issue, so we assumed it may be ok, but if this causes a lot of trouble to people (and tweaking internal dependencies does not work), we can try to discuss and see what to do… anyway, ultimately, we’ll want to at least have one more semver violation to bump MSRV and put non_exhaustive annotations on those internal structures, so that there are no more semver violations from non-breaking grammar changes.

@tomtau thanks for the pointers, this seems indeed the way to go! 👍

I am closing this issue as it is not directly related to pest.