chore(deps): bump syn from 2.0.119 to 3.0.5

[dependabot]

Bumps syn from 2.0.119 to 3.0.5.

Release notes

Sourced from syn's releases.

3.0.5

• Report correct span for lex errors from LitStr::parse_with (#2080, thanks @​sunshowers)

3.0.4

• Allow safe fn in impl Parse for ForeignItemFn (#2078)

3.0.3

• Documentation improvements

3.0.2

• Add Error::new_range(start..end, "msg") (#2068, #2070)
• Add Cursor::prev_span

3.0.1

• Parse const traits (#2056, #2057, #2058, #2063, #2064)
• Parse unsafe binder types (#2065)
• Parse impl restrictions (#2066)

3.0.0

This release contains adjustments to the syntax tree to account for ongoing Rust language development from the 3 years since syn 2.0.0 and to anticipate some in-flight Rust language RFCs.

These include: default values in fields, pinned type sugar, raw lifetimes, generator blocks and functions, unnamed enum variants, attributes in tuple types and tuple patterns, named arguments in parenthesized generic argument lists, lightweight clones, const traits, const function pointers, mutability restricted fields, supertrait auto implementation, final associated functions, trait implementability restrictions, const blocks in path arguments, item-level const blocks, return type notation, never patterns, function delegation, mutable by-reference bindings, in-place initialization, field projections, explicitly dyn-compatible traits, view types, file-level frontmatter, generic const arguments, guard patterns, lazy type aliases, explicitly safe foreign items, super let, unsafe fields, pattern types, heterogeneous try-blocks, function contracts, async function trait bounds, static closure coroutine syntax, unsafe binder types, move expressions, for-await loops, and postfix keywords.

Breaking changes

Modifiers

To reserve more room for language evolution, there are 10 new non-exhaustive structs in the syntax tree having the following commonality:

• Name ending in Modifiers. {BlockModifiers, ClosureModifiers, ConstModifiers, FieldModifiers, FnModifiers, ImplModifiers, LocalModifiers, TraitBoundModifiers, TraitModifiers, TypeModifiers}

• Each implements Default. The default value is guaranteed to comprise no tokens.

• Non-exhaustive. Can only be instantiated by Syn's parser or by creating and then mutating ▁▁Modifiers::default().

• Does not implement Parse. When parsing, they are parsed by the enclosing syntax tree node.

• Does not implement ToTokens. In some cases the syntax that these nodes might hold in the future is not necessarily contiguous tokens.

• Provides .require_empty() -> Result<()> which returns a meaningfully spanned error if the modifiers are different from the empty default. This enables a caller to reject syntax it does not recognize without knowing what that syntax may be.

Types

• Type::BareFn has been renamed to Type::FnPtr to mirror the compiler's terminology. Together with this, BareVariadic is renamed to FnPtrVariadic.

• The mutually exclusive const_token and mutability fields of Type::Ptr have been unified into an enum of type PointerMutability, which was already previously used by Expr::RawAddr.

... (truncated)

Commits

• e0ad92d Release 3.0.5
• 74e7d75 Merge pull request #2080 from sunshowers/lit-str-span
• 4c264f3 In LitStr::parse_with, report correct span for lex errors
• 7e2b27b Update test suite to nightly-2026-08-26
• b5d62a6 Release 3.0.4
• abf019c Merge pull request #2078 from dtolnay/foreginitemfn
• d454333 Allow safe fn in impl Parse for ForeignItemFn
• 8011b1c Update test suite to nightly-2026-08-18
• 56a8d83 Raise rayon thread size for tests
• f2c5c50 Ignore assert_is_empty pedantic clippy lint
• Additional commits viewable in compare view

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.30%. Comparing base (6c0e65d) to head (1ac7b30).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2209      +/-   ##
===========================================
- Coverage    85.31%   85.30%   -0.01%     
===========================================
  Files          353      353              
  Lines        31240    31240              
  Branches     31240    31240              
===========================================
- Hits         26651    26650       -1     
- Misses        4204     4207       +3     
+ Partials       385      383       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[da2ce7]

APPROVE — review round r1, head 28c9d2b7960ae7c38c126a267fb45acefedfbe6d.

This PR supersedes #2106, which dependabot closed on 2026-09-11T19:44:23Z with the comment Superseded by #2209 when it re-cut the bump onto the current develop. #2106 carried an approval and an ACK at 1f060a55d39ab989c65e694495258d1f6863fc70; an ACK names one tip, so it does not carry across to a new pull request, and this round re-establishes the evidence at the new head rather than pointing at the old one.

Patch identity with the previously ACKed head

	#2106	#2209
base (merge-base)	bd4aa83a — Merge #2201: chore: update dependencies	e53892791af6f497ce4c35bce6bc7a3c55c97ee2
head	1f060a55	28c9d2b7
commits	1	1
patch bytes	779	779
patch sha256	a9ceb8a6…9947e8	a9ceb8a6…9947e8

diff -u of the two patches is empty — not merely equivalent hunks, but identical bytes, index lines included. That the blob hashes agree is the stronger statement: the pre-images of both files were already the same at bd4aa83a and at e5389279, so #2201's dependency update did not touch either of them, and the re-cut is a pure rebase with no content change. The base moved between the two pull requests; the patch did not, and it is still byte-for-byte the object that was reviewed and ACKed.

e5389279 is the merge-base of head and develop, the PR targets develop, there is exactly one commit, and its author is dependabot[bot]. The only trailers are dependabot's own updated-dependencies block and its sign-off; unlike the previous round, the metadata is now internally consistent — dependency-version: 3.0.5, branch dependabot/cargo/develop/syn-3.0.5, title, manifest and lock all name 3.0.5.

The diff

Two files, one line each.

• contrib/dev-tools/analysis/workspace-coupling/Cargo.toml: the syn requirement moves from "2" to "3", features full and visit unchanged.
• Cargo.lock: the workspace-coupling package node's dependency list retargets syn 2.0.119 to syn 3.0.5. Nothing else in the lock moves.

Both syn majors remain lock nodes after the bump (Cargo.lock at head carries syn 2.0.119 and syn 3.0.5 as separate packages), because other dependents still require ^2. That duplicate is pre-existing on develop, and deny.toml:24 sets multiple-versions = "warn" for exactly this class of pre-existing duplication; cargo deny check bans answers bans ok, with warning[duplicate]: found 2 duplicate entries for crate 'syn' among the nineteen duplicate warnings it already emits on the base.

syn surface of the tool, recomputed item by item at this head

contrib/dev-tools/analysis/workspace-coupling/src/ is unchanged by this PR and unchanged since bd4aa83a, so the question is only whether every item it names still exists in syn 3.0.5. Checked against the 3.0.5 crate source, not against the changelog:

item used	use site (src/lib.rs)	present in syn 3.0.5
syn::parse_file	26	src/lib.rs:1108
syn::Error	24, 25	src/error.rs:107
syn::visit::Visit (trait)	5, 42	src/gen/visit.rs:28
Visit::visit_file	32	src/gen/visit.rs:354
Visit::visit_item_use	43	src/gen/visit.rs:522
Visit::visit_macro	47	src/gen/visit.rs:577
Visit::visit_path	52	src/gen/visit.rs:685
syn::visit::visit_macro (free fn)	49	src/gen/visit.rs:2830
syn::visit::visit_path (free fn)	54	src/gen/visit.rs:3182
syn::ItemUse	43	src/item.rs:510
syn::Macro	47	src/mac.rs:17
syn::Path	6, 52, 129	src/path.rs:15
syn::UseTree and all five variants Path/Name/Rename/Glob/Group	6, 59-81	src/item.rs:633

Thirteen items, none missing, none renamed, none behind a deprecated alias. That is consistent with the shape of the 3.0 break: the breaking changes are the ten new non-exhaustive *Modifiers structs, Type::BareFn to Type::FnPtr (with BareVariadic to FnPtrVariadic), the unification of Type::Ptr's const_token/mutability into PointerMutability, attributes on every Type variant, BareFnArg to NamedArg, and the Expr::Closure token rename. This tool constructs no syntax-tree nodes and matches on none of those variants — it parses a file, walks it with the default Visit traversal, and records use paths and macro paths — so a major bump lands here as a one-line manifest edit with no code change. syn 3.0.5 declares rust-version = "1.71", identical to 2.0.119 and comfortably under the workspace MSRV.

Licence

syn 3.0.5 is MIT OR Apache-2.0, byte-identical to syn 2.0.119's field in the same registry. deny.toml contains no reference to syn in any section, and its [licenses] section is explicitly left unconfigured ("License checking is a separate concern and not configured here"), so nothing in the repository's dependency policy has to move with this bump.

Third-party dependent sets are untouched

cargo tree -i was run for both majors at develop and at this head:

	develop e5389279	head 28c9d2b7
direct dependents of syn 2.0.119	15	15 (identical set)
direct dependents of syn 3.0.5	12	12 (identical set)

The 15 on the 2.x line are proc-macro/derive crates (axum-macros, derive_more-impl, mockall_derive, openssl-macros, pear_codegen, pest_generator, proc-macro2-diagnostics, sqlx-macros, sqlx-macros-core, synstructure, thiserror-impl 1.x, tracing-attributes, yoke-derive, zerocopy-derive, zerofrom-derive); the 12 on the 3.x line are async-trait, clap_derive, darling_core, darling_macro, displaydoc, futures-macro, multiversion-macros, serde_derive, serde_with_macros, thiserror-impl 2.x, tokio-macros, zerovec-derive. syn 2.0.119 therefore stays in the graph after the bump; that is upstream's business and resolves as those crates migrate.

One note on method, because it changes what these two tables do and do not prove. The gate ran cargo tree -i syn@… --all-features without --workspace, so it resolves from the root package and never reaches workspace-coupling, which is a workspace member (Cargo.toml:125) but not a dependency of the root binary. The tables above are consequently evidence that no third-party edge moves, which is the risk-bearing half; the tool's own edge is read directly from the lock diff and is confirmed by the build, where workspace-coupling v0.1.0 is checked, linted, compiled and tested at this head against the new lock. A --workspace-scoped tree would show the member edge too, and that is worth adding to the dependency-lane script.

Gates

Server lane on a detached worktree pinned to 28c9d2b7, git status --porcelain empty, one shared target directory under a lock. Toolchain rustc 1.100.0-nightly (a69a63265 2026-09-03), cargo 1.100.0-nightly (b2e9d5f9d 2026-09-02). Twelve commands, every one exit 0.

gate	exit	wall	result
cargo tree -i syn@2.0.119 --all-features (at develop)	0	0.3s	15 direct dependents
cargo tree -i syn@3.0.5 --all-features (at develop)	0	0.3s	12 direct dependents
cargo tree -i syn@2.0.119 --all-features (at head)	0	0.3s	15, identical set
cargo tree -i syn@3.0.5 --all-features (at head)	0	0.3s	12, identical set
cargo machete --with-metadata	0	7.4s	no unused dependencies
cargo deny check bans	0	1.4s	bans ok
linter all	0	27.5s	all linters passed (clippy, rustfmt, shellcheck, …)
cargo check --workspace --all-targets --all-features	0	10.0s	includes Checking workspace-coupling v0.1.0
cargo clippy --workspace --all-targets --all-features -- -D warnings	0	12.0s	clean
cargo test --workspace --all-targets --all-features	0	153.4s	57 suites, 2603 passed, 0 failed, 0 ignored
cargo test --doc --workspace --all-features	0	6.2s	24 suites, 30 passed, 0 failed, 2 ignored
contrib/dev-tools/git/hooks/pre-commit.sh	0	49.0s	6/6 steps PASS

2633 passing tests in total. Among them the tool's own nine integration tests in tests/parse_imports.rs run against syn 3 and pass — the compile is real rather than a cache hit, and the parse behaviour the tool depends on is exercised, not merely type-checked.

CI at this head

workflow (event)	run	conclusion
Testing (pull_request)	34640452735	success
Container (pull_request)	34640452576	success
OS Compatibility (pull_request)	34640452522	success
Generate Coverage Report (PR)	34640452447	success
Docs Lint (pull_request)	34640452412	success
Docs Lint (push)	34640449297	success
OS Compatibility (push)	34640449154	success
Testing (push)	34640449394	failure — Docker E2E only

Every commit check run at this sha is success or skipped except the one Docker E2E job in run 34640449394. Inside that job Layer Boundary Bans, Unit (stable) and Unit (nightly) all pass, Build Tracker Image succeeds, and the single failing step is Run E2E Tests; the three qBittorrent steps are skipped as downstream of it. That is #2179 — the workflow's cargo run --bin e2e_tests_runner omits the owning package, so it fails at target resolution before any code runs, which no dependency version can influence. The same job is skipped on the pull_request run, because its guard excludes pull requests based on develop, which is why the defect is invisible on develop and appears only on feature-branch pushes. A specification for it is open as #2194.

PR description

Dependabot's body links the 2.0.119…3.0.5 compare view and quotes the 3.0.0-through-3.0.5 release notes, including the full breaking-change list; the compatibility-score badge it renders is the generic Dependabot badge with no score committed to in the body text. The quoted notes match what the diff does: a major-version requirement change with the 3.0.5 delta being one span fix in LitStr::parse_with (dtolnay/syn#2080), an entry point this tool never calls.

Checklist notes

Against .github/skills/dev/pr-reviews/review-pr/SKILL.md: title is Conventional Commits (chore(deps): …, line 27), the target branch is develop (line 30), and the code-quality, test and documentation blocks (lines 32-52) have no applicable item — this PR adds no code, no API surface and no user-facing behaviour, and the linked-issue item (line 29) does not apply to a bot-authored dependency bump. Nothing in the checklist is unmet.

No blockers, no suggestions, one nit:

• Nit — the syn 2.0.119 node stays in the lock after this bump and will stay until the fifteen 2.x proc-macro dependents migrate. Nothing to do here; worth knowing that this PR does not reduce the lock's syn duplication, and deny.toml's multiple-versions = "warn" is what keeps that from being a gate failure.

[da2ce7]

ACK 28c9d2b — re-cut of the previously ACKed syn 3 bump for the workspace-coupling tool, patch byte-identical to #2106's head, all thirteen syn items it uses present unchanged in 3.0.5, twelve server gates green at this exact head, and the only red CI job the pre-existing #2179 Docker E2E target-resolution defect.

[da2ce7]

APPROVE — review round r2, head 585cf2442c110e0c7ec3cbf2c48bdb69ee24f6bd.

The force-push of 2026-09-14T15:06:52Z dismissed the r1 approval, which was bound to 28c9d2b7. An approval names one tip, so this round re-establishes the evidence at the new tip. The substance of the semver-major move was settled in r1 and is not re-litigated here; what r2 adds is the rebase itself, the gates and CI at the new head, and the one thing the rebase newly introduced.

The force-push is a rebase, but not a pure re-cut — it grew by one file

	r1	r2
base (merge-base with develop)	e53892791af6f497ce4c35bce6bc7a3c55c97ee2	f3eb9aa83979f3624a9180176924d2ba6e29220c
head	28c9d2b7	585cf244
commits	1	1
files changed	2 (+2 -2)	3 (+4 -4)

git range-diff f3eb9aa8..585cf244 e5389279..28c9d2b7 reports one commit on each side with the same subject and the same commit message, and shows exactly one difference: the new head carries a second Cargo.lock hunk and a third file, contrib/dev-tools/checks/clippy-allow-reasons/Cargo.toml, moving that manifest's syn requirement from "2" to "3" with features full/visit unchanged.

The cause is in develop, not in the branch. f3eb9aa8 is the merge of #2177, which introduced the workspace member contrib/dev-tools/checks/clippy-allow-reasons (added in d87a503c) declaring syn = { version = "2", features = [ "full", "visit" ] }. That member did not exist at e5389279. Dependabot re-derived the bump against the new tree, so it now covers both manifests that name syn, which is the correct outcome for a dependency bump: leaving the new member on syn 2 would have preserved the duplicate rather than reduced it.

The previously reviewed half is unchanged, not merely equivalent: contrib/dev-tools/analysis/workspace-coupling/Cargo.toml resolves to blob 51aa250c70a006cbc605b51b8eb23eda496d96c9 at 28c9d2b7 and at 585cf244. Its Cargo.lock hunk is likewise unchanged apart from the hunk header's line offset, which moved because develop grew above it.

The commit is single-parent on f3eb9aa8, authored by dependabot[bot], subject chore(deps): bump syn from 2.0.119 to 3.0.5 in the repository's convention, and its only trailers are the updated-dependencies block (dependency-version: 3.0.5, update-type: version-update:semver-major) and dependabot's own sign-off.

Lockfile delta: no crate version moves at all

Comparing every [[package]] name/version pair between f3eb9aa8:Cargo.lock and 585cf244:Cargo.lock:

measure	base f3eb9aa8	head 585cf244
package nodes	581	581
crates whose version differs	—	none
syn nodes present	2.0.119 and 3.0.5	2.0.119 and 3.0.5
dependency-list references to syn 2.0.119	32	30
dependency-list references to syn 3.0.5	15	17

syn 3.0.5 is already a lock node on develop — other dependents resolve to it — so this bump adds no node and removes none. The entire lock change is two dependency edges retargeting from the 2.0.119 node to the 3.0.5 node. syn 2.0.119 stays, because thirty other edges still require ^2; deny.toml:24 sets multiple-versions = "warn" for exactly that pre-existing duplication, and cargo deny check bans answers bans ok at this head.

Inverted dependency trees, run at both commits (--workspace scoping added this round, since the root-scoped form cannot reach a workspace member's own edge):

direct dependents	base f3eb9aa8	head 585cf244
syn 2.0.119, --workspace	26, including clippy-allow-reasons and workspace-coupling	24, neither member present
syn 3.0.5, --workspace	13	15, both members present
syn 2.0.119, root-scoped	15	15, identical set
syn 3.0.5, root-scoped	12	12, identical set

The root-scoped pair is unchanged on both sides, so no third-party edge moves; the workspace-scoped pair shows the two member edges moving and nothing else.

The newly covered consumer

clippy-allow-reasons was never part of a reviewed round, so its syn surface is new evidence rather than inherited. Its source is untouched by this PR; the question is only whether every item it names exists in 3.0.5 with the same meaning. It uses syn::parse_file, syn::Error, syn::parse::Parser (via parse2), syn::punctuated::Punctuated with parse_terminated, syn::spanned::Spanned and the proc-macro2 span-locations line numbers it yields, syn::visit::{self, Visit} with an overridden visit_attribute and the free visit::visit_attribute, syn::Attribute and its meta field, syn::Meta with the List, Path and NameValue variants, syn::Token![,], Path::is_ident, path.segments, and syn::Expr::Lit / syn::Lit::Str.

Rather than read those off the crate source, the build answers directly: at this head the member compiles under cargo check, under cargo clippy -D warnings, and under cargo test, and its own suites pass — 13 unit tests in src/lib.rs, 3 in src/main.rs, and 8 integration tests in tests/cli.rs. Those tests are the behavioural half of the question, since they exercise the attribute shapes the validator has to classify; a silent semantic change in Meta or span handling would show up there. workspace-coupling's three suites also pass, as in r1.

Gates at this head

Nightly toolchain on the lane server (rustc 1.100.0-nightly (809936eac 2026-09-12), cargo 1.100.0-nightly (7941be6fb 2026-09-11)), same command set as the r1 round plus the two --workspace tree invocations noted above.

gate	wall	result
cargo tree -i syn@2.0.119 --all-features (base, head)	0.4 s, 0.3 s	ok
cargo tree -i syn@3.0.5 --all-features (base, head)	0.3 s, 0.3 s	ok
cargo tree -i syn@2.0.119 --workspace --all-features (base, head)	0.3 s, 0.3 s	ok
cargo tree -i syn@3.0.5 --workspace --all-features (base, head)	0.3 s, 0.3 s	ok
cargo machete --with-metadata	8.0 s	ok
cargo deny check bans	1.4 s	bans ok
linter all	8.0 s	fails on missing lane tooling — see below
cargo check --workspace --all-targets --all-features	10.3 s	ok
cargo clippy --workspace --all-targets --all-features -- -D warnings	12.2 s	ok
cargo test --workspace --all-targets --all-features	176.3 s	85 suites, 2657 passed, 0 failed, 2 ignored
cargo test --doc --workspace --all-features	6.0 s	ok
contrib/dev-tools/git/hooks/pre-commit.sh	26.8 s	steps 1-4 and 6-7 pass; step 5 is the same linter failure

The two red results are a property of the lane environment, not of this branch. linter all could not run markdownlint, cspell or yamllint; with the npm prefix's bin directory on PATH, markdown linting and spell checking pass at this head and only yamllint remains unavailable, because the linter's installation path for it needs a package manager the lane cannot use. The control settles it: the identical command, in the identical environment, on develop at f3eb9aa8 with no PR content at all, fails the same way, and so does the pre-commit hook there. Ten of the eleven linters pass at this head, the branch changes no YAML, and the repository's own Docs Lint and Documented Clippy Allows workflows are green on it.

CI at 585cf244

Eleven workflow runs, all completed; none ended in startup_failure, so every workflow that was triggered produced real check runs. Forty-one check runs: thirty-eight success, two skipped (Publish (Development), Publish (Release)), one failure.

workflow (event)	run	conclusion
Testing (pull_request)	34860030847	success
Container (pull_request)	34860030725	success
OS Compatibility (pull_request)	34860030813	success
Docs Lint (pull_request)	34860030893	success
Generate Coverage Report (PR)	34860030637	success
Database Benchmarking (push)	34860025254	success
Database Compatibility (push)	34860025108	success
OS Compatibility (push)	34860025199	success
Docs Lint (push)	34860025252	success
Copilot Setup Steps (push)	34860025208	success
Testing (push)	34860025060	failure — Docker E2E only

Inside the failing run, Layer Boundary Bans, Unit (stable), Unit (nightly) and Documented Clippy Allows all pass; in Docker E2E the image builds and the single failing step is Run E2E Tests, with the three qBittorrent steps skipped behind it. That is the #2179 shape — the job is red on feature-branch pushes and skipped on the pull-request event, which is why the pull-request Testing run is green at the same commit. It is unrelated to this bump.

One scheduling note

#2213 (chore: update dependencies) is open against the same base and changes Cargo.lock only. Its crate set and this one do not overlap: #2213 moves fifteen semver-compatible crate versions and drops tinyvec_macros, mentions syn nowhere, and this PR moves no crate version at all. They are independent in content, but not in the file: whichever merges first will make the other's lock hunks stale, and if #2213 lands first dependabot will likely rebase this branch once more, at which point the head moves again and this round's evidence is superseded along with it.

[da2ce7]

ACK 585cf24 — rebase onto f3eb9aa re-derived the bump over the member #2177 added, so it now moves both syn-naming manifests while the previously reviewed one is blob-identical; the lock gains no node and moves no crate version, twelve gates plus two workspace-scoped trees are green at this head with the sole red pair reproduced identically on develop itself, and the only failing CI job is the pre-existing #2179 Docker E2E defect.

[da2ce7]

APPROVE — review round r3, head 1ac7b306cafcf8bcad333d5c77ff4ab3d5c1f3b2.

#2213 chore: update dependencies merged into develop at 18:11:25Z, and this branch was force-pushed onto the new tip 6c0e65da at 18:13:50Z. The approval from r2 carried across that push rather than being dismissed, which is consistent with what the rebase turns out to be — but an ACK names one tip, so the evidence is re-established here.

The rebase is a pure re-cut

git range-diff f3eb9aa8..585cf244 6c0e65da..1ac7b306 reports 1: 585cf244 = 1: 1ac7b306. One commit each side and the patches are identical, not merely equivalent. That is a stronger result than r2, where the rebase genuinely changed the patch by picking up the second syn-naming member #2177 had just added. Nothing is added or dropped this time.

Checked literally as well as by range-diff: both manifest hunks (workspace-coupling, clippy-allow-reasons, each syn = { version = "2" … } to "3") are byte-identical to r2's, and the Cargo.lock hunk is the same two syn 2.0.119 to syn 3.0.5 lines. Diffstat 3 files, +4/-4. The commit's parent is 6c0e65da and the merge-base equals it, so there is no divergence from develop.

The lockfile delta is empty

Every [[package]] name/version pair was extracted from both lockfiles by two independent methods, required to agree before any delta was reported; they agreed exactly. 580 nodes on each side and the sorted sets diff clean — no crate version moves at all.

The bump is an edge move rather than a node change: both majors were already lock nodes on develop, and exactly two member edges retarget (references to syn 2.0.119 go 32 to 30, syn 3.0.5 15 to 17, which balances). All 15 crates #2213 refreshed sit at identical versions on both sides, and tinyvec_macros is absent from both, so #2213's removal survives the rebase intact.

The dependency graph is likewise unchanged from the approved tip: the four inverted syn trees reproduce r2's head-side counts exactly — 24 and 15 workspace-scoped, 15 and 12 root-scoped. Neither bumped member appears under syn 2.0.119 --workspace; both appear under syn 3.0.5 --workspace.

Gates

Lane server, nightly (rustc 1.100.0-nightly (809936eac 2026-09-12)), detached worktree at this head, shared target directory under lock, everything at minimum priority. Twelve of twelve green: machete 19.9 s, deny bans 1.4 s, check 64.8 s, clippy -D warnings 12.4 s, test 182.9 s, doc tests 6.0 s, four inverted trees 0.3-0.4 s each, linter all 28.6 s, pre-commit hook 51.9 s — all exit 0.

Tests: 85 suites, 2687 passed, 0 failed, 2 ignored, with both bumped members running their full suites. The 2657 to 2687 increase is develop's own movement (127 commits between the two bases, including #2174's UDP server tests), not this PR, which changes no test. The elevated check wall against r2's 10.3 s is the near-cold rebuild #2213's refreshed crates forced on the shared target directory — a cache effect, not a code regression.

Worth recording: linter all and the pre-commit hook were the two red gates at r2, excused there by a control run on develop that reproduced the failure without any PR content. Both are green here, and no repository change caused that — the lane simply gained yamllint and the npm prefix on PATH. All eleven linters ran and passed, YAML included.

CI

At 18:27:16Z, about 13 minutes after the push: 19 successes, zero failures, zero startup_failure runs (checked against the workflow-runs endpoint rather than inferred from the checks summary). Green across both events: Docs Lint, Layer Boundary Bans, Documented Clippy Allows, all six platform/toolchain Build jobs, coverage and both codecov checks. Documented Clippy Allows — the job that actually exercises the bumped tool — passes on both events.

Still in progress at the sweep: Unit (stable) and Unit (nightly) on both events, Test (Docker) (release), and the push-event Docker E2E, which is where the known #2179 shape lives; it had not reached its E2E step. Nothing is red. The lane's own run covers the same unit and doc-test surface as the pending jobs and is green.

Standard

One commit; exactly one trailer, dependabot's own Signed-off-by; no AI co-author trailer; subject unchanged from r1 and r2; base develop, MERGEABLE, unstable only for pending checks. No open all-dependencies PR now that #2213 is merged. #2055 is untouched by this rebase.

The substance of the semver-major syn 2 to 3 move was settled in r1 and confirmed in r2; it is inherited and not re-litigated. What this round establishes is narrower and sufficient: the new tip is the same change on a newer base, and it is green.

[da2ce7]

ACK 1ac7b30 — the rebase onto 6c0e65d is patch-identical to the tip approved at r2 (range-diff reports the commits equal), the lockfile carries no package name/version delta at all by two independent extractions and moves only the two syn edges while #2213's 15 refreshed crates and its tinyvec_macros removal survive intact, the four inverted syn trees reproduce r2's counts exactly, twelve of twelve gates are green at this head including the two that were only environmentally red at r2, and CI shows 19 successes with no failure and no startup_failure.

[josecelano]

Superseded by #2218, which updates base64 together with the related syn Dependabot update.

[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.