redundant_nil_coalescing false-positive on double optionals: autofix ships a compile break that lint reports clean

[coenttb]

Found by the swift-json lint lane (coordinator session 8830f961), 2026-08-10. At two sites in swift-foundations/swift-json, redundant_nil_coalescing flagged } ?? nil where the ?? nil FLATTENS a double optional (T??) returned by withContiguousStorageIfAvailable. Applying the correction produced declared closure result 'Self?' is incompatible with contextual type 'Self' — a compile break that the linter itself then reports as clean.

Fleet-wide hazard: any lane running swiftlint --fix on this rule can land a compile break, and lint gives no signal. The rule's predicate must exclude positions where the coalesced expression is itself optional (double-optional flattening). Fixture wanted: a T?? site that must NOT fire, plus the ordinary T? positive control. Consumer-side workaround used in swift-json: rewrite as .flatMap { $0 } (semantically exact, not a disable).

[coenttb]

Verdict: GENUINE DEFECT. Independently reproduced by the linter-defect reproduction session (commissioned by the principal via the Launch coordinator, 2026-08-10). Reproducer: swift-issue-swiftlint-redundant-nil-coalescing-double-optional/.

Instrument

The exact instrument the fleet's CI runs, not a local approximation: SwiftLint 0.63.3 swiftlint_linux_amd64, sha256 26db741d43f2f2dc26c0cf16911100a3e186c3d1dbb59e55ad3ac87b0de4538f — byte-identical to the SWIFTLINT_SHA256 pin in swift-institute/.github's swift-ci.yml — executed inside the release-floor container image swiftlang/swift@sha256:8d614165059587ce9dcf6727a76aeff4cbf1cde41fde9a9281a43803be736224 (Swift version 6.4-dev, x86_64-unknown-linux-gnu), which is the image the lint job declares. Invocation mirrors CI: swiftlint lint --strict.

SwiftLint 0.65.0 on macOS arm64 reproduces identically.

Measured

Minimal fixture, two sites differing only in the optionality depth of the coalesced expression:

step	result
swiftc -typecheck before	exit 0
swiftlint lint --strict	2 × redundant_nil_coalescing
swiftlint --fix	Corrected redundant_nil_coalescing 2 times
swiftc -typecheck after	error: value of optional type 'Int?' must be unwrapped to a value of type 'Int'
swiftlint lint --strict after	Found 0 violations, 0 serious in 1 file

Positive control: the second site applies ?? nil to an ordinary Int?, where the rule is right and the correction is sound. It is reported in the same run as the hazard site — that is what proves the instrument ran and the rule was enabled, rather than a misresolved configuration producing a confident zero.

Hazard-shape control: the two sites are identical but for optionality depth, so the depth is isolated as the discriminator by construction. Restoring ?? nil at the double-optional site alone restores compilation.

The precise predicate that is wrong

redundant_nil_coalescing matches ?? nil on the syntax of the operator and its right-hand operand alone. It never consults the type of the left-hand expression, so it cannot distinguish T? ?? nil (dead code) from T?? ?? nil (the flattening step). Correctness of the rule requires the left-hand expression to be a single optional — a type-level fact SwiftLint's syntax-only engine does not have available.

The second half is independent of the first, and is arguably the worse one: after the correction the file does not compile, and swiftlint lint --strict still exits 0. Lint cannot detect that its own correction broke the build.

Ownership

redundant_nil_coalescing is an upstream realm/SwiftLint built-in rule, enabled fleet-wide by the Tier 1 opt_in_rules list in swift-institute/.github's .swiftlint.yml. It is not a swift-institute-linter-rules predicate, so this issue is filed against a repository that does not own the rule. Recording the fact; the disposition is the principal's.

Production sites

swift-foundations/swift-json at 8fbf175, Sources/JSON/JSON.Decode.swift:51 and Sources/JSON/JSON.Serializable.swift:223. Both still carry ?? nil as measured — the lane reverted its correction. Their closures return Self?, which yields the declared closure result 'Self?' is incompatible with contextual type 'Self' diagnostic the lane reported; the concrete Int? reduction yields the unwrap diagnostic instead. Same class, verified in both shapes.

No rule change, predicate edit, or disposition is proposed here — establishing the facts was the commission.

— linter-defect reproduction session