Pest Parser Pest Versions Save

The Elegant Parser

v2.6.1

10 months ago

What's Changed

New Contributors

Full Changelog: https://github.com/pest-parser/pest/compare/v2.6.0...v2.6.1

Using pest as a git dependency

pest v2.6.1 contains a patch for the longstanding problem that pest couldn't be used as a git dependency due to the bootstrapping process. It should be possible now with a special feature flag as follows:

pest = { git = "https://github.com/.../pest.git", rev = "..." }
pest_derive = { git = "https://github.com/.../pest.git", rev = "...", features = ["not-bootstrap-in-src"]}

Note that the compilation time will be higher due to the cargo library dependency. If that becomes an issue, you can still use the old workarounds, e.g. cloning the repo, running cargo bootstrap there and specifying the dependency as a path to the locally cloned repo instead of git.

Warning: Semantic Versioning

Note that the node tag feature in 2.6.0 was a technically semver-breaking change even though it is a backwards-compatible / non-breaking change in the meta-grammar. There may be similar non-breaking changes to the meta-grammar between minor versions in the future. These non-breaking changes, however, may translate into semver-breaking changes due to the additional variants propagated from the generated Rule enum. This is a known issue and will be fixed in the future (e.g. by increasing MSRV and non_exhaustive annotations).

If you face a dependency problem where Cargo mixes different versions of pest due to transitive dependencies: https://github.com/pest-parser/pest/issues/849#issuecomment-1525505256 you can try adding the older pest to explicitly force it as follows:

pest = { version = "=2.5.6" }

v2.6.0

1 year ago

What's Changed

New Contributors

Full Changelog: https://github.com/pest-parser/pest/compare/v2.5.7...v2.6.0

Introducing node tags

pest v2.6.0's grammar includes a new (optional) feature for labelling parts of rules (based on this idea posted by @oovm : https://github.com/pest-parser/pest/discussions/550 ), e.g.:

add = {#lhs = expr ~ "+" ~ #rhs = epxr}

This feature can help to distinguish tokens by labels instead of positions (which can help to reduce boilerplate code). You can read more about it here: https://pest.rs/book/grammars/syntax.html#tags

Warning: Semantic Versioning

Note that the node tag feature in 2.6.0 is a technically semver-breaking change even though it is a backwards-compatible / non-breaking change in the meta-grammar. There may be similar non-breaking changes to the meta-grammar between minor versions in the future. These non-breaking changes, however, may translate into semver-breaking changes due to the additional variants propagated from the generated Rule enum. This is a known issue and will be fixed in the future (e.g. by increasing MSRV and non_exhaustive annotations).

v2.5.7

1 year ago

What's Changed

New Contributors

Full Changelog: https://github.com/pest-parser/pest/compare/v2.5.6...v2.5.7

v2.5.6

1 year ago

What's Changed

Full Changelog: https://github.com/pest-parser/pest/compare/v2.5.5...v2.5.6

pest_fmt and Visual Studio Code extension

Thanks to the great work of @huacnlee , @Jamalam360 and others, the new version of pest_fmt was published and the Visual Studio Code extension for pest was released on the Marketplace: https://marketplace.visualstudio.com/items?itemName=pest.pest-ide-tools

v2.5.5

1 year ago

What's Changed

New Contributors

Full Changelog: https://github.com/pest-parser/pest/compare/v2.5.4...v2.5.5

Warning: Semantic Versioning

The "fast-col-line" feature was removed, because it's superseded by the line_col method on Pairs (which has a better or similar performance): https://github.com/pest-parser/pest/pull/785#issuecomment-1413604569

Note that the rustdoc support in 2.5.4: https://github.com/pest-parser/pest/pull/765 was a semver-breaking change even though it was a backwards-compatible / non-breaking change in the meta-grammar. There may be similar non-breaking changes to the meta-grammar between minor versions in the future. These non-breaking changes, however, may translate into semver-breaking changes due to the additional variants propagated from the generated Rule enum. This is a known issue and will be fixed in the future (e.g. by increasing MSRV and non_exhaustive annotations).

v2.5.4

1 year ago

What's Changed

Full Changelog: https://github.com/pest-parser/pest/compare/v2.5.3...v2.5.4

v2.5.3

1 year ago

What's Changed

New Contributors

Full Changelog: https://github.com/pest-parser/pest/compare/v2.5.2...v2.5.3

v2.5.2

1 year ago

What's Changed

New Contributors

Full Changelog: https://github.com/pest-parser/pest/compare/v2.5.1...v2.5.2

Happy Holidays and Best Wishes for 2023! ☃️🎄 🎆

v2.5.1

1 year ago

What's Changed

New Contributors

Full Changelog: https://github.com/pest-parser/pest/compare/v2.5.0...v2.5.1

v2.5.0

1 year ago

What's Changed

New Contributors

Full Changelog: https://github.com/pest-parser/pest/compare/v2.4.1...v2.5.0

Accidental breakage of semantic versioning since v2.2.0 in pest_meta

We found out that, in addition to a breaking change in pest that was reverted, there were a few breaking changes in pest_meta in v2.2.0:

  • pest_meta::validator::validate_undefined now takes 2 parameters instead of 3,
  • pest_meta::validator::validate_pest_keywords now takes 1 parameter instead of 2,
  • and pest_meta::validator::validate_rust_keywords now takes 1 parameter instead of 2.

Given pest_meta is primarily used within pest's own crates[^1] and no one opened an issue regarding these breaking changes, we decided not to revert the post-2.2.0 releases and keep those functions as they are now in 2.5.0[^2].

Having said that, we now have a CI action to check for semantic versioning, so we should be able to avoid accidental breaking changes in the future.

[^1]: Those three pest_meta functions are rather internal and perhaps did not need to be made public early on.

[^2]: If these accidental pest_meta breaking changes cause any trouble in your code, please feel free to open an issue though!

Introducing a new grammar debugger CLI and crate (pest_debugger)

While pest's focus is on accessibility, developers can sometimes struggle to understand what is going under the hood and why a particular input is parsed in a particular way (or fails to parse). A long time ago, @dragostis implemented a simple CLI debugger that could help in this aspect, but this effort was not finished. This implementation was revived and you are now welcome to use it. You should be able to install it using:

cargo install pest_debugger

You can then run the interactive debugger by calling pest_debugger and view its help by typing h in its prompt:

> h

Use the following commands:
g <grammar filename>          - load .pest grammar
i <input filename>            - load input from a file
id <input text>               - load input directly from a single-line input
ba                            - add breakpoints at all rules
b <rule>                      - add a breakpoint at a rule
d <rule>                      - delete a breakpoint at a rule
da                            - delete all breakpoints
r <rule>                      - run a rule
c                             - continue
l                             - list breakpoints
h                             - help

The commands are self-explanatory; for a quick reference, the basic usage is:

> g ...file path to your grammar...
> i ...file path to your input...
> b ...name of the rule you want to stop at...
> r ...the rule to start running at...

:bulb: There is a tab completion for file paths and command history.

And then, once the debugger hits a breakpoint, you can continue the execution by typing:

> c

:bulb: You can also start up the debugger with command-line arguments that will do those steps during initialisation:

Usage: pest_debugger [options]

Options:
-g, --grammar <grammar file>    - load .pest grammar
-i, --input <input file>        - load input file
-r, --rule <rule>               - run rule
-b, --breakpoint <rule>         - breakpoint at rule
-s, --session <session file>    - load session history file
-h, --help                      - print this help menu

Looking for a side project?

If you are using pest in your projects and would like to contribute to its development by organising its issues, reviewing its pull requests etc., please feel free to comment on this post to join the triage team!

In addition to that, here are also a few potential ideas for work that can help anyone who would like to get familiar with pest's implementation:

Does any of these ideas sound interesting to you and would like to work on them? Or do you have other pest-related ideas you are working on or would like to explore? Please don't hesitate to share them in the comments below the announcement!