Implement core::fmt::Display for ParseError - #477
Merged
Conversation
Peternator7
changed the title
philippemnoel
added a commit
to paradedb/paradedb
that referenced
this pull request
Aug 4, 2026
# Ticket(s) Closed - Closes # ## What Bumps `strum` and `strum_macros` from `0.27.2` to `0.28.0` in `pg_search`, `tests` and `tokenizers`. No source changes were needed. Fifth of the major-version dependency upgrades, done one at a time (after #5843 sysinfo, #5844 syn, #5849 rstest, #5853 proptest-derive). ## Why Broadest remaining upgrade — it's the only one touching three crates. ## How ### The documented breaking changes don't apply `0.28.0`'s one behavioral break is that **`EnumString` now implements `From<&str>` instead of `TryFrom<&str>`** for enums with a `#[strum(default)]` variant ([#476](Peternator7/strum#476)). Nothing here derives `EnumString`, and there are zero uses of `#[strum(default)]` or `EnumDiscriminants`. The `strum::ParseError` → `core::fmt::Display` change ([#477](Peternator7/strum#477)) is also unused — the `ParseError` matches in this workspace are `std::net::AddrParseError` and tantivy's `QueryParserError`, not strum's. MSRV moves to 1.71, well under our pinned 1.97.1. The derive surface actually in use is narrow: `VariantNames` (3), `AsRefStr` (3), `EnumIter` (2), `Display` (2), `IntoEnumIterator` (1), with only `serialize_all = "snake_case"` and two `serialize = "..."` overrides. ### What actually needed checking: the derived strings are public API `SearchTokenizer` derives `VariantNames` + `AsRefStr` under `serialize_all = "snake_case"`, and `SearchTokenizer::VARIANTS` is returned **directly by the `paradedb.tokenizers()` SQL function**: ```rust pub fn tokenizers() -> TableIterator<'static, (name!(tokenizer, String),)> { TableIterator::new(SearchTokenizer::VARIANTS.iter().map(|t| (t.to_string(),)).collect::<Vec<_>>()) } ``` So a change in how strum renders variants like `ICUTokenizer`, `EdgeNgram`, `WhiteSpace` or `ChineseLinderaDeprecated` would be a **user-visible break**, silently changing accepted tokenizer names. A replica of both derived enums — same attributes, same 23 variants, in their real tuple/struct/unit shapes — was compiled under 0.27.2 and 0.28.0. Identical output: ``` VARIANTS = ["default", "keyword", "keyword_deprecated", "raw", "literal_normalized", "white_space", "regex_tokenizer", "chinese_compatible", "source_code", "ngram", "edge_ngram", "chinese_lindera_deprecated", "chinese_lindera", "japanese_lindera_deprecated", "japanese_lindera", "korean_lindera_deprecated", "korean_lindera", "icu", "jieba", "lindera_deprecated", "lindera", "unicode_words_deprecated", "unicode_words"] ``` `as_ref()` for every variant shape (including both `serialize = "..."` overrides), `LinderaLanguage::VARIANTS`, and `EnumIter` ordering all matched too. ##⚠️ This temporarily duplicates strum in the graph `lindera 1.5.1` pins `strum = "^0.27.2"`, so its subtree keeps 0.27.2 while our crates move to 0.28.0: ``` strum v0.28.0 strum v0.27.2 ├── pg_search ├── lindera v1.5.1 └── tokenizers └── lindera-dictionary v1.5.1 ``` Cost is one extra `strum` + `strum_macros` compile. No `phf` pull-in, since that feature stays off. **This resolves itself with the lindera upgrade** — `lindera 4.0.1` requires `strum 0.28.0`, so landing that collapses the duplicate. The two upgrades are complementary; if you'd rather not carry the duplication at all, this one could wait until after lindera. ## Tests All three crates reach lindera, whose build script downloads dictionaries from `lindera.dev` — a host blocked by egress policy in my environment — so none can be compiled locally. The matrix jobs on this PR are what compile them. - equivalence harness above — identical derived names under 0.27.2 and 0.28.0 - `cargo fmt --all -- --check` — clean ## Remaining | crate | current → latest | note | |---|---|---| | `lindera` | 1.5.1 → 4.0.1 | also collapses the strum duplication above; but 4.0 dropped the `compress` feature, so embedded dictionaries become raw `include_bytes!` — a `.so` size vs. startup trade-off worth measuring, plus segmentation output needs checking | | `bincode` | 2.0.1 → 3.0.0 | touches an on-disk encoding | | `cmd_lib` | 1.9.6 → 2.0.0 | | | `emojis` | 0.8.2 → 0.9.0 | | --- _Generated by [Claude Code](https://claude.ai/code/session_01XEm6G1qKw694BQQqb9HBiU)_
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
strum::ParseErrorcan implementcore::fmt::Display.core::error::Errorwasn't added to core until1.81Fixes #453