chore(deps)(deps): bump nom from 7.1.3 to 8.0.0

[dependabot]

Bumps nom from 7.1.3 to 8.0.0.

Changelog

Sourced from nom's changelog.

8.0.0 2025-01-25

This version represents a significant refactoring of nom to reduce the amount of code generated by parsers, and reduce the API surface. As such, it comes with some breaking changes, mostly around the move from closure based combinators to trait based ones. In practice, it means that instead of writing combinator(arg)(input), we now write combinator(arg).parse(input).

This release also marks the introduction of the nom-language crate, which will hold tools more focused on language parsing than the rest of nom, like the VerboseError type and the newly added precedence parsing combinators.

Thanks

• @​cky
• @​5c077m4n
• @​epage
• @​Fumon
• @​jtracey
• @​OliveIsAWord
• @​Xiretza
• @​flier
• @​cenodis
• @​Shadow53
• @@​jmmaa
• @​terror
• @​zanedp
• @​atouchet
• @​CMDJojo
• @​ackxolotl
• @​xmakro
• @​tfpk
• @​WhyNotHugo
• @​brollb
• @​smheidrich
• @​glittershark
• @​GuillaumeGomez
• @​LeoDog896
• @​fmiras
• @​ttsugriy
• @​McDostone
• @​superboum
• @​rruppy
• @​thssuck
• @​Chasing1020
• @​thatmarkenglishguy
• @​ambiso
• @​boxdot
• @​krtab
• @​code10129
• @​manunio
• @​stuarth
• @​mindeng
• @​JonathanPlasse
• @​nabilwadih
• @​phoenixr-codes

... (truncated)

Commits

• 2cec1b3 v8.0.0 (#1797)
• 7afe3a8 Merge pull request #1793 from rust-bakery/beta.1
• 84af9e7 nom 8.0.0-beta.1
• 555eab9 Merge pull request #1792 from rust-bakery/nom-language
• 6a25312 fix nom-language tests
• bcc1b0c move the left_assoc combinator to nom-language
• 9b0e18c Implement new parser left_assoc. (#1775)
• cb3b5b8 move precedence parsing to nom-language
• f1abba6 fix precedence parsing
• 6c12469 Precedence parsing (#1362)
• Additional commits viewable in compare view

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[nikhilunni]

@dependabot recreate

[engrams-agent]

✅ engrams review — complete. 1 finding posted. · View details

[engrams-agent]

Engrams review

Verdict: 1 finding posted inline.
Severity: Critical 1 · High 0 · Medium 0 · Low 0
Categories: 🎯 Functional Correctness: 1

View the full engrams review

[engrams-agent]

🎯 Functional Correctness · CRITICAL — nom 7→8 bump breaks compilation of engram-egress-proxy (two nom versions collide in sni.rs)

WHAT: Bumping the workspace nom dependency from 7 to 8 makes engram-egress-proxy resolve nom to nom 8.0.0, but crates/engram-egress-proxy/src/sni.rs:69 matches a value produced by tls_parser, which is still pinned to nom 7.1.3. The Err(nom::Err::Incomplete(_)) pattern now names nom 8's Err type while the scrutinee is a nom 7 Err. Because two different crate versions produce two distinct, non-interchangeable types, this is a hard type-mismatch and the crate no longer compiles.

WHEN: Every build. sni.rs line 41 does match parse_tls_plaintext(&buf) { ... }. parse_tls_plaintext comes from tls_parser 0.12.2, whose error type is nom7::Err<...> (Cargo.lock keeps tls-parser on nom 7.1.3). Line 69's pattern Err(nom::Err::Incomplete(_)) resolves nom:: to engram-egress-proxy's own direct dependency, which this PR just moved to nom 8.0.0 (Cargo.toml:269 + nom.workspace = true in the crate manifest). Before this PR both were nom 7.1.3, so the arm type-checked; after it, the arm's expected type (nom8::Err) no longer matches the scrutinee's type (nom7::Err), so cargo check -p engram-egress-proxy fails and the whole workspace build/CI breaks. engram-egress-proxy is the sole first-party crate using nom (only sni.rs references it), so it is the single point of breakage.

I could not run cargo in this environment (no toolchain present), so I confirmed this by static analysis of the manifests, Cargo.lock, and the one source site — not by an actual compile.

Suggested change

	nom = "8"
	Keep the direct `nom` dependency of `engram-egress-proxy` on the same major version that `tls-parser` uses (`nom = "7"`), or replace the `nom::Err::Incomplete` reference in `sni.rs` with `tls_parser`'s re-exported nom type (e.g. match on `tls_parser::nom::Err::Incomplete`) so both sides use one nom version. Only bump `nom` to 8 once `tls-parser` also moves to nom 8.

[engrams-agent]

Deferred — nom 8 cannot enter this tree until tls-parser moves

I took this on in today's dependency sweep and reproduced the failure locally on
the branch rebased onto current main. I am not pushing a migration: this bump
is red by construction, not by oversight.

The failure

We have exactly one direct nom touchpoint in the whole workspace:

crates/engram-egress-proxy/src/sni.rs:69

Err(nom::Err::Incomplete(_)) => {

That arm matches the error returned by tls_parser::parse_tls_plaintext. So the
nom::Err we name has to be tls-parser's nom, not ours. This PR moves our
direct pin to 8 while tls-parser 0.12.2 stays on nom 7, which puts two noms in
the graph. rustc says it exactly:

error[E0308]: mismatched types
  --> crates/engram-egress-proxy/src/sni.rs:69:21
69 |   Err(nom::Err::Incomplete(_)) => {
   |       ^^^^^^^^^^^^^^^^^^^^^^^ expected `Err<Error<&[u8]>>`, found `Err<_, _>`
note: there are multiple different versions of crate `nom` in the dependency graph
  nom-7.1.3/src/internal.rs:97   pub enum Err<E> {                        <- expected
  nom-8.0.0/src/internal.rs:101  pub enum Err<Failure, Error = Failure> { <- found

The lockfile on this branch carries both nom 7.1.3 and nom 8.0.0, with
tls-parser 0.12.2 -> nom 7.1.3. That is the whole bug.

Why bumping our pin can never fix it

tls-parser 0.12.2 is the newest release (2024-09-09) and it is still on
nom 7. There is no nom-8 tls-parser. Until upstream ships one, our direct pin
is not free to move.

There is also a second, independent reason, which is the part I would flag to a
reviewer. nom is vestigial as a direct dependency — we never parse with it,
we only name a type that belongs to tls-parser's public API. I verified what that
means for the gate: if you decouple the one call site (tls-parser re-exports its
own nom — pub use nom; and pub use nom::{Err, IResult}; at lib.rs:178), so

Err(tls_parser::Err::Incomplete(_)) => {

then engram-egress-proxy compiles clean, and cargo hakari generate
rewrites workspace-hack/Cargo.toml from nom = "8" straight back to
nom = "7" — because nom 7 is then the only nom in the graph. cargo hakari verify runs in just check and in CI, so the gate itself reverts this PR's
central claim. nom 8 has nowhere to live here.

What should actually happen

Two separate pieces of work, neither of which is this PR:

1. Drop the direct nom dependency and match through
   tls_parser::Err. This is a 3-line change (one match arm, one
   nom.workspace = true line in crates/engram-egress-proxy/Cargo.toml, one
   just hakari) and it removes a workspace dependency, so it wants a human's
   yes rather than a bot's. It is the durable fix: after it, the nom version is
   tls-parser's business and this PR class stops existing.
2. When tls-parser 0.13 ships with nom 8, that bump carries nom 8 with it
   and no coordination is needed.

Worth naming: tls-parser's last release is from September 2024, so (1) is the
one I would actually schedule.

Housekeeping

I am adding @dependabot ignore this major version below. This is not a
"not yet" — as long as our only nom contact is tls-parser's error type, a direct
nom 8 pin is always wrong, so the PR would keep reappearing red every time
nom 8.x releases. When tls-parser moves, nom 8 arrives through it. Minor and
patch nom updates are unaffected by the ignore.

I did not push to this branch, so Dependabot keeps ownership of it.

[engrams-agent]

@dependabot ignore this major version

[dependabot]

Sorry, only users with push access can use that command.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.