feat: support go 1.24 ignore directives#35
Conversation
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
| fn ignore_multi(input: &mut &str) -> Result<Vec<String>> { | ||
| let _ = ("(", multispace1).parse_next(input)?; | ||
| let res: Vec<Vec<String>> = | ||
| repeat(1.., terminated(ignore_single, multispace0)).parse_next(input)?; | ||
| let _ = (")", multispace0).parse_next(input)?; |
There was a problem hiding this comment.
ignore_multi duplicates the ( ... ) block parsing shared by require_multi, replace_multi, etc. — should we extract a helper? Also, ignore_single calls take_till before opt(comment), so whole-line // comments inside ignore (...) get parsed as bogus path entries; should we detect and consume comment lines first, like the Go module parser does?
Finding types: Code Dedup and Conventions Logical Bugs | Severity: 🟠 Medium
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents
In src/parser.rs around lines 326-333, fix `ignore_multi()`/`ignore_single()` so
whole-line `// ...` comments inside `ignore (...)` blocks are consumed instead of being
parsed as path entries. In `ignore_single` (lines 314-324), detect and consume a comment
at the start of the line (after optional whitespace) and return an empty result, rather
than calling `take_till(..., WHITESPACES)` before `opt(comment)`. Ensure
`ignore_multi`'s `repeat(…, terminated(ignore_single, multispace0))` still skips
newlines/spaces after comment lines. Additionally, consider extracting the shared `(`
... `)` repetition and `<single>` parser pattern into a helper reused by
`require_multi`, `replace_multi`, `retract_multi`, `godebug_multi`, and `ignore_multi`.
| pub exclude: Vec<ModuleDependency>, | ||
| pub replace: Vec<ModuleReplacement>, | ||
| pub retract: Vec<ModuleRetract>, | ||
| pub ignore: Vec<String>, | ||
| } |
There was a problem hiding this comment.
Adding public ignore: Vec<String> to GoMod makes GoMod { ... } construction non-exhaustive, so downstream crates will fail to compile unless they set it too — should we treat this as a breaking change or hide direct construction with a builder/#[non_exhaustive] + accessors?
Finding type: Breaking Changes | Severity: 🟠 Medium
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In src/lib.rs around
lines 45-57, the GoMod struct adds a new public field `pub ignore: Vec<String>`, which
breaks downstream crates using `GoMod { ... }` exhaustive struct literals because they
now must include `ignore`. Refactor the API to restore source compatibility by either
marking GoMod with `#[non_exhaustive]` and making `ignore` non-public (or replacing it
with a private field plus a public accessor like `ignore()`), and/or introducing a
dedicated constructor/builder so external code doesn’t need to construct the struct
via a struct literal. Keep FromStr behavior the same (still parsing Ignore directives)
but update any internal/tests to use the new accessor where needed.
1 participant
User description
This pull request adds support for parsing the new
ignoredirective in Go module files added in Go 1.24Generated description
Below is a concise technical summary of the changes proposed in this PR:
Add
ignoredirective handling to the Go module parser by wiring the new field intoGoMod::from_strand returning parsed ignore paths from the directive dispatch. Update parser logic and supporting sample data to read single/multi-lineignoreblocks and verify thatGoModreports the expected ignored paths.ignoredirectives so that the module parser captures single and parenthesized ignore blocks, records them on theGoModstruct, and accepts directives at the end of files.Modified files (3)
Latest Contributors(0)
ignoredirectives, including parser unit tests and data file scenarios to ensure the new field is populated as expected.Modified files (2)
Latest Contributors(0)