What
Found while configuring SwiftLint's orphaned_doc_comment rule for the code-style rollout
(#876), not fixed there since fixing either one turned out to obligate a full swift-format sweep
of the whole file under that PR's own "if you touch it, you fix it" manifest rule, and a
~1900-diagnostic reformat of two large files is out of scope for a CI-infrastructure PR.
Both are real, structurally identical bugs: a doc comment separated from the declaration it
documents by an inserted // MARK: line.
-
Sources/OCCTSwift/Surface.swift:1329 — a doc comment ("Convert this surface to an array
of Bezier surface patches...") sits orphaned before // MARK: - Surface Singularity Analysis (v0.37.0), with nothing between it and the MARK. The function it describes,
toBezierPatches() (line 1426), currently has no doc comment of its own — this one belongs
there. Fix: move the comment block to sit directly above toBezierPatches().
-
Sources/OCCTSwift/Shape+Modeling.swift:405 — a doc comment ("Create a pipe shell with
transition mode control...") sits orphaned before // MARK: - Variable-Section Sweep (v0.21.0). Unlike case 1, this one is pure duplication: pipeShell(spine:profile:mode:...)
(line ~391) already has its own complete doc comment covering the same transition parameter
verbatim. Fix: delete the orphaned block, nothing to move.
Why this matters beyond the two instances
Both are the same failure shape SwiftLint's orphaned_doc_comment rule is meant to catch, and
both slipped through undetected until this policy rollout added a check for it — exactly the
"no way of knowing the comments are up to date" problem the wider code-style proposal is about.
What
Found while configuring
SwiftLint'sorphaned_doc_commentrule for the code-style rollout(#876), not fixed there since fixing either one turned out to obligate a full swift-format sweep
of the whole file under that PR's own "if you touch it, you fix it" manifest rule, and a
~1900-diagnostic reformat of two large files is out of scope for a CI-infrastructure PR.
Both are real, structurally identical bugs: a doc comment separated from the declaration it
documents by an inserted
// MARK:line.Sources/OCCTSwift/Surface.swift:1329— a doc comment ("Convert this surface to an arrayof Bezier surface patches...") sits orphaned before
// MARK: - Surface Singularity Analysis (v0.37.0), with nothing between it and the MARK. The function it describes,toBezierPatches()(line 1426), currently has no doc comment of its own — this one belongsthere. Fix: move the comment block to sit directly above
toBezierPatches().Sources/OCCTSwift/Shape+Modeling.swift:405— a doc comment ("Create a pipe shell withtransition mode control...") sits orphaned before
// MARK: - Variable-Section Sweep (v0.21.0). Unlike case 1, this one is pure duplication:pipeShell(spine:profile:mode:...)(line ~391) already has its own complete doc comment covering the same
transitionparameterverbatim. Fix: delete the orphaned block, nothing to move.
Why this matters beyond the two instances
Both are the same failure shape SwiftLint's
orphaned_doc_commentrule is meant to catch, andboth slipped through undetected until this policy rollout added a check for it — exactly the
"no way of knowing the comments are up to date" problem the wider code-style proposal is about.