Changelog

All notable changes to OCCTSwift.

Current: v2.0.0

macOS / iOS (device + simulator) | OCCT 8.0.1 (+ the fifteen carried patches 0010-0012 and 0014-0025; ten earlier patches were absorbed by 8.0.1 itself and retired)

A correctness release, not a wrapping one: it adds almost no operations. Seventeen breaking changes, each named with its migration in SEMVER.md.

v2.0.0

• AAG’s sharedEdgeCount is no longer silently capped at 10 by the bridge’s fixed edge buffer, which made a floor/wall pair sharing more than ten boundary segments under-report. (#761)

Every public member is now documented, and the census that measures that is fixed (#802)

docs/reference/ gained 1,249 sections and extended 208 more across 61 pages, taking check-docs-existence.py --coverage from 509 public members named nowhere in docs/ to 0, against 5,974 public members.

The census itself was wrong in two ways, which is why the reported gap was 1,487 rather than 509. It counted private/internal members, because it built on an extractor that is deliberately access-blind (correct for the staleness gate, wrong for a census of what consumers need), so it demanded reference pages for ~300 implementation helpers. And it counted only headings, so a field documented as a table row read as undocumented, which is what produced 584 empty anchor headings beside tables that already explained every field. Access is now resolved per member, honouring the rules that are not readable off the declaration line: an enum case takes its enum’s access, an unmarked member of a public extension is public while the same member in a bare extension is internal, a nested type in a public extension keeps its public let fields public, and no member is more visible than the type holding it. Any backtick-quoted identifier now counts as “named”. Twelve new self-test rows, each proven load-bearing by injection.

Also corrected while assembling it: ThreadBuild.boolean was still shown as a live enum case and described as behaving like .auto, when it was removed at v2.0.0 and a legacy "boolean" JSON key decodes to .direct; 745 headings that jumped two or more levels were re-levelled; and docs/occtswift-wrapping-gaps.md and docs/integration-tests.md both claimed 3,333 operations across 1,112 headers, unchanged since 2026-04-13, against a derived 4,256 across 1,166.

PDF/SVG/DXF exporters share one drawing-collection pipeline instead of three independent copies (#795)

PDFExporter.swift, SVGExporter.swift and DXFExporter.swift now route their edge, annotation and dimension collection through one shared implementation in DrawingDispatch.swift (DrawingPrimitiveSink, collectDrawing, collectProjectedEdges, strokeWidthMM, formatMM), instead of each independently hand-rolling its own copy. DXFExporter.swift’s own formatTolerance/TolerancedLabel and its separate dimension/annotation dispatch pipeline (emitLinear/emitRadial/emitDiameter/emitAngular/emitOrdinate, collectAnnotations/emitBalloon/emitCuttingPlaneLine/emitHatch) are removed in favour of the same shared dispatcher PDF/SVG already used, closing the gap where a tolerance-formatting fix made to the shared file could previously miss DXF entirely. No public API signature changed and output is byte-identical, verified by golden-output tests over every annotation and tolerance case. Internal only.

A new gate checks that every symbol docs/ documents as current API still exists in Sources/OCCTSwift (#802)

Scripts/check-docs-existence.py closes a gap none of the existing gates covered: during #798, two reference pages showed a live-looking signature for a symbol the same PR had deleted, caught only by a reviewer reading closely. The new gate checks every symbol docs/**/*.md and README.md document against Sources/OCCTSwift, keyed on the exact (owning type, member name) pair so a rename cannot collide with a same-named live symbol elsewhere (Shape.nbEdges, removed, vs. ShapeContentsExtended.nbEdges, live and unrelated). Wired into ci.yml’s gate-scripts job and the optional pre-commit hook alongside the other five gates.

Fixed 18 stale references it found: three sections (Curve3D.ContinuityOrder, Shape.BSplineContinuity, Surface.Continuity) still described a removed typealias as a live deprecated alias; Document-OCAF-Attributes.md’s whole TDocStd_PathParser section documented a type #784 removed outright (now points at OSDPath); a cookbook guide still called generation merely deprecated rather than removed; and 13 pages (headings and code snippets both) named a method that never existed under that name, unrelated to #784: Curve3D.helix, Shape.fillet, Shape.pipe, Mesh.fromShape/Mesh.from, Curve2D.rectangle/Curve2D.arc, Shape.makeFace/makePolygon, and Exporter.writeGLB/exportDXF.

Also corrected docs/reference/FeatureRecognition.md’s detectPocketsAAG() and detectHoles() sections, both of which still described their pre-#762/#747 criteria in full rather than the current mechanism.

61 deprecated symbols plus one bridge deprecation, adjudicated and removed (#784)

Every @available(*, deprecated) symbol in Sources/OCCTSwift (61) and the one __attribute__((deprecated)) bridge symbol (OCCTFacesAreAdjacent) were adjudicated one at a time and removed. None had a live caller anywhere in Sources/OCCTSwift or Sources/OCCTBridge, measured via swift build --build-tests’s own deprecation warnings, all 45 of which landed in Tests/ or Scripts/repro/censuses/, none in Sources/. See the SemVer impact section below for the full list of removed symbols and their replacements, and Scripts/repro/784-deprecations/adjudication.md for the row-by-row evidence.

Investigated OCCTFacesAreAdjacent specifically for the “replacement is worse” case: its replacement, adopted by its only caller since #783, costs a full walk of the face pair where the original stopped at the first shared edge, but that caller already needs the full walk for other reasons, so the cost is paid regardless of which function is called, and no other caller wanting pure adjacency exists. Removed under the same OCCTBridge-orphan precedent as #506/#651.

Tests/OCCTThreadTests/Issue254BuildModesTests.swift (#254) is kept, not deleted, and its surviving test renamed to autoMatchesDirect(). Its old allModesAreDirect() asserted three things: that a direct build is a smooth low-face helix (fDirect < 40, against the faceted cut’s roughly 893 faces), that .auto resolves to .direct for a single start (fAuto == fDirect), and that the now -removed .boolean matched .direct too (fBool == fDirect). Only the third concerned the removed case; the first two are the substance of #254 and were about surviving API. Deleting the whole file, as this PR first did, would have dropped coverage nothing else in the tree provides: Issue189ThreadGuardTests.swift, the only other file mentioning ThreadBuild, covers thread building and worm-pitch rejection, not this equivalence. The .boolean shaft, its helper, the third expectation, and the .boolean-only booleanIsInEnvelope() test (whose remaining claim, that the direct build’s crest is in-envelope, is already covered by Issue222EnvelopeTests.swift) are removed; the two surviving assertions are not.

README.md/docs/API_REFERENCE.md totals re-derived via count-operations.py --fix (4,306 to 4,254): not every removed symbol counted as a wrapped operation under that script’s rule (typealiases and an enum case do not).

#784 duplication rescan: a committed census artifact, six issues filed, no source changes

Added Scripts/repro/784-duplication-rescan/detect-duplicate-logic.py, a re-runnable k-token-shingle clone detector over the bridge’s C functions and the Swift API’s funcs, built to answer whether Pass 1a/1b (#380/#381) missed more of the duplication shape six accidentally-found instances revealed on 2026-08-07. It found 38 bridge and 21 Swift candidate pairs at its tuned thresholds; 6 issues (#791-#796) were filed from what measured as genuine, none fixed in this PR. No public API changed.

OCCTConvertSphereToBSplineSurface/OCCTConvertCircleToBSpline2D now share their siblings’ array-building helper (#791)

Internal-only bridge refactor, found by the #784 duplication rescan (PR #797). OCCTConvertSphereToBSplineSurface and OCCTConvertCircleToBSpline2D each reimplemented the pole/weight/knot-array-building sequence a shared helper (buildSurfaceFromElementary/ buildCurve2DFromConic) already provides and their Cylinder/Cone/Torus and Ellipse/Hyperbola/Parabola siblings already call, because both entry points predate the helpers’ extraction. Convert_SphereToBSplineSurface/Convert_CircleToBSplineCurve both genuinely inherit the base class each helper is typed on (verified against the bundled OCCT headers), so both are now drop-in calls to the shared helper. Same signature, same OCCT calls, same output for every input tested (exact-equality baseline captured from the pre-change implementation, plus a geometric-invariant check independent of the implementation), non-breaking.

Kernel pin moved to v2.0.0-kernel.2, carrying all fourteen patches (#512)

• Pinned v2.0.0-kernel.2, which carries all fourteen patches in Scripts/patches/. The previous pin held eleven, leaving the ChFi2d_Builder::AddChamfer (#705), GeomTools null-handle (#643) and Extrema_ExtCC bounds (#636) fixes untested by any CI job. (#512)

detectPocketsAAG() no longer double-counts a single pocket’s floor; its floor/wall match survives meshing and is now caller-configurable (#724, #733)

A single blind cylindrical pocket reported two pockets instead of one:

let box  = Shape.box(origin: SIMD3(-10, -10, -10), width: 20, height: 20, depth: 20)!
let tool = Shape.cylinder(at: .zero, direction: SIMD3(0, 0, 1), radius: 4, height: 20)!
let cut  = box.subtracting(tool)!
print(cut.detectPocketsAAG().count)   // was 2, now 1

Ground truth for this solid, from OCCT’s own classifier ChFi3d::DefineConnectType: 13 convex edges, 1 concave (the bore’s floor meeting its cylindrical wall), 1 tangential (the cylinder’s own seam). One concave edge joining a wall to a floor is one pocket.

This was a grouping defect, not a classification one, and is independent of #703 (the face1/face2 order fix) and of #723 (the separate replacement of OCCTEdgeGetConvexity’s formula with ChFi3d::DefineConnectType): AAG.detectPockets() selected a floor candidate on isUpward && isHorizontal && isPlanar plus at least one concave, vertical neighbor, with no check that the neighbor was actually resting on that floor rather than merely touching it somewhere along its height. A curved wall’s rim, where it meets the exterior surface it opens through, can classify concave under the convexity formula even after #703’s fix, since that fix addressed a planar/planar order-dependence and left a planar/cylindrical pair’s classification unchanged. The box’s own top face satisfies the floor predicate exactly as well as the real floor does, and once its rim edge to the bore’s wall is (wrongly) concave, it is indistinguishable from a second, shallower floor sharing the same wall.

Fixed: a wall only counts toward a given floor candidate if the wall’s own bounding-box minimum Z matches that floor’s Z, within a tolerance (AAG.defaultFloorRestsOnWallTolerance, 1e-4) far tighter than any real pocket depth and far looser than bounding-box noise on an exact primitive. A pocket floor is upward-facing, so it is always the low end of the walls that rise from it; a wall’s high end is where it opens, whether to the exterior, to a shallower pocket’s floor, or to open air, never to a floor of its own. This holds regardless of whether the wall’s rim classified concave for a legitimate reason or a wrong one, so the fix does not depend on #723 and did not need revisiting when it landed.

Two further fixes, both from this PR’s own review:

• The Z-match compared against Face.bounds, which BRepBndLib::Add enlarges by the mesh’s deflection once a shape has been meshed. Measured on the fixture above: at the mesh library’s own default deflection (0.1), a meshed shape’s wall bound drifted ~290x past the tolerance, and every deflection tried (0.001-5.0) exceeded it, dropping the pocket outright once the shape had been meshed at all before calling detectPocketsAAG(). A planar-walled pocket never drifted (a plane triangulates without curvature error), which is why the fix above’s own fixtures didn’t catch it. Fixed with a new internal Face.exactBounds (backed by a new bridge entry point, OCCTFaceGetBoundsExact, BRepBndLib::Add(..., useTriangulation: false)), used only inside AAG; Face.bounds itself is unchanged for every other caller.
• The tolerance was a hardcoded private static let, the only non-configurable tolerance anywhere in this module (every other tolerance, 296 of them, is a caller-supplied parameter with a default). Promoted to a tolerance: parameter on both AAG.detectPockets(tolerance:) and Shape.detectPocketsAAG(tolerance:), defaulting to the same 1e-4 (AAG.defaultFloorRestsOnWallTolerance, now public). Existing call sites are unaffected.

Migration note: detectPocketsAAG()/AAG.detectPockets() can now report fewer pockets, and a PocketFeature.wallFaceIndices can now be shorter, for any shape where a wall’s rim classified concave without the wall actually bottoming out at that candidate floor. A genuine multi-wall pocket, where every wall shares the same floor Z, is unaffected: measured on the existing square-pocket fixtures (Issue703EdgeConvexityOrderTests, Shape.detectPocketsAAG()’s own doc example), the pocket count and each wall count are unchanged, meshed or not. One known limitation, not exercised by any fixture in this codebase: a filleted floor/wall junction would round the wall’s bounding box past the floor’s own Z by roughly the fillet radius, which could exceed the default tolerance; pass a larger tolerance: for that case.

Tests: Tests/OCCTModelingTests/Issue724PocketGroupingFloorTests.swift, Tests/OCCTModelingTests/Issue733MeshTriangulationBoundsTests.swift (both new).

Surface.joinBezierPatches rejects rational patches instead of silently dropping their weights (#725)

GeomConvert_CompBezierSurfacesToBSplineSurface has no rational path: its own precondition against rational input is a Standard_NotImplemented_Raise_if that this project’s Release kernel compiles out via No_Exception, so a rational Bezier patch used to convert to the polynomial surface through the same control net and report success. Measured on a rational quarter-cylinder patch: a 0.606602 radius error reported as IsDone() == true. joinBezierPatches now rejects any patch that is rational in either direction before constructing the converter, using the same IsURational() || IsVRational() predicate the compiled-out guard used. Weights are never clamped or silently dropped.

Shape.geomFillSweep rejects a fit that misses its own tolerance instead of reporting it as done (#597)

GeomFill_Sweep::Build’s general path always fits the swept surface with an internal approximation and records the achieved deviation in ErrorOnSurface(); IsDone() alone says only that some surface was produced, not that it met the tolerance the fit was built at. geomFillSweep used to accept whatever Build() returned without ever reading that number. Measured: a rapidly oscillating spine can report IsDone() == true with ErrorOnSurface() == 13.0, five orders of magnitude past the 1e-4 tolerance the fit was built at. Now rejects a fit whose reported error exceeds that tolerance. Two upstream kernel sites the wider issue also names (GeomFill_Sweep.cxx’s ForceApproxC1 branch, ShapeUpgrade_UnifySameDomain.cxx) are not reachable from this bridge file and remain open; see #597 for the measurement.

Surface.networkSurface now succeeds on well-formed curve networks (#689)

networkSurface used to fail every network tried, including the simplest possible 2x2 bilinear patch of straight lines, a network with nothing to approximate at all. The cause was not the intersection grid: it was that the locator parameters handed to the underlying GeomFill_NetworkSurface builder were a caller-invented [0,1] fraction rather than each curve’s own raw parameter in the other family’s domain, which the builder requires to match before it will align its internal profile, guide, and reference skins to one knot basis. Fixed by finding each profile/guide pair’s real contact point and parameter via GeomAPI_ExtremaCurveCurve (the same class GeomFill_Gordon’s own internal network preparation uses) and averaging across the family. networkSurface now builds well-formed networks, including a network of genuinely rational profile curves, matching their reference geometry to within floating-point precision; it does not replicate GeomFill_Gordon’s full curve-reordering and reparametrization pipeline, so a scrambled or genuinely misaligned network can still decline. This new call site of GeomAPI_ExtremaCurveCurve is guarded against the parallel-curve SIGSEGV #636 found in the same class, since that fix (PR #730) is scoped to a different file and does not cover it.

Review-response follow-up (same PR, second pass): the contact-point loop above picked GeomAPI_ExtremaCurveCurve’s solution index 1 unconditionally instead of its nearest extremum, and substituted a fabricated placeholder point (each curve’s own FirstParameter()) for a parallel/no-extremum pair, silently averaging it into an otherwise-real result. Both fixed: the nearest-extremum accessors are used instead of index 1, and a pair with no real contact now rejects the whole network as .invalidInput rather than fabricating one. Separately, verifying a docs claim about this same function surfaced a distinct, unrelated kernel defect in GeomFill_NetworkSurface itself (two of four corners of the built surface can be wrong even when .done is reported); filed as #748, not fixed in this PR.

Shape.divided(at:) and dividedByContinuity(criterion:tolerance:) unified onto one entry point (#438)

Shape exposed ShapeUpgrade_ShapeDivideContinuity through two public entry points that set different criteria on the same builder: divided(at:) set boundary, pcurve AND surface criteria together, matching OCCT’s own shape-healing guide; dividedByContinuity(criterion:tolerance:) set only the boundary criterion, leaving pcurve/surface pinned at the class’s own C1 default regardless of the requested continuity. Measured (Scripts/repro/cluster-d-continuity) as a flat result across every criterion on a fixture where divided(at:)’s own behaviour varies (nil/4/4/25 faces at C0/C1/C2/C3).

divided(at:) is now divided(at:tolerance:), taking ContinuityLevel (the strict superset dividedByContinuity alone used to reach) and a tolerance parameter (default 1e-7, matching this method’s prior implicit behavior). dividedByContinuity(criterion:tolerance:) is deprecated and forwards to it. One behaviour change for existing dividedByContinuity callers: .c0 now returns nil rather than a spurious non-nil result, matching divided(at:)’s own .c0 answer, because the pcurve/surface criteria are now genuinely applied instead of silently ignored.

Shape.vinertGK(...) reports a real integration error; VinertGKResult.absoluteError removed (#732)

OCCTBRepGPropVinertGK hardcoded result.errorReached to 0.0 on every call. The comment explaining it (“GetErrorReached is inline-only in OCCT 8.0.0”) had the conclusion backwards: an inline accessor is callable precisely because the compiler emits its body into the caller, which is why nm finds no exported symbol for it. Fixed by calling BRepGProp_VinertGK::GetErrorReached() directly; measured on a radius-10 sphere, it now tracks the requested tolerance across six orders of magnitude (8.09e-4 at 1e-3, down to 1.14e-9 at 1e-9) instead of reporting 0 at every one.

VinertGKResult.absoluteError is removed rather than given a second real value. BRepGProp_VinertGK does declare a second accessor, GetAbsolutError(), but it has no definition anywhere in the OCCT 8.0.1 sources: calling it fails at link time (symbol(s) not found, confirmed by compiling against it). Deriving one from errorReached * mass recovers the source’s internal absolute value in the common case, but not in OCCT’s own near-zero-mass branch, where the un-normalized value is kept as-is rather than divided, so that derivation would go quietly wrong exactly where a caller most needs a reliable number.

errorReached itself is also documented more precisely now: it is a relative fraction of mass only when |mass| clears an internal floor; below it, OCCT returns the undivided residual as-is instead, with nothing in the return value distinguishing which happened. See the doc comment on VinertGKResult and the review response below for the full investigation.

Curve3D.extrema(with:) no longer crashes the process on parallel curves (#636)

Found while building a fixture for #622: a parallel-curve fixture for extrema(with:) crashed the process outright, unrelated to the count bound #622 was about. CLAUDE.md’s Known OCCT Bugs already documents the topological sibling (BRepExtrema_ExtCC crashes on parallel edges, guarded with isParallel); OCCTCurve3DExtrema (OCCTBridge_Curve3D.mm), reached from the Swift API by a different bridge path through GeomAPI_ExtremaCurveCurve, had no equivalent guard.

Root cause, confirmed against the pinned V8_0_1 source before touching anything: GeomAPI_ExtremaCurveCurve wraps Extrema_ExtCC. On parallel curves, Extrema_ExtCC::PrepareParallelResult reports exactly one “extremum” by appending a distance to its private mySqDist sequence, but several of its branches (an unbounded pair, or a bounded pair whose projected ranges overlap, where a whole span is equidistant rather than one discrete closest point) never append the matching pair to mypoints. NbExtrema() reports 1 (mySqDist.Length()), so Points() indexes an empty NCollection_Sequence. This project’s OCCT is built with BUILD_RELEASE_DISABLE_EXCEPTIONS=ON (No_Exception), so the bounds check that would normally throw Standard_OutOfRange compiles to nothing: the out-of-range access is undefined behaviour, confirmed via a standalone binary linked directly against libOCCT-macos.a to be a genuine SIGSEGV, not a C++ exception. A catch (...) around the call cannot help: an OS signal never reaches it.

Measured against two fixtures, both crashing before the fix and both built from real Curve3D factory methods: two unbounded parallel Geom_Lines (Curve3D.line(through:direction:)), and two bounded parallel segments with overlapping projected ranges (Curve3D.segment(from:to:), the exact fixture shape Issue622AllocationBoundsTests deliberately avoided making parallel, per its own comment).

Fixed: OCCTCurve3DExtrema now queries IsParallel() and returns empty before touching any solution, mirroring the guard already in place for the sibling Extrema_ExtCC/Extrema_ExtCS entry points in the same file (OCCTExtremaExtCC/OCCTExtremaExtCS). OCCTCurve3DMinDistanceToCurve (Curve3D.minDistance(to:)), which shares the same GeomAPI_ExtremaCurveCurve construction, needed no change: it only calls LowerDistance(), which reads mySqDist, populated correctly in every parallel branch, and never touches the empty mypoints. Measured, not assumed: it already reported the correct offset distance for both parallel fixtures before this fix.

Audited the rest of the bridge for the same shape (every GeomAPI_ExtremaCurveCurve, Extrema_ExtCC/Extrema_ExtCS, and BRepExtrema_ExtCC call site): OCCTCurve3DExtrema was the only unguarded one. OCCTBridge_Geom2d.mm’s OCCTCurve2DAllExtrema (Geom2dAPI_ExtremaCurveCurve) has the identical unguarded .Points() call and is very likely the 2D sibling of this same defect, but that file is outside this PR’s scope; noted here as a follow-up rather than fixed.

Issue636ExtremaParallelCurvesTests (Tests/OCCTCurveTests), 4 tests. Since this is an uncatchable OS-signal crash, an in-process test cannot observe “before” without taking the whole test runner down with it: the defect and the fix were instead proven out-of-process first, via a temporary probe in Sources/OCCTTest/main.swift (restored byte-identical afterward) run as swift run OCCTTest. With the guard removed: SIGSEGV (exit 139). With the guard restored: clean exit reporting the expected empty result. The permanent, safe-to-run-in-process regression tests landed only once both were confirmed.

Bridge and Swift only: no kernel patch, no OCCT.xcframework rebuild.

Prepared the upstream kernel fix for Extrema_ExtCC::Points() on parallel curves (#636)

Extrema_ExtCC::NbExt() counts mySqDist; Extrema_ExtCC::Points() reads a different container, mypoints, but bounds-checked the request against NbExt(). Several branches of PrepareParallelResult leave a distance in mySqDist with no matching pair in mypoints (a genuinely parallel curve pair has no unique closest point, only a distance), so NbExt() reported 1 in exactly the cases Points(1) indexed an empty sequence — a SIGSEGV under this project’s No_Exception Release build, already mitigated bridge-side in PR #730. Scripts/patches/0024-* bounds Points() against mypoints.Length() instead, validated via override-link against the pinned kernel (not a full rebuild): the crash becomes a catchable Standard_OutOfRange, and the two non-crashing fixtures are byte-identical before and after. Includes a companion, behavior-neutral IsParallel() forwarder on Geom2dAPI_ExtremaCurveCurve, closing an ergonomic (not crash) gap between the 2D and 3D wrappers. Upstream issue/PR text drafted, not filed. See Scripts/repro/636-extrema-parallel/.

Verified the status of ten open upstream OCCT PRs and assessed patch 0020 for filing (#657)

Re-verified all ten upstream OCCT PRs behind our pre-8.0.1-base carried patches (0010-0012, 0014-0021) against the GitHub API rather than trusting recorded status: all ten remain open with green CI, none needs a conflict-resolving rebase (each patch still applies to current upstream master with zero rejected hunks), and the belief that OCCT#1399 (patch 0016) still needed its Storage_Schema fix updated to match maintainer review was already stale, that update shipped three days before it was recorded. Flagged OCCT#1417 and OCCT#1418 as carrying unanswered maintainer feedback. Confirmed carried patch 0020 (BRepFeat_MakeCylindricalHole part selection, #532), still unfiled upstream, is ready to submit: still applies, its reproducer runs and matches its documented post-fix measurements, and it needs no reformatting against OCCT’s own .clang-format. Drafted the upstream PR text; no upstream issue, PR, comment or push was made. See Scripts/repro/657-upstream-pr-status/.

detectPocketsAAG() now finds a pocket whose floor/wall junction is filleted or chamfered (#762)

A fillet at a pocket’s floor/wall junction is tangent to both surfaces (ChFi3d::DefineConnectType reports .smooth at both new edges by construction), so concaveNeighbors(of:) found nothing and the pocket was invisible. A chamfer’s two new edges classify .concave correctly, but the chamfer face is planar at an intermediate angle and fails the wall’s own isVertical filter, so the search never continued past it. Since nearly every real machined pocket has a filleted floor/wall junction, this was non-detection of the pockets anyone would actually cut, not an edge case.

Fixed by tracing outward from the floor through any absorbed junction face, a chamfer via its own correct .concave classification, a fillet via a new radially-inward curvature test, until a genuine wall is reached. Ground-truthed against ChFi3d::DefineConnectType directly first (Scripts/repro/762-filleted-pocket-detection/), including false-positive guards for a filleted through-slot (must stay open), a filleted boss (must never report a false enclosed pocket), and a plain box with its own exterior edges filleted (must report no pocket at all).

let box = Shape.box(width: 20, height: 20, depth: 20)!
let pocketTool = Shape.box(origin: SIMD3(-5, -5, 0), width: 10, height: 10, depth: 15)!
let cut = box.subtracting(pocketTool)!
let junctionEdges = cut.edges(where: { abs($0.bounds.min.z) < 1e-6 && abs($0.bounds.max.z) < 1e-6 })
let filleted = cut.filleted(edges: junctionEdges, radius: 1.0)!
print(filleted.detectPocketsAAG().count)   // 1, was 0

detectHoles() was checked against the same blindness and found unaffected (see above); no change made there.

Carried patch 0020 (#532, BRepFeat_MakeCylindricalHole tool part selection) is now filed upstream as OCCT#1447

Re-verified the defect directly against current upstream master before filing: the four affected call sites, the two correct callers in the same builder, and the second, unfixed defect in the same heuristic are all unchanged from the V8_0_0_p1-based measurement this patch was originally built against, and the touched file is byte-identical between master and our pin. Confirmed by compiling BRepFeat_MakeCylindricalHole.cxx from master as an override translation unit, once unmodified and once patched, and running the existing reproducer against both: every “before” and “after” figure in the original writeup reproduces exactly, including the oversized-radius status change. Filed as Open-Cascade-SAS/OCCT#1447, PR only per okf/policies/upstream-occt-style.md. No change to OCCTSwift’s own behavior or public API.

Dead BisectorPoint/OCCTBisectorPointOnBis bisector-point value type removed (#771)

BisectorPoint (Swift), and the OCCTBisectorPointOnBis bridge struct and OCCTBisectorPointOnBisCreate function it wrapped, are removed. Found while teaching Scripts/census-unmeasured-values.py a third sub-kind (a boolean gate flag assigned false somewhere and true nowhere): OCCTBisectorPointOnBisCreate never called into OCCT’s Bisector_PointOnBis and had no Swift call site, and BisectorPoint had no public initializer and no constructor call site anywhere in the package. Both sides were fully dead code, not a stuck gate on a live path. BisectorIntersection and bisectorIntersections(a:b:c:d:), the live bisector API in the same file, are unaffected.

// Before: an unconstructable public type (no public init, no factory anywhere)
// public struct BisectorPoint { ... } // removed

// After: use bisectorIntersections(a:b:c:d:) for bisector work; there is nothing to migrate a
// BisectorPoint value to, since nothing could ever have produced one.

Shape.analyze(tolerance:) can now check self-intersection (opt-in) (#772)

analyze(tolerance:selfIntersectionTimeout:) gains one new parameter, selfIntersectionTimeout: Double? = nil. nil (the default) skips the self-intersection check entirely; a non-nil value opts in, forwarded as the timeout: to isSelfIntersecting(timeout:) (the same BOPAlgo_ArgumentAnalyzer check isSelfIntersecting uses), and populates the new ShapeAnalysisResult.hasSelfIntersection: Bool? field: nil when not requested, or requested but indeterminate; true/false when the check resolved. totalProblems adds a flat +1 when hasSelfIntersection == true, matching how hasInvalidTopology is counted.

Passing a non-nil selfIntersectionTimeout makes this call block the calling thread for up to that many seconds (more, if OCCT never reaches a checkpoint to poll); do not pass it from a UI/main thread without accepting that stall.

Measured before deciding (Scripts/repro/772-analyze-self-intersection/): the check costs 1x-2x the rest of analyze()’s scan on ordinary shapes but ~3500x-4200x on a known pathological artifact (a few ms vs 30+ seconds), so it defaults off rather than running unconditionally.

// Default stays cheap; self-intersection is not reported unless asked for.
let analysis = shape.analyze(tolerance: 0.001)
print(analysis?.hasSelfIntersection)   // nil

// Opt into the expensive, thread-blocking check when it's actually needed.
let checked = shape.analyze(tolerance: 0.001, selfIntersectionTimeout: 30)
switch checked?.hasSelfIntersection {
case .some(true):  print("self-intersects")
case .some(false): print("clean")
case nil:          print("indeterminate or not requested")
}

ShapeAnalysisResult.selfIntersectionCount removed; ShapeAxis.extent now computed for revolutionAxes()/symmetryAxes() (#763)

ShapeAnalysisResult.selfIntersectionCount is removed. It was always 0, never computed (the bridge’s own comment admitted “would require more expensive computation”). Use Shape.isSelfIntersecting(timeout:) for a real self-intersection check.

ShapeAxis.extent (from Shape.revolutionAxes(tolerance:) and Shape.symmetryAxes(fractionalTolerance:)) is now genuinely computed rather than always nil: it reports the axis’s own shape’s bounding box projected onto the axis direction, in real 3D units. Face.primaryAxis is unaffected and still never populates extent.

// Before: always nil
let axis = Shape.cylinder(radius: 5, height: 20)!.revolutionAxes().first
axis?.extent  // nil, always, regardless of the cylinder's actual height

// After: a real measured extent
axis?.extent  // Optional(0.0...20.0), or -20.0...0.0 since the axis direction sign varies

• Pinned v2.0.0-kernel.3, adding patch 0025 (GeomFill_Sweep conversion error, #597) and the revised 0018 (GCPnts, #555) after upstream review. (#512)

Document.shapeColor/setShapeColor now round-trip alpha correctly (#763)

Document.shapeColor(_:type:) previously always reported alpha == 1.0 regardless of what was actually stored, because the bridge read a shape’s color through XCAFDoc_ColorTool’s RGB-only GetColor overload. It now reads the RGBA overload and reports the real value, for example a STEP import with a transparent surface style. Document.setShapeColor(_:color:type:) previously silently dropped color.alpha on write; it is now stored and round-trips through shapeColor.

AAG.detectHoles() no longer reports zero holes for an ordinary blind or through cylindrical hole (#747)

detectHoles() required every neighbor of a candidate face to connect via a concave edge, a criterion written against the convexity formula #723 replaced, and unsatisfiable under the correct one for both a through-hole (zero concave neighbors) and a blind hole (one out of two). Replaced with a criterion built from the wall’s own geometry: cylindrical or conical, closed in U by its own seam, and with material lying radially outside the wall rather than inside it, which also correctly excludes a boss or standalone cylinder (topologically identical to a hole in every way neighbor convexity can see) and correctly finds a hole bored on any axis, not only a vertical one.

let box  = Shape.box(origin: SIMD3(-10, -10, -10), width: 20, height: 20, depth: 20)!
let tool = Shape.cylinder(at: .zero, direction: SIMD3(0, 0, 1), radius: 4, height: 20)!
let cut  = box.subtracting(tool)!
print(cut.buildAAG().detectHoles().count)   // 1, was 0

PocketFeature.isOpen tests enclosure per edge, not by wall count or by summing shared-edge counts (#735)

isOpen was wallIndices.count < 3, a proxy that does not mean enclosure: a blind cylindrical pocket has exactly one wall and is fully enclosed, so it reported isOpen == true, and a genuinely open three-sided slot and a closed three-walled pocket both have exactly 3 walls and were indistinguishable by counting alone.

Fixed to test enclosure directly and per edge: for each edge of the floor’s own outer wire, ask which faces border it in the shape and check whether one of them is a member of wallFaceIndices, by structural identity rather than by summing a shared-edge count. This closes two review findings on an earlier version of the fix that compared counts instead: a boss standing on the pocket floor could mask a genuine gap in the outer wall loop (the count included the boss’s own inner-wire edge alongside the outer boundary’s), and the underlying shared-edge count is separately capped by a fixed-size bridge buffer. Neither can occur with the per-edge test, since it never sums a total and never visits an inner-wire edge.

GeomFill_Sweep reports the achieved conversion error, not the tolerance that was requested (#597)

Carried kernel patch 0025. When BRepOffsetAPI_MakePipeShell and its callers force C1 continuity and the swept surface is not already C1 in V, GeomFill_Sweep::BuildAll re-approximates through GeomConvert_ApproxSurface and then overwrote the measured surface error with the tolerance the caller asked for. Every consumer of ErrorOnSurface() on that path was therefore reading its own request back. Measured on a helical sweep: 0.0001 reported against a real 2.54714.

Diagnostic only. The returned geometry is byte-identical before and after, confirmed by override-linking the patched translation unit against the pinned archive, and no bridge site gates on the value today.

kernel-integration.yml no longer discards a successful 79-minute build on timeout (#727)

The workflow’s trigger paths (Scripts/patches/**, Scripts/build-occt.sh) and its xcframework cache key (hashFiles of those same two globs) were the same condition, so every run the workflow exists to do was, by construction, a first-time cache miss: there was no run where the ~79-minute build could be skipped. With build and swift test as one job, actions/cache’s save runs as an automatic post step queued for the end of the job; a job cancelled by its own timeout-minutes partway through swift test never reaches that post step, so it reports skipped, not cancelled, discarding a build that had already finished successfully one step earlier. Measured on PR #718’s job 92538270414: 79 min to build OCCT (success), 10 min into swift test before the 90-minute job timeout fired (cancelled), cache save skipped. Retrying reruns the same build and times out at the same place, so there was no path to green by re-running.

Split into two jobs: build-kernel builds and caches Libraries/OCCT.xcframework (timeout-minutes: 120, roughly 50% margin over the measured 79 min), and swift-test (needs: build-kernel, timeout-minutes: 30) restores that cache and runs swift test against it. The build job now has nothing left to run after the build, so its cache save is no longer hostage to the test job’s runtime, and each job’s timeout matches what it actually does instead of both sharing one 90-minute budget. The xcframework reaches the second job only through actions/cache, never actions/upload-artifact: the two jobs compute the same cache key independently (hashFiles of the same commit each checks out), rather than passing it as a job output.

The build job’s own cache handling also moved from the combined actions/cache action to explicit actions/cache/restore plus actions/cache/save (the latter if: always()), placed immediately after the build step instead of left as an automatic post step. Splitting the job already closes the main gap; this closes a narrower, related one the split does not: this workflow’s own concurrency.cancel-in-progress cancels the whole in-progress run, both jobs, if a new commit lands on the same ref while the build is still going, and an if: always() step still gets a chance to run after that cancellation signal, unlike a not-yet-started automatic post step.

Verified: the two-job workflow parses and its workflow_dispatch trigger is reachable. Not verified in this change: a real cache-miss run start to finish, the ~80-minute cost this fix exists to stop wasting, had not completed by the time the PR was opened. See the PR description for exactly what ran and what remained outstanding.

Surface.appSurf(curves:) rejects fewer than 2 curves instead of crashing; two sibling GeomFill_* null-handle guards (#644, #710)

Two independent, uncatchable SIGSEGVs in OCCTGeomFillAppSurf (OCCTBridge_Surface.mm) and its two sibling bridge functions, both migration notes since neither can be a docs/SEMVER.md recorded exception – that mechanism is for breaks within a major line, and both land in the still-unreleased v2.0.0.

#644: Surface.appSurf(curves:) SIGSEGVed on 0 or 1 curves; 2+ already returned isDone: true cleanly. Not the unguarded (double)i / (double)(count - 1) divisor the issue’s own investigation had already disproved – substituting a guarded 0.0 there still crashed. The real mechanism: GeomFill_AppSurf’s approximation solver (AppDef_Compute, reached through AppBlend_AppSurf::InternalPerform) is never driven with fewer than 2 sections anywhere in the kernel; at 1 section the first and last constraint point are the same section evaluated twice, and the solver’s degree-of-freedom bookkeeping – built assuming at least one free interior span – segfaults. Measured via a forked ground-truth probe against the pinned kernel and, separately, a temporarily-repointed Sources/OCCTTest/main.swift run as a standalone process (an in-process @Test cannot assert a SIGSEGV without killing the whole suite): counts of 0 and 1 both SIGSEGV (exit 139), 2 and 3 both return cleanly (exit 0), before and after.

Surface.appSurf(curves:) was the one function in this family missing the guard, not a new gap: Surface.nSections(curves:params:) and Surface.generatedFromSections(curves:tolerance:) already carry a curves.count >= 2 guard at the same Swift boundary. appSurf now matches them exactly: guard curves.count >= 2 else { return nil }.

#710: found building #666’s Cluster C census, OCCTBridge_Surface.mm has nine sites reaching a Handle(Geom_Curve) through *(const Handle(Geom_Curve)*)curveRef – a fifth alias form Scripts/check-null-handle-guards.py cannot see even after #711 taught it the #656 shape. Six wrap the result immediately in GeomAdaptor_Curve, which raises a catchable Standard_Failure on a null Handle, already absorbed by each function’s own catch (...). Three do not, and each SIGSEGVs uncatchably on a null Handle(Geom_Curve):

• OCCTGeomFillProfilerAddCurve (GeomFill_Profiler::AddCurve – CurveProfiler.addCurve(_:))
• OCCTGeomFillAppSurf’s own curveRefs loop (the same non-virtual GeomFill_Profiler::AddCurve, inherited by GeomFill_SectionGenerator)
• OCCTGeomFillSectionPlacement’s sectionCurve argument (GeomFill_SectionPlacement ctor – its pathCurve argument is already safe, wrapped in GeomAdaptor_Curve first)

Each gets if (<curve>.IsNull()) return <fallback>; immediately after binding the alias. The three guarded aliases (curveRef’s curve in OCCTGeomFillProfilerAddCurve, curveRefs[i]’s curve in OCCTGeomFillAppSurf’s loop, sectionCurveRef’s sectionCurve in OCCTGeomFillSectionPlacement) are bound through ->curve field access rather than the file’s *(const Handle(Geom_Curve)*)ref cast form, so check-null-handle-guards.py’s already-recognised “handle alias” pattern sees them: removing any one of the three guards is now a CI failure, confirmed by injection: remove, checker reports the site, restore, checker is clean again (for all three). pathCurve in OCCTGeomFillSectionPlacement and the six pre-existing GeomAdaptor_Curve-wrapped sites keep the cast form, unchanged: pathCurve needs no guard (GeomAdaptor_Curve copes), and ALLOWED has no per-argument granularity, so exempting OCCTGeomFillSectionPlacement by name to cover pathCurve would also blind the checker to the sectionCurve guard this fix depends on. Teaching the checker the cast form itself as a general fifth alias shape remains the separate, deferred follow-up work described below and in the repro README; this is a narrower, in-place idiom swap at exactly the three sites this fix already touches, not that census.

Reachability, measured rather than assumed. #710’s own filing said CurveProfiler “has … no public factory anywhere,” concluding its guard was latent. That premise was wrong: CurveProfiler.create() is public and has been since the type was first wrapped (already exercised by GeomFillProfilerTests) – the “inaccessible” compiler error the filing hit was from calling the internal init(handle:) directly, the same internal/public-factory split every geometry wrapper in this codebase uses. All three sites are equally reachable in that respect.

The harder question – can any public factory produce a Curve3D wrapping a null Handle(Geom_Curve) to drive the crashing input through – was answered by reading every OCCTCurve3D-constructing site across all five bridge files that produce one (~100 sites): every one checks IsNull()/IsDone() first, constructs from a fresh concrete Geom_* object that cannot be null, or copies an already-checked input. No public factory produces one, reconfirming #478’s sweep of the (then) 228 handle-binding sites. All three fixes are therefore defensive hardening against a hazard the current tree cannot trigger through the public Swift API today, not a live crash reachable right now – worth doing anyway, since the guard is a one-line match to established idiom and the invariant is a fact about today’s sites, not a guarantee about the next one. See Scripts/repro/644-710-geomfill-appsurf-null-arity/README.md for the full measurement, including why teaching the checker this alias form is real but separate follow-up work, not part of this fix.

Automated review pass on PR #722. Three of four findings held up and are folded into the fix above (the checker-visibility idiom swap is described there); the fourth was verified and rejected with evidence rather than implemented:

• CurveProfiler.addCurve(_:)’s null-handle drop had no doc comment, unlike sectionPlacement’s sibling entry updated in the same original commit. Added to both the /// comment (CurveProfiler.swift) and docs/reference/Shape-Completions.md, describing the only indirect signal available: a dropped curve shifts every later curveIndex passed to poles(curveIndex:) by one.
• Tests/OCCTSurfaceTests/OCCTSurfaceTests.swift’s pre-existing approximateSurface (in GeomFillAppSurfTests) asserted inside a nested if let, silently skipping on nil: the same blind pattern the new regression tests in this fix deliberately avoid two tests below it. Converted to the same guard ... else { Issue.record(...); return } idiom. Proven by injection: temporarily made appSurf(curves:) always return nil, confirmed approximateSurface now fails (it previously would have passed silently), restored, confirmed green again.
• Rejected: that appSurf’s curves.count >= 2 guard exists only in Swift and the bridge function itself SIGSEGVs if reached directly with count < 2. True, but not a gap this PR introduced: OCCTGeomFillNSections and OCCTGeomFillGenerator, the two sibling bridge functions backing Surface.nSections(curves:params:) and Surface.generatedFromSections, have the identical gap and predate this PR untouched. Adding a bridge-side arity guard to only OCCTGeomFillAppSurf would make it inconsistent with both siblings, not more correct; the Swift-boundary guard is this family’s established, deliberate convention (OCCTBridge is an internal target, not a public product; see #486). The review’s separate observation that no automated gate covers arity the way check-null-handle-guards.py covers null handles is accurate and is left as a genuine, but separate, future census.

OCCTEdgeGetConvexity replaces its hand-rolled formula with OCCT’s own classifier (#723)

#703 (below) fixed the face1/face2 argument-order dependence by replacing a scalar triple product with a formula built from each face’s own area centroid, a GLOBAL property of the face, standing in for a LOCAL one (which side of an edge is material). That residual was filed as #723: the two averaged centroid terms are each a different global measure, so their sum drifts with face proportions. Measured: a round through-hole’s rim classified 2 concave edges at plate thickness 20 but 0 (correctly, by accident) at 40/60/120, because the cylindrical wall’s own centroid moves as the wall gets taller while the rim geometry itself never changes, the same failure class #703 fixed (a geometric answer depending on something that is not the local geometry), re-parameterised.

Fixed by replacing the formula entirely with ChFi3d::DefineConnectType, the classifier the 3D fillet and chamfer builders use themselves to decide which edges they can round or bevel, called with CorrectPoint=true, matching ChFi3d_Builder_1.cxx’s own call. It samples the LOCAL dihedral at the edge midpoint (each face’s normal there, from its pcurve’s D1, against the edge tangent), needs no per-face integration, and reports the identical classification for (face1, face2) and (face2, face1) by construction, so #703’s order-independence requirement holds with no centroid argument needed. ChFiDS_Concave/ChFiDS_Convex map onto the existing OCCTEdgeConvexity enum directly; ChFiDS_Tangential (and the residual ChFiDS_Other/ChFiDS_Mixed/ChFiDS_FreeBound cases this classifier can decline to resolve) map to Smooth, the same “can’t classify this edge” fallback the function has always used. SinTol reuses the previous formula’s smoothThreshold (0.01, ~0.5°) rather than introducing a new tolerance.

let plate = Shape.box(width: 50, height: 50, depth: 20)!
let drill = Shape.cylinder(at: SIMD3(0, 0, -15), direction: SIMD3(0, 0, 1), radius: 10, height: 30)!
let drilled = plate.subtracting(drill)!
print(drilled.buildAAG().edges.filter { $0.convexity == .concave }.count)   // was 2, now 0

Migration note: a hole rim (the edge where a cylindrical/conical wall meets the face it penetrates) now consistently reports .convex, never .concave, independent of wall height/thickness: a hole rim is convex by construction, since the solid occupies the quarter-space below the pierced face and outside the wall, a 90° material angle, not the 270° that makes an edge concave. detectPocketsAAG() no longer reports a through-hole as a 1-wall pocket at any thickness. This ships in v2.0.0, a major version, so it is not recorded as a SEMVER.md exception, since that mechanism is for breaks shipping within a major line.

Dead plumbing removed. #720’s review of #703 added OCCTFaceGetAreaCentroid (a cached BRepGProp::SurfaceProperties centroid, adaptive integration) plus a widened OCCTEdgeGetConvexity signature taking each face’s precomputed centroid, so AAG.buildGraph() could avoid repeating a whole-face integration per adjacent pair. ChFi3d::DefineConnectType needs no centroid at all, so all of that becomes dead: OCCTEdgeGetConvexity drops back to its original four-argument signature (shape, edge, face1, face2), OCCTFaceGetAreaCentroid is removed outright (confirmed to have no other caller before deleting it), and buildGraph()’s centroid-precompute loop is gone.

Performance improves further, it does not regress. #720 measured a 7-12x slowdown from OCCTEdgeGetConvexity recomputing BRepGProp::SurfaceProperties per face-pair, then recovered 2.06x by caching each face’s centroid once per occurrence instead. ChFi3d::DefineConnectType needs no integration at all, just a handful of D1 derivative evaluations per edge, the same order of cost as the pre-#703 tangent-plane formula. Re-measured with the same method (Shape.buildAAG() on a many-faced drilled-plate fixture, three runs per configuration): every post-#723 run was faster than every pre-#723 (cached-centroid) run, by more than 3x at the extremes (min 110ms vs min 354ms on a 262-face/524-pair fixture). See Scripts/repro/703-edge-convexity-order/README.md’s “Update following #723’s fix” for the full numbers and a caveat about a stale-incremental-build artifact hit while measuring.

Fixture bug found and fixed alongside the classifier swap. The through-hole regression test added under #703 pinned its drill’s base at a fixed Z (-5) rather than scaling it with plate thickness, so for every thickness the test actually exercised (20/40/60/120mm) the drill never reached the plate’s own bottom face (Shape.box(width:height:depth:) centers the box, so the plate’s bottom is at -thickness/2, below -5 once thickness > 10), so the fixture was silently a BLIND pocket with a floor fixed at Z=-5 for every tested thickness, not a through-hole at all, independently confirmed via ChFi3d (1 concave edge, matching a blind round pocket exactly, not the 0 a through-hole reports). Fixed by anchoring the drill’s base thickness/2 + 5 below center, so it clears the plate by 5mm on both faces regardless of thickness, matching the fixture’s evident intent.

AAG (Sources/OCCTSwift/FeatureRecognition.swift) is the only Swift caller of OCCTEdgeGetConvexity, re-audited for this fix rather than trusted from #703’s own audit.

Tests: Issue703EdgeConvexityOrderTests’s through-hole case (throughHoleConcaveCountIsPinnedPendingIssue723, an explicitly-labelled characterisation test pinning the old formula’s wrong answer of 2) is rewritten as a real ground-truth test (throughHoleHasNoConcaveEdges, pinning the correct answer of 0), with its fixture bug fixed in the same change. Proved by injection per okf/policies/prove-the-test-fails.md: the rewritten test, run against the pre-#723 formula, fails at three of its four parametrized thicknesses (2 concave edges reported, and a false 1-pocket count, at 20/40/60mm); restoring the ChFi3d fix makes all four pass. The suite’s other tests (plain box, glued boxes, genuine pocket, square pocket) are unaffected, since ChFi3d agrees with the centroid formula everywhere except the through-hole rim.

OCCTEdgeGetConvexity no longer depends on which face is passed first (#703)

Found via Cluster A’s census (#664, Scripts/repro/cluster-a-subshape-enumeration/) while confirming #699’s own fix, then confirmed directly on the simplest possible input: detectPocketsAAG() reported a pocket on a plain, uncut, convex 10mm box.

let box = Shape.box(width: 10, height: 10, depth: 10)!
print(box.detectPocketsAAG().count)   // was 1, now 0

A convex solid has no concave edges and therefore no pockets. OCCTEdgeGetConvexity’s formula, the sign of (tangent × n1) · n2, is a scalar triple product of the edge tangent and the two face normals: swapping which normal is n1 and which is n2 swaps two of its three terms, which negates a triple product. AAG.buildGraph()’s pairwise loop picks face1/face2 by array position (faces[i], faces[j], i < j), not by any geometric convention, so the same physical edge reported opposite convexity depending on face enumeration order rather than on geometry. Two of a plain box’s four side-wall-to-top-face dihedrals were misclassified concave this way, feeding a false pocket. The same mechanism, once per box, explains the 1/2 counts Issue642AAGNodeIdentityTests and Issue699AAGSolidScopedAdjacencyTests used to pin on their split-box fixtures.

Fixed: convexity is a property of an edge with respect to the solid it bounds, not of which face a caller happens to pass first, so the new formula is built to be symmetric under the face1/face2 swap rather than merely observed to be on the fixtures it was checked against. OCCTEdgeGetConvexity now takes each face’s own area centroid (BRepGProp::SurfaceProperties), a point well inside the face and away from the edge, and checks which side of the OTHER face’s tangent plane (at the edge midpoint) that centroid falls on, using that face’s own outward normal: a negative dot product means the two faces wrap around the solid’s material at this edge (convex), a positive one means the material recedes (concave). Doing this both ways, face1’s centroid against face2’s normal and face2’s centroid against face1’s normal, then averaging, makes swapping which face is face1 relabel the same two terms of the sum rather than change it.

Migration note: detectPocketsAAG(), AAG.concaveNeighbors(of:)/convexNeighbors(of:), and any AAGEdge.convexity a caller reads directly can all report a different, now-correct, answer for a shape that previously hit this defect. Measured moves: a plain box’s detectPocketsAAG().count goes from 1 to 0; the split-box fixtures in Issue642AAGNodeIdentityTests and Issue699AAGSolidScopedAdjacencyTests move from 1/1 to 0/0 in both compound member orders (both fixtures are two plain boxes glued face to face, which have no concave edges to begin with); a compound of two disjoint boxes plus a free face moves from 2 to 0. A genuine pocket (real overlap between a box and its cutting tool) is unaffected in kind: detectPocketsAAG() still finds it and still reports concave edges at the floor/wall junction: the fix corrects the sign convention, it does not flatten every edge to convex. This ships in v2.0.0, a major version, so it is not recorded as a SEMVER.md exception, since that mechanism is for breaks shipping within a major line.

AAG (Sources/OCCTSwift/FeatureRecognition.swift) is the only Swift caller of OCCTEdgeGetConvexity, re-audited for this fix rather than trusted from #701’s own earlier audit, so the blast radius is exactly the AAG-derived API surface above and nothing else.

Two long-standing fixtures needed correcting alongside the bridge fix, not because of it: the detectPocketsAAG() doc example in FeatureRecognition.swift and the detectPocket() test in Tests/OCCTModelingTests/OCCTModelingTests.swift both placed their pocket-cutting tool at origin: SIMD3(5, 5, 10) against a box centred at the origin (Shape.box(width:height:depth:) spans -10…10 on a 20mm axis), so the tool’s z range (10…25) only ever touched the box’s top face at z=10 with zero volume in common (measured: result.volume == box.volume, unchanged). The single “pocket” both used to report was entirely this same order-dependence, not a real feature of either shape. Both now place the tool at origin: SIMD3(-5, -5, 0), which actually overlaps the box and cuts a real 10mm-deep pocket.

Tests: Tests/OCCTModelingTests/Issue703EdgeConvexityOrderTests.swift (new), plus updated pins in Issue642AAGNodeIdentityTests and Issue699AAGSolidScopedAdjacencyTests. swift run Censuses cluster-a’s two detectPocketsAAG().count rows move from 1/1/1 to 0/0/0; the census and its README (Scripts/repro/cluster-a-subshape-enumeration/README.md) are updated to match. This is Cluster A’s last open member (#664).

Follow-up from PR #720’s automated review: three real, independently-measured issues in the fix above, addressed without touching the classification formula itself (a formula change is #723’s scope, deliberately deferred):

• Performance (finding 7, confirmed). OCCTEdgeGetConvexity called BRepGProp::SurfaceProperties on face1/face2 directly, so AAG.buildGraph()’s pairwise loop repeated a face’s own whole-face integration once per neighbor. Measured 7-12x slower building the AAG of a 134-face part than the pre-#703 formula (which does no integration at all). Fixed: a new OCCTFaceGetAreaCentroid bridge call lets buildGraph() compute each face occurrence’s centroid once, before the pairwise loop, and pass it into OCCTEdgeGetConvexity (which no longer computes it internally), cutting the redundant-integration half of the regression exactly in half (measured 2.06x, matching the 2.09x the call-count reduction predicts). The remaining gap versus the pre-#703 baseline is the inherent cost of the centroid approach itself, not a caching problem; see Scripts/repro/703-edge-convexity-order/ for the full measurement.
• Sliver-face guard (findings 2 and 9, not reproduced, added defensively). A dedicated probe (Scripts/repro/703-edge-convexity-order/repro_sliver.mm) fusing two boxes with a deliberate sliver overlap found no instability: OCCT’s own boolean tolerance handling does not let a genuinely near-zero-area face survive as its own topological face. OCCTFaceGetAreaCentroid still declines any face under area 1e-9 (several orders below the smallest sliver measured) and reports “no centroid”, which OCCTEdgeGetConvexity treats as Smooth: free, from the finding-7 restructuring, not because a live bug was found.
• Integration accuracy (finding 8, confirmed as a real gap, closed). The plain SurfaceProperties overload has no bounded relative error; OCCTFaceGetAreaCentroid now uses the adaptive-integration overload (Eps = 1e-6, matching Face.area()’s own default), which does.

Two findings were investigated and are not regressions:

• Finding 3 (removing the tangent-magnitude cusp guard). The new formula’s terms are the edge midpoint’s position, the two face normals, and the two face centroids, none of which derive from the edge curve’s own parametric derivative. A cusp in the curve’s parameterization (a vanishing derivative) cannot perturb an answer with no dependence on that derivative; the removed code was dead relative to the new method, not a guard the new method still needed.
• Findings 1 and 4 (the centroid-toward-material assumption failing for holes/curved faces, and smoothThreshold no longer bounding a real angle). Both restate #723, already filed and tracked separately with its own measurement (a through-hole rim’s classification drifting with plate thickness). Every fixture in the PR’s own verification comment shows this PR matching or beating the base branch, never regressing it, including on holed/curved geometry; see Issue703EdgeConvexityOrderTests.throughHoleHasNoConcaveEdges (renamed and rewritten as a ground truth test when #723 landed; see that entry above) / squarePocketHasExactlyEightConcaveEdges (new, finding 6) for regression locks on curved/holed geometry that do NOT depend on #723’s disputed cases.

Finding 5 ((result.volume ?? 0) < (box.volume ?? 0) masking a nil volume computation as 0) is a test-quality fix, not a formula question: both occurrences (OCCTModelingTests.detectPocket() and Issue703EdgeConvexityOrderTests.genuinePocketStillReportsConcaveEdges) now unwrap both volumes and fail loudly if either is nil, matching this suite’s own guard let ..., let v0 = shape.volume else { #expect(Bool(false), ...) } idiom.

plateSurface’s point constraints reject .g2 in Swift instead of relying on OCCT’s own throw (#437)

Cluster D’s continuity census (#513/#667, Scripts/repro/cluster-d-continuity/) measured #437 as a genuine instance of the cluster’s shared root: SurfaceContinuity’s raw value is forwarded as a literal GeomPlate_PointConstraint/GeomPlate_CurveConstraint order, with no GeomAbs_Shape decode step at all. GeomPlate_PointConstraint’s point constructor throws above order 1 (pinned V8_0_1, GeomPlate_PointConstraint.cxx): a bare point carries no curvature to match, so .g2 was always out of domain for a point constraint. GeomPlate_CurveConstraint has no such restriction and accepts order 2 directly, so this is a point-only defect.

Shape.plateSurface(through:orders:...) and the point half of Shape.plateSurface(pointConstraints:curveConstraints:...) clamped the incoming order into [0, 2] and passed it straight to the constructor, which threw, unwound past the whole constraint loop, and was swallowed by the bridge’s blanket catch (...), returning nil with no indication which constraint was at fault.

Rejected at the Swift boundary instead of clamped or split into a new type. Three options were on the table (SurfaceContinuity.g2 documented as unsupported here already, from #436):

• Clamp to [0, 1] in the bridge. Silently substitutes a lower order than the caller asked for, the same class of behaviour #430/#432/#434 deliberately moved away from (“used or the constraint fails, never silently substituted”).
• Give point constraints a narrower type that cannot express curvature. Most precise, but adds a fourth continuity vocabulary right where #398/#490 spent real effort collapsing nine into two, and unlike #619 (which retired a parameter because its name lied about what it took), this would be introducing a new type for a shared enum that is correct everywhere else it is used (Shape.fill, FillingSurface, curve constraints all accept .g2 legitimately).
• Reject in Swift, before building any constraint. Chosen. Keeps the single SurfaceContinuity vocabulary, and makes the nil a deliberate, documented decision instead of an accidental side effect of OCCT happening to throw where our bridge happens to catch.

The public answer does not change: a point .g2 was already nil and stays nil. What changes is that the rejection is now asserted in Swift (SurfaceContinuity.isUnsupportedForPointConstraint, Shape.plateMixedRejectsPointOrders) rather than incidentally produced by relying on OCCT’s internal domain check, and it no longer builds any GeomPlate_PointConstraints before failing. Issue437PlatePointG2Tests has the guard-removal matrix proving which of its own cases exercise the new mechanism and which pin the (unchanged) public contract only, per okf/policies/prove-the-test-fails.md.

Not fixed here: #438, a different, API-duplication-shaped defect in the same file that the census’s own measurement confirmed is unrelated to this one (two public APIs correctly decoding the same continuity through the same canonical decoder, but setting different criteria on the builder).

derive-bridge-header-split.py now verifies each declaration is in the header its .mm owns (#673)

--verify only ever asked whether every declared bridge function maps to exactly one .mm file, which was the whole question before #395 split the header. After that split there is a second question it did not ask: is the declaration actually in the header its .mm owns? A declaration could sit in OCCTBridge_Surface.h while its implementation lived in OCCTBridge_Modeling.mm and --verify would still report clean, because the symbol still maps to exactly one .mm.

The script now tracks declarations per header file, not just concatenated across all sixteen, so it can answer both. A hand check at the time #673 was filed found 0 misfiled of 4022, with 29 apparent duplicates all traced to mentions inside the umbrella’s cross-reference index comment block. Re-measuring rather than trusting that number: 0 misfiled of 4018 today (the drop from 4022 is unrelated churn, not a regression). Comments have to be excluded from the per-header scan for the same reason the hand check found 29 false duplicates: // Class -> OCCTFoo (aside) names a symbol followed immediately by (, the same shape a real declaration has, so an unstripped scan credits whichever header holds the comment with a second declaration of a symbol that is for real declared somewhere else.

Gained a --self-test, the one thing this script’s three siblings already had and it did not. Six cases, each proven by removing the guard it covers and watching the count drop, not merely added and trusted:

Each restored to 6/6 after its own row. The “clean split” row also catches the two comment-guard rows collapsing at once, since all three share the same wrong = home - {expected} computation; the other four guards are each isolated to exactly one row.

Joins ci.yml’s gate-scripts job as the fifth script, run with --verify (its bare form only prints the manifest and always exits 0). Unlike the other two derive-*.py scripts in Scripts/, which are one-time censuses for a split not yet done, this one protects an invariant from a split already shipped (#395) that every ~100-operation release can still violate by hand. The pre-commit hook (Scripts/git-hooks/pre-commit) gains the matching two invocations to stay flag-for-flag identical to CI, and CLAUDE.md’s Static Gate Scripts section, ci.yml’s own header comment, and the hook’s header comment are updated from four/seven to five/nine accordingly. In the same pass, ci.yml’s comment for count-operations.py is corrected: it said the script “ignores an unrecognised” option, which was true only until the same-day commit that made it exit 2 instead (confirmed still correct: count-operations.py --self-test and --bogus both exit 2 with a usage message).

Shape.analyze(tolerance:) reported zero free edges for every shape, and a healed()/fixSolid() demotion had no reliable signal (#702)

Shape.healed() and Shape.fixSolid() can reach isValid == true by demoting a solid to a shell: ShapeFix_Solid (via ShapeFix_Shape’s delegation, for healed()) hands back the shell unpromoted whenever it cannot close it, already correctly documented for fixSolid() since #442. A shell has no closure requirement of its own, so the demoted result is genuinely isValid, and the issue asked for a way to tell.

The issue’s own reproducer does not reproduce on this branch. It measured a ThruSectionsBuilder(isSolid: true, isRuled: false) loft through a 36-tooth bevel gear’s six section wires (1152 points each) on OCCT v1.17.0. Three independent reconstructions against this kernel (8.0.1 + patches), matching gear-tooth polygons at various tooth counts/tapers/twists, a dense sinusoidal profile, and a faithful port of OCCTSwiftScripts/recipes/04-spur-gear’s involute math scaled per section (matching the issue’s own 1152-points-per-wire figure exactly at flankSamples = 14, plus a spiral-twist variant), all produced a BRepCheck_Analyzer-valid raw loft, across 400+ parameter combinations. BRepCheck_Analyzer itself does not flag 3D self-intersection between non-adjacent faces either: a deliberately self-intersecting 179-degree-twisted star-prism loft still reports isValid == true, confirmed directly and matching analyze()’s own selfIntersectionCount, which is hardcoded to 0 and always has been (see below). Source-reading ShapeFix_Solid::Perform()/CreateSolids()/CollectSolids() found no path that demotes a genuinely closed shell either: every demotion in that class is gated on BRep_Tool::IsClosed/ShapeAnalysis_FreeBounds finding real free edges, matching #442’s documented contract. No fix was made for this specific scenario because nothing was found broken there; per the issue’s own instruction, a non-reproducing report closes with the evidence rather than a manufactured fix.

What does reproduce, trivially, with no loft at all: an open shell wrapped as a TopoDS_Solid (a box missing one face, sewn, then Shape.solidFromShells([shell]), exactly what BRepBuilderAPI_MakeSolid does with a single non-closed shell, no fixing). fixSolid()/healed() correctly demote it to a shell (#442’s contract), isValid reads true on the result, and this is where the issue’s own complaint held: analyze(tolerance:) read zero free edges on it regardless.

Root cause, and fixed: OCCTShapeAnalyze (OCCTBridge_Healing.mm) called ShapeAnalysis_Shell::LoadShells() and then read HasFreeEdges()/FreeEdges(). LoadShells() only registers a shell for NbLoaded()/Loaded() bookkeeping; it runs no edge analysis at all. Only CheckOrientedShells() populates the free-edge set those accessors read, exactly as the sibling entry point OCCTShapeAnalyzeShell (backing Shape.analyzeShell()) already calls it. So freeEdgeCount was hardcoded to 0 for every shape passed to analyze(tolerance:), however open, and freeFaceCount’s own local variable was never incremented anywhere in the function; both silently agreed with a defect no matter what it was. Now CheckOrientedShells(shell, alsofree: true) is called, freeEdgeCount reports the real count, and freeFaceCount counts the shells found not fully closed, matching the field’s own existing header comment (“Number of free faces (shell not closed)”).

Shape.isValidSolid already answered the issue’s actual question, unaffected by either bug, for a reason unrelated to this fix: added for #206/#208 (an unrelated self-intersecting-loft hazard), it checks shapeType == .solid before running BRepCheck_Analyzer, so it reads false on any demoted shell where plain isValid reads true. It had no test at all for that branch: every existing assertion (Issue225ThreadedRodTests, Issue257MultiStartTests, Issue397CircularHoleTests, OCCTShapeHealingTests) only tested the positive, already-a-solid case. Also documented: selfIntersectionCount is another permanent 0 (the bridge’s own comment: “would require more expensive computation”), not a computed absence of self-intersection.

healed() gained the demotion warning fixSolid() has carried since #442 (it shares the same ShapeFix_Solid mechanism, confirmed by reading ShapeFix_Shape.cxx’s delegation), and both now cross-reference isValidSolid as the reliable check. This is a bug fix to the values Shape.analyze(tolerance:) returns, not a new field or a signature change. Like the #605/#609/#583/#595 fabricated-zero fixes before it, this is a PATCH-level correction (a wrong value repaired, per SEMVER.md’s own quick-reference table), not a recorded exception: nothing could have correctly relied on a hardcoded 0.

New tests: Tests/OCCTShapeHealingTests/Issue702SolidDemotionTests.swift, 11 cases on the tiny open-shell fixture above (a box missing one face is the “smallest shape that demotes” the issue asked for). Proven to catch the fix: reverting OCCTShapeAnalyze back to LoadShells() fails exactly the three tests exercising freeEdgeCount/freeFaceCount (open shell, demoted shell, a two-shell compound) and leaves the other seven (isValidSolid, demotion-to-shell, closed-box negative control) green, confirming the new tests target this bug specifically rather than the already-correct demotion behaviour.

Follow-up from code review, before this landed:

• OCCTShapeAnalyze’s new CheckOrientedShells call omitted checkinternaledges, the third argument, unlike the sibling OCCTShapeAnalyzeShell, which already passed true. ShapeAnalysis_Shell.cxx: with checkinternaledges false, a FORWARD/REVERSED edge with no opposite-orientation partner is unconditionally free; with it true, an edge that also occurs with TopAbs_INTERNAL orientation elsewhere in the same shell (matched by IsSame: same TShape and Location, ignoring orientation) is read as connected through that occurrence instead. The two entry points could silently disagree on any shell carrying an INTERNAL-oriented edge, directly contradicting this fix’s own “analyze() must agree with analyzeShell()” test invariant. The original fixture (the box missing one face) has no INTERNAL-oriented edges, so it could not catch the divergence; a new fixture does (a single face wrapped as a shell, with an .internal-oriented duplicate of one of its own boundary edges embedded back into the face before the face joins the shell). Both call sites now share one helper (occtAnalyzeShellOrientation), so the argument cannot drift between them again the way it just did.
• totalProblems double-counted an open shell’s defect: once via freeEdgeCount (one count per free edge) and again as a flat +1 via freeFaceCount (one shell found not fully closed), now that this fix makes both fields live for the same shape at once for the first time. freeFaceCount is a derived summary of the same scan, not an independent defect category, so totalProblems no longer includes it; freeFaceCount stays a public field for callers who want the shell-level breakdown.
• The per-shell scan gained a per-iteration try/catch. CheckOrientedShells is a real OCCT computation, unlike the LoadShells() it replaced, so it can raise Standard_Failure on a malformed shell; without a scoped catch, one bad shell in a multi-shell shape would abort to this function’s outer catch and discard every other shell’s free-edge count along with the small-edge/small-face/gap counts computed afterward, rather than just skipping that one shell’s contribution.

A second, corrected review pass retracted five of the first pass’s seven points (a docs gap on fixed/upgraded, the per-shell try/catch above, duplicated scan logic, and two writing-style nits) as not part of its own verified output, keeping only two (checkinternaledges and the totalProblems double-count, both already listed above) and replacing the rest with two genuinely different findings:

• isValidSolid, isValid and healed()’s doc comments carried no fenced swift code block. isValid and healed() gained new demotion-hazard prose in this same fix and neither picked up an example; isValidSolid had none even before this fix touched its doc, so the review’s claim held on all three. All three now carry a runnable snippet that builds the box-missing-one-face fixture and shows isValid == true / isValidSolid == false on the demoted shell: the exact hazard each paragraph describes, not a decorative unrelated example. Each snippet’s literal code was run once as a throwaway test before being written into the doc comment.
• Issue702SolidDemotionTests.openShellMissingOneFace() duplicated a fixture Issue442FixSolidMultiBodyTests.swift already built inline, in the same test target: both drop one face from a box, compound the remaining five and sew them, the smallest input that reaches ShapeFix_Solid’s cannot-close branch. Extracted to Tests/OCCTShapeHealingTests/ShapeHealingTestFixtures.swift (sewnBoxMissingOneFace(_:tolerance:), parameterized on the box so the two suites keep their own box size/origin), following the precedent Tests/OCCTStressTests/StressTestFixtures.swift already set for sharing fixtures within one test target. Both suites re-verified unchanged after the refactor.

CI builds the same kernel the branch is written against

Package.swift now pins the v2.0.0-kernel.1 pre-release: upstream V8_0_1 plus the eleven carried patches 0010-0012 and 0014-0021. It previously pinned v1.15.18, which is V8_0_0_p1 + patches 0001-0016.

That mismatch made ci.yml’s macOS job useless as a signal on this branch. Every test asserting behaviour a newer patch fixes failed there, indistinguishably from a real regression, and seven suites were red for that reason alone: #522 approximation collapse, #570 healing approximations, both #572 sweep and conversion suites, #491 approximation parity, #496 cylindrical hole contracts and #532 hole part selection. Every new correctness fix added more, and the documented workaround was to read kernel-integration.yml instead (#585).

Against the new pin, with no local Libraries/ and no OCCTSWIFT_LOCAL, the full suite is 5,313 tests, 0 failures. OCCTSWIFT_LOCAL=1 remains useful for iterating on a locally rebuilt kernel; it is no longer required to get correct results.

The pre-release is not a library release, and is not installable as one. The v2.0.0 release commit re-points url:/checksum: at the final asset (#512), but the pre-release itself is kept: every commit in the v2.0.0 window pins it, so deleting it would take its asset with it and make those commits unbuildable from a clean checkout, breaking git bisect and historical re-measurement.

Verified before publishing, per docs/guides/building-occt.md’s shipping checklist: occt-src at exactly V8_0_1, all eleven patches reverse-apply, and zero modified files that no carried patch touches, so no investigation probe is compiled in. The published asset re-downloads to the same SHA256 it was uploaded with.

OCCT re-pinned to 8.0.1

The source pin moves from V8_0_0_p1 to V8_0_1 (2026-07-30), the first maintenance release in the 8.0 series. Against p1 it is a clean fast-forward (23 commits, 74 files, nothing reverted) and it carries no API or ABI break: the only public header in the whole diff is ShapeAnalysis_FreeBounds.hxx, changed by one comment line. Nothing to migrate for the OCCT API itself.

Package.swift’s url:/checksum: pointed at the v1.15.18 asset when this landed, which is p1 + patches 0001-0016, on the #512 rule that the bump belongs to the release commit. That is no longer the case: see “CI builds the same kernel the branch is written against” above, which pins the v2.0.0-kernel.1 pre-release. A clean checkout with no local Libraries/ now resolves the right kernel, and ci.yml’s macOS job is a real signal. OCCTSWIFT_LOCAL=1 remains useful for iterating on a locally rebuilt kernel; it is no longer needed for correct results.

edges() keeps its orientation collapse: audited, no consumer needs it (#638)

Documentation only, no code change.

Shape.edges() has the identical TopExp::MapShapes/IsSame collapse #614 fixed for faces(): an edge reachable from two owners collapses to one entry carrying whichever orientation was reached first. Measured on a plain box, edges().count/edgeCount report 12 distinct edges while Shape.contents.edges (an independent, already-documented occurrence count) reports 24: one per (face, edge) visit.

#614 was a defect because Face.normal(atU:v:) reverses on TopAbs_REVERSED, so a face’s stored orientation changed the answer a caller got. This issue’s own text refused the analogy and asked whether the same is true for edges before assuming it. It is not: Edge exposes no .orientation accessor at all, and every geometric query on it (tangent(at:), point(at:), parameterBounds, curvature(at:)) reads the edge’s underlying Geom_Curve through BRep_Tool::Curve, which is defined independently of TopAbs_Orientation. A bridge-wide grep for .Orientation() == across Sources/OCCTBridge/src/*.mm finds 14 branching sites: 13 are face-normal logic #614 already covers, and the fourteenth (occtSampleWirePoints, OCCTBridge_Modeling.mm) reads orientation fresh off a BRepTools_WireExplorer walk of the wire it samples, never from an edge Shape.edges() produced.

Verified beyond the source read: constructing the identical edge with both TopAbs_Orientations (Shape.subShape(type:index:).reversed) and comparing every accessor Edge exposes shows them bit-for-bit identical, on both a straight and a circular edge.

Decision: document the contract, add no orientedEdges(), change no behaviour. This is the outcome this issue’s own text names as correct when no orientation-dependent consumer exists. Shape.edges()/edgeCount’s doc comments and docs/reference/Edge.md now state the collapse explicitly, matching how Shape.faces() documents its own. Regression tests in Tests/OCCTTopologyTests/Issue638EdgeOrientationContractTests.swift pin both halves: the dedup mechanism itself (12 distinct / 24 occurrences on a box, 20 distinct on the #614 split fixture), and the orientation-independence of Edge’s per-instance accessors, verified by injecting a hypothetical orientation-aware tangent and watching it fail before restoring it.

See Scripts/repro/cluster-a-subshape-enumeration/ (#664) for the full census this decision rests on.

Ten carried kernel patches retired

8.0.1 ships our own upstream contributions, so Scripts/patches/ goes from 21 files to 11. Retired: 0001-0009 and 0013, covering #263, #280, #298, #310, #317, #318, #323 (three) and #348. Every merge commit was confirmed an ancestor of the tag rather than merely merged to master, and every patch was diffed against its as-merged form before its file was deleted, because review can change a patch between submission and merge.

Nine came back unchanged. 0001 did not: upstream’s merged form also guards a removed face (anApplied.IsNull() ||) where ours checked only the shape type, so that retirement fixes a latent null dereference our own patch had. Per-patch verdicts are in Scripts/patches/README.md under “Retired patches”.

Patch numbers are not reused: the carried sequence now reads 0010-0012, 0014-0021, and the gaps are the retirements. Renumbering would have repointed every citation in CLAUDE.md, docs/, closed issues and Scripts/repro/ at a different fix.

Behaviour changes 8.0.1 brings, measured

The full suite is green on the new kernel (5313 tests, 1400 suites, 0 failures), but a green suite is not evidence for two of these, because no test in the repo uses INTERNAL/EXTERNAL edge orientation and #645 records that the Gordon tests assert only status ordinals. Those two were probed directly. Tracked in #654.

• GeomFill_Gordon was returning a 5% wrong surface, and 8.0.1 fixes it. Handed the isocurves of the surface it should reproduce, a rational network (quarter cylinder, r=5) deviated 0.251262658 from its own input while reporting IsDone; it is now 2.6e-15. The 45° sample moves from 3.713203436 to 3.535533906, which is exactly 5/√2. A non-rational control was already exact on both kernels, so only rational networks ever moved. Affects Surface.gordon(profiles:guides:tolerance:) and Surface.gordonReport(...). Evidence added to #645.
• Shape.sectionWiresAtZ(_:tolerance:), not freeBounds*, sees the INTERNAL/EXTERNAL skip (#655). ShapeAnalysis_FreeBounds::ConnectEdgesToWires now skips edges oriented .internal/.external: a sequence of one INTERNAL edge plus a square returns 1 wire where it returned 2, and a sequence of nothing but INTERNAL/EXTERNAL edges returns 0 wires where it returned 1. That C++ function appears exactly once in this bridge, inside OCCTShapeSectionWiresAtZ, which backs Shape.sectionWiresAtZ(_:tolerance:), a CAM sectioning API: in every case measured, an ordinary transverse cut does not produce such an edge, but a cut plane coincident with an edge a caller already marked .internal/.external via Shape.setOrientation(_:) does move, 2 wires to 1 on a measured fixture. The freeBounds* family does not move, but not because its call graph avoids the change: Shape.freeBounds, freeBoundsClosedCount, freeBoundsClosedWires and freeBoundsOpenWires build ShapeAnalysis_FreeBounds’s (shape, tolerance) constructor, whose own chainage step reaches the same skip. The reason is upstream, the edges that constructor feeds in come from BRepBuilderAPI_Sewing::FreeEdge, and in every case measured that sewing stage never produced an .internal/.external free edge for the skip to act on. freeBoundsAnalysis, FreeBoundsProperties and its four accessors take a second constructor at tolerance <= 0, with no sewing stage at all, so that reason does not apply to them; measured separately, the exclusion holds there too.
• BRep_Tool::CurveOnPlane fails differently. An out-of-domain, inverted or zero-length edge range now yields a null pcurve where 8.0.0p1 threw a catchable Geom_TrimmedCurve::parameters out of range. All four probed cases changed.
• No movement from the BRepMesh periodic-seam fix, the ChFi3d_Builder::StartSol hardening, or the BRepCheck_Face/GeomLib_CheckCurveOnSurface fast paths. For those three the green suite is evidence, since they are well covered.

Fixed: evalAndUpdateTolerance handed OCCT an unguarded null pcurve

Shape.evalAndUpdateTolerance(edge:face:) was an uncatchable SIGSEGV whenever the edge had no pcurve on the given face and that face was not planar, which is routine for mesh-sewn topology. The bridge guarded the 3D curve and the surface but passed the pcurve straight into BRepTools::EvalAndUpdateTol, which dereferences it at if (!C2d->IsPeriodic()).

Fixed here rather than deferred because the re-pin adds a second route to it: with #1402 returning null instead of throwing, the crash became reachable on a planar face too, where 8.0.0p1 returned a safe 0.0. Shipping the absorb without the guard would have introduced a new crash path. #656.

build-occt.sh could not change OCCT version

It cloned occt-src only when the directory was absent, so bumping OCCT_VERSION/OCCT_RC was a silent no-op on any machine that had built before: the old tag’s sources were compiled and packaged under the new version’s number. It now requires HEAD to be at the tag the script names and aborts otherwise, naming the tree so a diagnostic probe left by an investigation is not destroyed silently.

GeomTools_Curve2dSet/SurfaceSet null-handle census: closed on evidence, kernel patch carried (#643)

Cluster C’s own census (#666, PR #711) concluded, without re-measuring, that #643 is already bridge-guarded and the remaining defect is upstream. Re-verified rather than inherited, per this issue’s own instructions.

The guard holds. OCCTGeomToolsCurve2dSetWrite/OCCTGeomToolsSurfaceSetWrite (Sources/OCCTBridge/src/OCCTBridge_IO.mm) already refuse a null handle per array element before calling GeomTools_Curve2dSet::Add/GeomTools_SurfaceSet::Add (the #618 “array element through a cast” shape), and these two functions are the only call sites of either class anywhere in the tree. Confirmed dynamically too, not just by reading the guard: override-linking the real OCCTBridge_IO.mm against a genuinely null-handle-wrapping OCCTCurve2D/OCCTSurface returns nullptr rather than crashing, for both a null-only array and a mixed valid+null array. Removing the guard (injected, then restored) reproduces the SIGSEGV through the real bridge function, confirming it is load-bearing rather than incidental.

The upstream asymmetry is real and still live. GeomTools_CurveSet::Add guards a null handle and drops it (return (C.IsNull()) ? 0 : myMap.Add(C);); GeomTools_Curve2dSet::Add and GeomTools_SurfaceSet::Add don’t, so a null is bound at a valid-looking index and only crashes later, inside Write(). Re-measured directly against the pinned kernel (v2.0.0-kernel.1, OCCT V8_0_1 + eleven carried patches) rather than assumed from the issue’s original 8.0.0p1 report: identical result. A second, previously unnamed divergence was found checking whether the three writers disagree anywhere else: Index() has the same asymmetry (CurveSet::Index guards, the siblings don’t). It doesn’t crash (NCollection_IndexedMap::FindIndex never dereferences its argument), but the two siblings silently report a bogus non-zero index for a handle that was never validly bound, where CurveSet::Index correctly answers 0. Both files are byte-identical between the pinned V8_0_1 tag and current upstream master.

Filed upstream and carried, not fixed bridge-side. This repo’s own guard already prevents any caller from reaching the defect, so the fix belongs in the container, not the wrapper. Kernel patch Scripts/patches/0023-GeomTools_Curve2dSet-SurfaceSet-null-handle-643.patch mirrors GeomTools_CurveSet’s own correct guard onto Add/Index on both siblings (four one-line changes), verified by override-linking the patched files ahead of the unpatched archive: all three classes’ Add() now return 0 for a null handle and Write() completes normally; all three classes’ Index() now return 0. Filed as Open-Cascade-SAS/OCCT#1434 (repro) / OCCT#1435 (fix). Inert until the pinned xcframework is rebuilt (#512); this change does not rebuild or bump the pin.

No bridge behavior change, no public API change. See Scripts/repro/643-geomtools-null-write/ for the reproducer and the full “prove the test fails” injection matrix (bridge guard removed → SIGSEGV reproduced; kernel patch applied → both defects resolved).

chamfer2D SIGSEGVs, uncatchably, on a repeated edge pair (#705)

Found by Cluster B’s edge/vertex-index census (#665, Scripts/repro/cluster-b-fillet-edge-contract/), which records the crash rather than running it live, since an in-process OS signal would kill the census itself. Shape.chamfer2D(edgePairs:distances:) crashed the whole process, uncatchably, when the same edge pair appeared twice:

let wire = Wire.polygon3D([SIMD3(0, 0, 0), SIMD3(10, 0, 0), SIMD3(10, 10, 0), SIMD3(0, 10, 0)], closed: true)!
let rectFace = Shape.face(from: wire)!
_ = rectFace.chamfer2D(edgePairs: [(0, 1), (0, 1)], distances: [1.0, 2.0])   // SIGSEGV, exit 139

Confirmed in a separate process (a temporarily-repointed Sources/OCCTTest/main.swift, restored after), since an in-process crash kills the test runner rather than failing one test:

The crash is inside the repeat call’s own BRepFilletAPI_MakeFillet2d::AddChamfer, an OS signal the bridge’s catch (...) cannot absorb, and it is an upstream OCCT defect, not this bridge’s own. AddChamfer(edge1, edge2, ...) calls ChFi2d::FindConnectedEdges to look up the pair’s shared vertex and dereferences the two edges it returns without checking the returned status first, and that lookup leaves both edges null on every failure path. A pair’s second call fails the lookup, because its shared vertex was already consumed chamfering the pair the first time. The sibling overload (AddChamfer(edge, vertex, distance, angle)) checks the identical status correctly, which is the precedent the upstream filing cites. Reusing one edge across two different pairs, i.e. chamfering adjacent corners of a polygon, the ordinary multi-corner case, does not crash, measured above. Only the identical pair repeated does, order-independent. A kernel patch is carried separately, tracked in a follow-up PR; the guard below is what protects callers until it ships.

Fixed: OCCTFace2DChamfer (OCCTBridge_Modeling.mm) now checks each pair against every prior pair in the same call before invoking AddChamfer, and rejects the whole request (returns nullptr) on a match in either order. This matches fillet2D(vertexIndices:radii:)’s own contract for a duplicated vertex on the same builder (#568) and the #568 idiom already used one line above in the same function for an out-of-range index: the whole call fails rather than guessing which of two distances to keep. #633 is open on the wider family’s duplicate-index direction (fillet is last-wins, chamfer is first-wins) and is deliberately not settled here; this fix removes a crash, not a vote in that debate, though it is recorded as a data point for it.

This is a behaviour change on a public API with no compile error, recorded in SEMVER.md. A call with no repeated pair, which includes every existing caller, is unaffected. Tests: Tests/OCCTModelingTests/Issue568IndexSkipTests.swift’s chamfer2DRejectsDuplicatePair and chamfer2DAcceptsSharedEdgeAcrossDifferentPairs, the latter proven to catch an overly broad fix by injecting one (reject on any repeated single index rather than a repeated pair) and confirming it turns the shared-edge test red, then restoring.

The census’s own row for chamfer2D is updated from CRASH (SIGSEGV, uncatchable) to the measured REJECT (nil), now safe to run live: swift run Censuses cluster-b calls it directly rather than noting it as unsafe to run.

Pass 1b of the #377 duplication audit

PipeSweepMode.frenet and .correctedFrenet were wired to each other’s OCCT mode (#598)

Found while measuring #572, which needed the pipe shell driven in a specific trihedron mode. BRepOffsetAPI_MakePipeShell::SetMode’s parameter is named IsFrenet, and its header (confirmed against the pinned V8_0_1 source before changing anything) says so: “If IsFrenet is false, a corrected Frenet trihedron is used.” occtPipeShellSetMode (OCCTBridge_Modeling.mm:494) passed the opposite boolean for both enum cases: OCCTPipeModeFrenet called SetMode(Standard_False) (corrected Frenet) and OCCTPipeModeCorrectedFrenet called SetMode(Standard_True) (plain Frenet). PipeSweepMode.frenet is the default mode: on all three Shape.pipeShell* spellings, so this affected every caller who never named a mode, not only one who asked for .frenet explicitly.

Measured, not assumed, that the two modes actually differ, using an independent oracle: PipeShellBuilder.setFrenet(_:) calls BRepFill_PipeShell::Set(frenet) directly, a separate bridge function this bug never touched. On a curved B-spline spine (the same fixture Issue503PipeShellTests.curvedSpine() uses) with a rectangular profile, Shape.pipeShell’s .frenet and PipeShellBuilder.setFrenet(true) disagreed before this fix (180.286724 vs 177.347557) and agree after it; .correctedFrenet and setFrenet(false) disagreed the other way and now agree too. On a spine with no torsion the two OCCT trihedron laws coincide, so the swap was silent there: a straight-line spine produces byte-identical volumes for .frenet and .correctedFrenet both before and after this fix, confirmed by a test that stays green with the defect deliberately reinjected.

Fixed: swap the two SetMode booleans in occtPipeShellSetMode. A second, related site was found in the same file and left behavior-unchanged: OCCTShapeCreatePipeShellWithLaw (line 4134) hardcodes SetMode(Standard_False) with a // Frenet comment that was equally wrong (it builds corrected Frenet); that entry point takes no mode: parameter at all, so no public contract changed, only the misleading comment.

Not recorded as a SemVer exception. This lands in v2.0.0, a major version, where SemVer permits breaking changes outright: SEMVER.md’s own words scope its recorded-exception ledger to a break “within a major line”, which a break shipping in the major bump itself is not. An earlier revision of this entry added a fourteenth exception here anyway; review of #715 (this fix’s own PR) caught that as a category error, and it also introduced counter drift in two other places (SEMVER.md stated both “thirteen” and “fourteen” total exceptions in different paragraphs, and left #609 mis-numbered as the “fourteenth” held-for-v2.0.0 break instead of the fifteenth). SEMVER.md is restored to the state it was in before this issue; this changelog entry is the migration note a consumer needs instead.

Blast radius, corrected after review of #715, not fully measured the first time. The original measurement covered a spine with ordinary curvature/torsion and a spine with none; neither is the case .correctedFrenet’s own doc comment names as its reason to exist (“avoids twisting at inflection points”). Measured properly this time, on a planar S-curve whose curvature crosses exactly zero at its midpoint (confirmed by sampling curvature(at:) across the domain rather than assumed from the control points):

This is the regression class review of #715 asked for: a caller who never named a mode and sweeps a spine through a curvature inflection now gets an invalid solid where the pre-#598 (wrongly-wired) default happened to build the safer sweep instead, by accident, under the old bug. There is no general substitute for naming .correctedFrenet explicitly here: if a spine’s curvature may pass through zero, do not rely on the .frenet default.

Also corrected: the claim that a circular profile makes the two trihedron laws produce “the identical swept volume” everywhere was wrong, and it was the reason this entry originally gave for why docs/guides/cookbook/helices.md’s spring recipe needed no update. Measured directly against the independent PipeShellBuilder oracle, on the cookbook’s own r=10, pitch=4, turns=5, wireRadius=1.5 helix: .frenet reproduces the textbook tube volume (π·wireRadius²·coilLength, 2225.1497 measured vs 2225.1564 expected) but .correctedFrenet does not (2495.4373 measured, about 12% larger). A circular profile only guarantees the two laws agree on a spine with no torsion (the case actually tested above); a helix has constant, non-zero curvature and does distinguish them. Since the cookbook’s own claimed invariant (spring.volume ≈ π·wireRadius²·(coil length)) now holds only for .frenet on this recipe, the recipe is corrected in this same PR to use .frenet, and its prose no longer claims rotational symmetry makes the two laws interchangeable.

Revised after OCCTSwift #721: the paragraph above was itself wrong, not just the cookbook. The “about 12% larger” measurement placed the profile at SIMD3(r, 0, 0) with tangent normalize(0, r, pitch/2pi), describing that as the helix’s own start point and tangent. It is neither: Wire.helix’s default clockwise: false reverses the build axis to -Z, so the wire’s actual start is (-r, ~0, 0), descending, and the real tangent’s Z-component has the opposite sign. With the profile placed at the spine’s own measured start point and tangent instead, .frenet and .correctedFrenet agree with each other and with the textbook volume to ~1e-6 relative, at every pitch and turn count tested (see #721’s own PR for the full sweep). The rotational-symmetry argument this entry originally walked back was correct after all; the measurement that contradicted it was constructing the wrong profile, not testing a real .correctedFrenet limitation. docs/guides/cookbook/helices.md’s recipe and this repo’s own Issue598PipeShellFrenetModeTests.cookbookSpringRecipeVolumeInvariant are corrected in #721’s PR to measure the tangent from the wire rather than compute it analytically, and .correctedFrenet is restored as a mode that also produces the textbook volume on a helical spring.

Every other existing pipe-shell call site in this repo’s tests uses either a straight spine or a non-Frenet mode (.fixed(binormal:), .auxiliary(spine:)) this bug never touched. Exactly one existing hardcoded literal needed updating: Issue503PipeShellTests.fixedBinormalDiffersFromFrenet’s pinned .frenet volume moves from 180.286724 to 177.347557. Shape+Modeling.swift’s own pipeShell doc snippet had the same stale literal (180.29) and is corrected to 177.35.

New tests: Tests/OCCTModelingTests/Issue598PipeShellFrenetModeTests.swift. Six cases: .frenet and .correctedFrenet each matched against the PipeShellBuilder oracle on the curved spine (and confirmed to disagree with the other oracle value, so a match isn’t a coincidence of tolerance), the multi-section spelling inheriting the same fix through the shared helper, the no-torsion control, the curvature-inflection self-intersection case above, and the cookbook recipe’s volume invariant above. curvedSpine() and the scale-relative tolerance helper are no longer duplicated in this file: review of #715 found three near-identical copies of the same tolerance formula (with two different default tolerances) split across this file and Issue503PipeShellTests.swift (same target); both fixtures are now promoted from Issue503PipeShellTests.swift and reused directly instead.

Proved each new/changed case catches its own defect, per test rather than as a suite total: reinjecting the original swap (SetMode(Standard_False) for OCCTPipeModeFrenet, SetMode(Standard_True) for OCCTPipeModeCorrectedFrenet), rebuilding, and rerunning:

13 issues across 5 new/changed tests plus the pre-existing literal, while the no-torsion control stays green throughout, confirming it really is a silent case rather than an assumption. Restoring the fix returns all of them to green.

The fillet family could not report a declined edge, only skip it silently (#639)

BRepFilletAPI_MakeFillet::Add does nothing, with no exception and no false return, for an edge it cannot fillet, most commonly a free-boundary edge of an open shell, which has only one adjacent face where a fillet needs two. filleted(edges:radius:), filleted(edges:startRadius:endRadius:) and filletEvolving(_:) have always skipped such an edge rather than rejecting the whole call (#612), correctly, but had no way to tell a caller which edges those were, or how many. The Cluster B census (Scripts/repro/cluster-b-fillet-edge-contract/) measured the gap concretely: filleting all 12 edges of an open shell (a box with one face dropped, sewn) accepts 8 and silently declines 4 ([6, 9, 10, 11]), and every one of these three entry points reports plain success.

The decision this issue asked for, made explicitly: report, do not reject. Converging every declining entry point onto rejecting a batch with any declined edge would change filleted(edges:radius:), filleted(edges:startRadius:endRadius:) and blendedEdges(_:) on every open shell: a behaviour change wider than this issue, and the same mistake an earlier draft of #633 made and withdrew. Skip stays the answer; the fix is observability, following #482’s FillingSurface.refusedConstraintCount precedent named in the issue.

What OCCT can actually say, measured before designing around it: Add returns nothing, and BRepFilletAPI_MakeFillet::NbFaultyContours()/BadShape()/StripeStatus() describe a contour that failed during Build(), which an edge OCCT never added to any contour never reaches. The one signal OCCT does expose is Contour(edge) == 0, populated by Add() itself rather than by Build(). So this reports which edges were declined (a list of indices, not just a count: the issue’s own “count is cheap, naming which is more useful” argument, taken as far as it goes), and not why: no reason is reachable from this API.

Fixed for the three entry points that genuinely had no side channel: filleted(edges:radius:) and filleted(edges:startRadius:endRadius:) (OCCTShapeFilletEdges/OCCTShapeFilletEdgesLinear, sharing occtShapeFilletEdgeList) and filletEvolving(_:) (OCCTShapeFilletEvolving) each gained a WithReport sibling, filletedWithReport(edges:radius:), filletedWithReport(edges:startRadius:endRadius:), filletEvolvingWithReport(_:), returning a new Shape.FilletResult { shape, declinedEdgeIndices }. The bridge computes the report with a new shared helper (occtFilletDeclinedIndices/occtFilletWriteDeclined, OCCTBridge_Internal.h) that re-checks Contour(edge) for each requested index after every Add() and before Build(); the three underlying bridge functions gained two nullable trailing out-parameters the existing non-reporting call sites pass nil for, so nothing about their cost or behaviour changes.

Two of the issue’s own named members already carried the mechanism, measured rather than assumed missing: filletedWithFullHistory(radius:edges:)’s ShapeHistoryRef distinguishes a declined edge from an accepted one via !record.isDeleted && record.generated.isEmpty. An edge OCCT actually filleted is always deleted with the new fillet-boundary edges in generated (12/12 on the fixture). The first hypothesis for this recipe was wrong and caught by measuring it: a declined edge is not necessarily modified.isEmpty too. On this fixture every declined edge shows exactly one modified entry, a different edge instance with a shorter length (10.0 to 8.0), because an accepted neighbour’s fillet trims the declined edge’s shared endpoint. modified alone is not the signal; generated/isDeleted are. Separately, FilletBuilder.contour(for:), already present and unrelated to this issue, answers the identical Contour(edge) == 0 question directly, readable right after addEdge with no build() required, matching the census’s measured set exactly before and after build(). Both are documented (ShapeHistoryRecord, FilletBuilder) with a runnable recipe rather than given new bridge code, since there was nothing to add.

blendedEdges(_:), #633’s own site, does not adopt this mechanism here. It is the same SKIP behaviour on the same declined-edge axis, so the same WithReport shape would apply, but #633 is about a different axis of this contract (a duplicated edge index silently discards a radius) and is scheduled after this PR specifically because the reporting decision made here might change what #633 should do. Recommendation for that issue: adopt the same FilletResult-shaped report, extended to also carry which duplicate indices were overwritten, since the same “list what happened, do not change what SKIP or OVERWRITE means” principle applies to it too.

New tests: Tests/OCCTModelingTests/Issue639FilletDeclinedEdgeReportTests.swift, seven cases covering all five members named in the issue (the three WithReport siblings, the FilletBuilder recipe, the history recipe) plus two “empty on a closed solid” negative controls. Each of the five declined-set assertions was proven to catch its own mechanism, not just some regression elsewhere: reverting occtFilletWriteDeclined to report nothing fails exactly the three WithReport tests (the two negative controls correctly stay green, since they expect empty anyway); separately reverting OCCTFilletBuilderContour fails exactly the FilletBuilder test; separately reverting OCCTBooleanHistoryIsDeleted fails exactly the history test.

This is additive, non-breaking Swift API (three new methods, one new struct, no existing signature changed), recorded in SEMVER.md per #664’s discipline of writing this down now rather than at tag time, even though nothing here moves the file’s own “twelve recorded exceptions” count. Scripts/repro/cluster-b-fillet-edge-contract/ is unchanged: the census measures the contract, this issue only adds a way to observe one axis of it, and the measured grid itself (SKIP/REJECT per cell) does not move.

blendedEdges(_:) reports which duplicate entries were overwritten (#633)

The last open member of Cluster B (#665). BRepFilletAPI_MakeFillet::Add(radius, edge) resolves an edge’s own slot within its fillet contour and writes there, so naming the same edge index twice in blendedEdges(_:)’s edgeRadii writes that slot twice – the second Add silently overwrites the first, with no exception, no false return and nothing in the result to say a radius was ever discarded. Re-measured on this tree rather than trusted from the issue: blendedEdges([(0, 2.0), (0, 5.0)]) gives the identical volume (946.349541) to blendedEdges([(0, 5.0)]) and differs from blendedEdges([(0, 2.0)]) (991.415927) – last-wins, confirmed.

Sequenced deliberately after #639, which decided the reporting mechanism for the family’s other silent axis (an edge OCCT declines outright) and recommended, in its own PR, extending the same shape to also cover this one rather than re-deriving a mechanism. That recommendation is taken here without a reason found to deviate: report, do not reject or pick a “winning” direction. Converging blendedEdges(_:) onto reject, or onto first-wins (matching the chamfer family, see below), would change what it returns for every existing caller who happens to name an edge twice and currently gets a built shape – a behaviour change wider than this issue, and the same move #639 rejected for its own axis.

Fixed: blendedEdgesWithReport(_:) is a new WithReport sibling, returning Shape.FilletResult, now with a second field, overwrittenDuplicateIndices – the 0-based edge indices whose radius a later entry in the same request overwrote, mirroring the request list the same way declinedEdgeIndices already does (an edge named three times reports two overwritten entries, not one distinct index). Computing it needs no OCCT round trip at all: an edge index maps to exactly one edge via Shape’s own TopExp enumeration, so which entries lose is a property of the caller’s edgeRadii array alone, resolved Swift-side. blendedEdgesWithReport(_:) also adopts #639’s declined-edge mechanism for this entry point (OCCTShapeBlendEdges gained the same two nullable trailing out-parameters OCCTShapeFilletEdges/OCCTShapeFilletEdgesLinear already carry, threaded through the shared occtShapeFilletEdgeList skeleton) rather than leaving that field permanently empty for this one sibling: a report that answered one axis and silently stayed blank on the other would be the same shape of silent-wrong-answer this whole cluster exists to fix. blendedEdges(_:) itself, and every other FilletResult-returning method, are unchanged – the new field defaults to [] for filletedWithReport(edges:radius:), filletedWithReport(edges:startRadius:endRadius:) and filletEvolvingWithReport(_:), none of which has a duplicate axis of its own to report.

filletEvolving(_:) measures the identical last-wins mechanism (documented on EvolvingFilletEdge’s own doc comment, and confirmed again by this PR’s re-measurement), and is deliberately left alone here: extending filletEvolvingWithReport(_:) with the same field is a natural follow-up, not a requirement of this issue, which is scoped to blendedEdges(_:) by its own title.

New tests: Tests/OCCTModelingTests/Issue633BlendedEdgesDuplicateReportTests.swift, seven cases. Proven against three independent injections, each restored and confirmed green afterward:

This is additive, non-breaking Swift API (one new method, one new field on an existing struct, no existing signature or behaviour changed), recorded in SEMVER.md – checked and confirmed the file’s “thirteen recorded exceptions” count is unaffected. Scripts/repro/cluster-b-fillet-edge-contract/ and Scripts/repro/censuses/ClusterB.swift are updated to annotate the now-fixed cell; the measured grid itself does not move (swift run Censuses cluster-b still emits 16 rows).

AAG rode the lossy faces(), so detectPocketsAAG() answered 2 or 1 for the same geometry depending on compound member order (#642)

AAG.buildGraph() built its node set from Shape.faces(), the IsSame-keyed enumeration #614 documented as orientation-insensitive by design: a face occurring both FORWARD and REVERSED collapses to one entry, keeping whichever orientation was reached first. AAGNode.isHorizontal/ isUpward/isDownward/isVertical/zLevel are all derived from that entry’s normal, and AAG.detectPockets() selects floors on exactly those fields, so which orientation survived the collapse silently decided the answer. #614 already fixed horizontalFaces(), upwardFaces() and facesByZLevel() by routing them onto orientedFaces(); AAG was a fourth consumer that PR did not reach, because it was never enumerated as one.

Measured on an origin-centred 10mm box cut through z=4 and recompounded in both member orders, the exact fixture Cluster A’s census (#664) confirmed reproduces this: detectPocketsAAG().count was 2 in one order and 1 in the other, and the AAG upward+horizontal node set was [2, 8] against [2], for identical geometry. #614’s own committed fixture, a vertical rather than horizontal cut, does not exercise this at all (its shared wall’s normal is horizontal-axis, never reaching isHorizontal()): a regression test built from that fixture would have found no order-dependence and wrongly concluded the defect did not exist. That correction came from the census, not this issue’s own text.

Fixed by moving AAG.buildGraph() onto Shape.orientedFaces(): a face shared between two solids in a compound is now two nodes, one per owning solid, each carrying that solid’s own normal, rather than one node carrying whichever normal the dedup happened to keep. AAGNode gains distinctFaceIndex, the node’s position in the old faces() enumeration, so a caller can still tell the two sides of a shared face apart or recover the previous one-node-per-face view. buildGraph() also gained a guard skipping any pair of nodes that share a distinctFaceIndex: without it, OCCTFacesAreAdjacent (which compares edge sets by IsSame, ignoring orientation) reports every one of a shared face’s own boundary edges as adjacent to itself, since both occurrences bound the identical edge set.

Two other approaches were considered and rejected, per the precedent #614 set of naming rejected alternatives: carrying both normals on one node per distinct face (preserves the old index model, but pushes the “which side” ambiguity onto every caller of isUpward/isHorizontal/etc. instead of resolving it once), and restricting AAG to single-solid input (never established as the only valid use, and would not fix anything for the multi-solid case it was already used for).

A second, different, pre-existing defect surfaced while verifying the fix, and is deliberately not fixed here. On the vertical-cut fixture, detectPocketsAAG().count moved from agreeing (1/1) to disagreeing (1/2) across member order, confirmed by reverting buildGraph() alone to show the identical asymmetry already existed before this fix and only cancelled out by coincidence in the total count. The mechanism: OCCTFacesAreAdjacent/OCCTEdgeGetConvexity have no concept of solid membership, so a face occurrence’s adjacency and convexity are checked against every topologically coincident neighbor, including one that belongs to a different solid than the occurrence’s own orientation. Doubling the shared wall’s node count made this pre-existing ambiguity fire more often. Recorded in Scripts/repro/cluster-a-subshape-enumeration/README.md rather than fixed, since it is a different mechanism than #642’s own (a graph lacking solid-membership tracking, not a normal losing information across a dedup collapse) and out of this issue’s scope.

This is a behaviour change on two public APIs (Shape.buildAAG(), Shape.detectPocketsAAG()) with no compile error, recorded in SEMVER.md. On every shape that shares no face, orientedFaces() equals faces() exactly, so nothing about a single-solid shape’s AAG changes. Tests: Tests/OCCTModelingTests/Issue642AAGNodeIdentityTests.swift, each proven to catch its own mechanism by reverting it alone: reverting orientedFaces() back to faces() fails 5 of 7 tests (the two no-regression tests, on a plain box and on #614’s own vertical-cut fixture, correctly still pass); separately reverting only the distinctFaceIndex adjacency guard fails exactly the one test that exists to catch it.

AAG linked faces across a solid boundary, so #642’s own fix moved a second, independent order-dependence into view (#699)

Found while measuring #642’s own fix. Cluster A’s census (Scripts/repro/cluster-a-subshape-enumeration/) re-ran after #642 landed and caught a NEW disagreement on a fixture #642 does not touch: a plain 10mm box split by an X-normal plane through x=4, recompounded in both member orders, detectPocketsAAG().count was 1 in one order and 2 in the other, for identical geometry. Confirmed with git stash that reverting #642 alone reproduces the identical asymmetry, so this is not something #642 introduced: #642’s fix (doubling a shared face’s node count) exercised it twice as often, which is why a previously-accidental cancellation stopped holding.

The mechanism is different from #642’s, and needs a different fixture to show. #642 was about node identity: which faces become graph nodes. #699 is about edges: which nodes get linked and with what attribute. OCCTFacesAreAdjacent and OCCTEdgeGetConvexity (OCCTBridge_BRepGraph.mm) have no concept of solid membership: both compare two TopoDS_Face values purely on their own edge geometry, ignoring the shape argument they are handed beyond a null check. On a vertical two-solid split, the shared wall borders two half-faces of the box’s original top face that also border each other along the cut line, so one edge is common to three face occurrences (both top-face halves and both sides of the wall). AAG.buildGraph()’s pairwise loop compared all three against each other regardless of which solid each belonged to, linking a face in one solid to a face in another and attributing a convexity meaningless for either. #642’s own fixture (a horizontal cut) never exercises this: its shared wall’s normal is horizontal-axis, so isHorizontal()/isUpward() never reach the duplicated face at all, and conversely #642’s own defect needs a horizontal cut, so neither fixture reproduces the other’s mechanism.

The contract: two faces sharing a B-Rep edge but belonging to different solids in a compound are adjacent in the compound and not adjacent in either solid, and AAG’s consumers (detectPockets(), concaveNeighbors(of:), convexNeighbors(of:)) want the solid-scoped answer.

Fixed by restricting AAG.buildGraph()’s pairwise adjacency/convexity check to occurrence pairs it can establish share a solid, rather than by adding solid-scoping to the bridge functions themselves: an audit found OCCTFacesAreAdjacent/OCCTEdgeGetConvexity have exactly one Swift call site each, both inside buildGraph(), so there was no other consumer a bridge-side change could have broken, and the Swift-side fix is the smaller change either way. Solid membership per occurrence is derived rather than looked up through a new bridge entry point: orientedFaces()’s underlying TopExp_Explorer walk visits every occurrence under one top-level solid contiguously before moving to the next, in the same first-encountered order Shape.solids itself enumerates solids in (both are one DFS over the same shape), so the flat occurrence list partitions into contiguous runs sized by each solid’s own face-occurrence count. Confirmed against both split fixtures (dumping every occurrence’s bounds alongside each solid’s own orientedFaces() count) before relying on it. AAG.buildGraph() falls back to the pre-#699 unrestricted comparison on a shape with zero or one solid, or if the per-solid counts don’t sum to the total occurrence count. Silently mis-partitioning would be worse than not partitioning at all, and neither case arises on any fixture this change measures.

OCCTEdgeGetConvexity did not need its own solid-membership fix on top of this: once adjacency is restricted to same-solid pairs, convexity is only ever computed for a legitimate same-solid neighbor. (A separate, unrelated defect was found while explaining a side effect below: OCCTEdgeGetConvexity’s reported concavity for a given physical edge depends on argument order, which reproduces on a single, uncut box and has nothing to do with solid membership. Recorded in Scripts/repro/cluster-a-subshape-enumeration/README.md rather than fixed here, since it was found explaining a side effect rather than measured as this issue’s own claim.)

A further correction to #642’s own headline measurement. Restricting to same-solid pairs also moves the HORIZONTAL fixture’s detectPocketsAAG().count from 2 (in both orders, #642’s own fix) to 1 (in both orders). This is not a regression: #642 was about order-AGREEMENT, which survives intact (1 in both orders, was 2 in both orders, still equal either way). What moved is that one of the two “pockets” reported before #699 was itself built from a cross-solid comparison between the shared wall and the wrong side of a split face, exactly the mechanism this issue fixes. Tests/OCCTModelingTests/Issue642AAGNodeIdentityTests.swift’s own pinned count moves from 2 to 1 accordingly, with a note explaining why; the AGREEMENT assertion it exists to guard is unchanged and still passes.

This is a further behaviour change on Shape.detectPocketsAAG(), recorded alongside #642’s own entry in SEMVER.md rather than a new one, since it is the same public API. On every shape with zero or one solid, nothing changes. Tests: Tests/OCCTModelingTests/Issue699AAGSolidScopedAdjacencyTests.swift, each proven to catch its own mechanism by reverting the fix alone (7 assertions across 3 tests fail, reproducing the exact 1-vs-2 and 2-vs-1 disagreements measured above; the single-solid and node-count tests correctly still pass, since #699’s fix touches edges, not nodes, and never applies to a single-solid shape).

Every workflow action pin moves to a Node 24 major (#648)

#625 bumped only the job it introduced, so ci.yml was left mixed-version: actions/checkout@v7 in gate-scripts, actions/checkout@v4 in build-and-test and ios-simulator-build. Deprecation annotations are emitted per job, not per workflow, so each remaining v4 job raised its own “Node.js 20 is deprecated” warning.

All 17 pins across the five workflow files were enumerated rather than just the two the issue named: actions/checkout v4 → v7 (six sites), actions/cache v4 → v6 (four sites), and actions/github-script v7 → v9 (one site). maxim-lobanov/setup-xcode@v1 is unchanged — the moving v1 tag already resolves to a node24 build — as are gate-scripts’ own actions/checkout@v7 and actions/setup-python@v7.

Bumping actions/checkout alone would not have cleared the warning. The annotation on the base commit names two actions, not one — “the following actions target Node.js 20 … actions/cache@v4, actions/checkout@v4” — because it is emitted once per job listing every Node 20 action in that job. Changing only the action the issue names would have left actions/cache@v4 behind and the warning still standing, while the diff looked like a fix.

The target for each was read out of that action’s action.yml at the pinned ref, not inferred from the version number, and one action does not follow the pattern: actions/github-script@v7 is using: node20, and node24 only arrives at v8. A sweep that made every pin say v7 would have produced a repo that looked consistent and left require-issue-labels.yml deprecated — the same shape of defect as the mixed-version file it was fixing.

No bump changed an interface: action.yml at the new ref is byte-identical to the old one apart from the using: line in all three cases, so fetch-depth, submodules, persist-credentials and cache-hit keep their declared defaults. The two real behaviour changes are inert here — checkout v6 persists credentials to a separate file rather than .git/config (no workflow reads them or pushes), and checkout v7 blocks checking out a fork PR head under pull_request_target or workflow_run (neither trigger is used; the two pull_request workflows are unaffected).

Four gate scripts documented as gating on exit status, run by nothing (#625)

check-bridge-index.py, check-null-handle-guards.py, check-docs-defaults.py and count-operations.py were each written to gate a commit, and three said so in their own docstring. No workflow, hook, script or Makefile invoked any of them. CLAUDE.md told contributors the guard script “exits 1 on any unguarded site” — true, and it still merged green when it didn’t, because nothing ran it. The documentation described a gate that existed only as prose.

All four now run in a new gate-scripts job in .github/workflows/ci.yml, together with the three --self-test batteries, on ubuntu-latest, in about three seconds of work.

A separate job rather than a step in build-and-test, for a reason beyond speed. The obvious argument is that a pure-Python check should not wait ~6 minutes behind a Swift build to say a symbol name is misspelled. The load-bearing one is the status check: build-and-test is red branch-wide on any refactor/** branch carrying a kernel patch newer than Package.swift’s pinned xcframework (#585), so a gate folded into that job would be red for a reason that has nothing to do with it — indistinguishable from having no gate at all. Linux rather than macOS because none of the four needs Xcode, OCCT or a build, and a macOS runner bills ten times the minutes for the identical result. Python is pinned at 3.12 rather than taken from the image: these gates parse Swift and C++ with regexes, and a runner-image Python bump quietly changing a verdict is the exact failure mode they exist to prevent.

Each script’s --self-test runs alongside its real invocation. A detector that reports “all clear” because it is blind looks exactly like one reporting “all clear” because the tree is clean, and this branch shipped three gate scripts that were confidently wrong — #618 (the guard checker saw one of the five ways this bridge reaches a handle), #624/#630 (the index checker called seven correct entries misfiled), #626 (the drift it was written to catch was live in the tree). Two of those had self-tests with holes. Running the fixtures in CI is what keeps the gate from rotting into vacuity while still exiting 0.

Every step after the first carries if: '!cancelled()', so one failing gate does not hide the other three; without it a contributor fixes them one CI round trip at a time. !cancelled() rather than always() so the workflow’s cancel-in-progress concurrency still takes effect.

count-operations.py gains the docstring line its three siblings already had. It was always a gate — return 0 if (readme_n == derived and apiref_n == derived) else 1 — but nothing said so, so it read as a release-time reporting tool, which is the only way it was ever used. Its counts had drifted on this branch before (#625’s own scope note).

It also now exits 2 on an unrecognised option instead of silently ignoring it. This one is a trap this PR itself arms: the other three gates all take --self-test, and CI pairs each self-test with its real run, so “seven invocations, self-test beside gate” becomes the house pattern in two places — and the natural thing to write when extending that list is count-operations.py --self-test, which was accepted, ran the ordinary report, and passed forever. The first fix was a docstring warning, which is the wrong shape of fix for an issue whose entire premise is that prose describing a gate is not a gate. Exit 2 matches the siblings’ “cannot run” status (they use it for a wrong working directory) so it is distinguishable from a real failure, and it also stops --fi silently reporting when --fix was meant.

An opt-in pre-commit hook, not an installed one. Scripts/git-hooks/pre-commit runs the same seven invocations locally, for the case CLAUDE.md actually addresses: a contributor mid-change, not a reviewer. It is enabled deliberately with a symlink into .git/hooks (or core.hooksPath, which replaces the hooks directory wholesale rather than adding to it — documented, because that silently disables any hook a contributor already has). The rejected alternative was auto-installation — a bootstrap script or SwiftPM plugin writing .git/hooks/pre-commit on first build. It was rejected because it changes when a contributor’s commits succeed without them asking, and its failure mode is a commit refused by a hook they did not know existed and cannot find in the tree. The hook runs the same seven invocations flag for flag. It first ran the three real gates with --quiet, which is exit-status-only, so it named the failing gate and then printed nothing about where — a fabricated index entry got you FAIL: check-bridge-index.py where CI names OCCTBridge.h:66. The flag was redundant anyway, since the runner already buffers output and only prints it on failure. The reason that survived the first round of proof is worth recording: the hook was proven with count-operations.py, the one invocation that had no --quiet and therefore the one case that could not exhibit the defect. A proof that exercises only the case immune to the bug is the same shape as the vacuous self-tests this batch keeps finding — the re-proof breaks all three of the previously---quiet gates individually and confirms each now prints its site.

Three ways the hook can still diverge from CI, all documented in it rather than closed: it checks the working tree rather than the staged snapshot, so a partially-staged commit can pass it and fail CI; it runs whatever python3 is on PATH while CI pins 3.12; and it warns and exits 0 if python3 is missing, so “the hook passed” can mean “the hook did nothing”. All three resolve the same way — CI decides, and it runs on every push regardless.

The install instruction was also wrong for this repo’s normal working mode: ln -s ... .git/hooks/pre-commit fails with “Not a directory” in a linked worktree, because a worktree’s .git is a file, and almost all work here happens in .claude/worktrees/*. The hook body was already worktree-correct (cd "$(git rev-parse --show-toplevel)"); only the instruction was not. Both the hook header and CLAUDE.md now give the worktree forms.

Verified by breaking each condition and confirming the gate catches it. Fabricating an index entry (OCCTShapeBoxNope) took check-bridge-index.py 0 → 1; deleting the IsNull() from a guarded bridge opener took check-null-handle-guards.py 0 → 1; editing a restated default in docs/reference/ took check-docs-defaults.py 0 → 1; editing README’s headline count took count-operations.py 0 → 1. All four returned to 0 on restore. The job is pinned to actions/checkout@v7 + actions/setup-python@v7 (both using: node24) rather than the @v4 its sibling jobs use, so it does not newly introduce a Node 20 deprecation annotation — those are emitted per job, so this job’s pins decide this job’s warning. Bumping the other two jobs is #648.

What this does not do: the repo has no branch protection and no rulesets, so a red gate-scripts is a visible red X that does not block a merge. Making it a required check is #649, and it is the one check in the repo that can be required without a caveat — unlike build-and-test it needs no OCCT, no build and no xcframework, so #585’s pinned-kernel mismatch cannot make it red.

Seven entry points indexed sub-shapes by occurrence while their consumers used the deduplicated map (#613)

#541 put sub-shape indexing on one enumeration, TopExp::MapShapes — one entry per distinct sub-shape, TopoDS_Shape::IsSame, orientation ignored. Seven entry points stayed on a bare TopExp_Explorer, which yields one entry per occurrence. A plain 10 mm box has 24 edge occurrences over 12 edges and 48 vertex occurrences over 8 vertices, because every edge is reached once per adjacent face — so the two enumerations disagree on any ordinary solid, not only on an exotic one.

The end-to-end failure is the composition this branch’s own documentation recommends. Shape.filleted(edges:radius:) carries the snippet bracket.filleted(edges: bracket.concaveEdges(), radius: 3). edgeConcavities() sizes its buffer from edgeCount and zips the bridge’s answer against edges(), but the bridge filled it per occurrence, so every label past the first repeat landed on the wrong edge. Measured on an L-bracket (two fused boxes, inner corner at x = 10, z = 10, map edge 27):

So the recommended one-liner filleted an empty list. Measured on base, filleted(edges: [], radius: 2) returns nil — it reported failure, not success. The harm is not a silent wrong answer but a misattributed one: a nil from a fillet reads as “the fillet failed”, and nothing pointed at the edge selection as the cause. On the fix it returns a shape, 28034.3 mm³ against the bracket’s 28000.0.

The six named sites, plus one the issue and its audit both missed:

Meshing is the one site where the two enumerations pull opposite ways, and it uses both. Triangle winding is set by the face’s orientation as it occurs in the parent (if REVERSED swap(n2, n3)), so converting it to the map would have kept only the orientation a shared face was first seen with — #614’s defect one level down. Measured on a BRepAlgoAPI_Splitter cut of a 20×10×10 block at x = 10: 12 face occurrences over 11 distinct faces, exactly one face present in both orientations, and the map stores it FORWARD. Meshed off the map the shared wall emits 2 triangles wound +x and 0 wound −x — the upper solid’s floor simply absent. The new occtForEachOrientedFace hands out both from one traversal: the occurrence for its winding, and that occurrence’s index in the enumeration faces() reads. FindIndex is the IsSame lookup, so a REVERSED occurrence resolves to its FORWARD twin’s index and both sides of a shared wall carry the one index that names it.

OCCTPolyMergeNodes is deliberately NOT converted, and is now documented and pinned as such. It emits no index, and the reversed flag it derives per occurrence goes straight to Poly_MergeNodesTool::AddTriangulation. Deduplicating it would add a shared wall once and lose the other solid’s side (measured: +x 2, −x 0). A regression test fails if a later sweep converts it.

The audit’s own verdicts were re-derived rather than taken on trust, and one was overturned: site 6 was recorded as “already on the map bridge-side”, which is true of the faceIndex argument and not of the Edge.index on the way out — the issue’s actual complaint, and a live defect. Sites 1-4 were confirmed safe to read off the map by measurement rather than by reading headers: every consumer was handed both orientations of every box edge (12 pairs) and vertex (8 pairs) and gave an identical answer, 0 differing — BRepOffset_Analyse::Type’s interval list, BRepExtrema_ExtCC’s IsParallel/NbExt/SquareDistance/ParameterOnE1/PointOnE1, the full BRepCheck_* status list, and BRep_Tool::Range + LocOpe_SplitShape::DescendantShapes. That matches what the headers predict (BRepOffset_Analyse.hxx:173, LocOpe_SplitShape.hxx:89-90, BiTgte_Blend.hxx:202 are all TopTools_ShapeMapHasher-keyed, and that hasher’s equality operator is IsSame, TopTools_ShapeMapHasher.hxx:35-38) — but the headers are the reason to check, not the check.

The BRepCheck WIRE and SHELL spellings go through the same converted helper, and a plain box has no wire or shell occurring twice, so the first pass could not exercise them. Six further fixtures were built for exactly that — compound{solid, solid.Reversed()}, and the same for a shell, a face, a wire, an open (invalid, non-closed) wire, and a fused two-body solid — giving 26 WIRE pairs and 4 SHELL pairs, BRepCheck identical across orientation in every one, 0 differing, invalid geometry included. Their index domain does move, which is the point of the conversion and is recorded in SEMVER.md: on compound{solid, solid.Reversed()} the WIRE enumeration goes 12 occurrences → 6 distinct.

This was not a complete sweep of the per-occurrence idiom at the time. Shape.nbEdges / nbVertices / nbFaces returned per-occurrence counts (a box answered 24 and 48 against edgeCount 12 and vertexCount 8; a split compound’s nbFaces was 12 against faceCount 11) while their own published docs asserted the deduplicated answers, filed separately as #651 and resolved below, by deprecation rather than by repointing in place, since all three are pure duplicates of edgeCount/faceCount/vertexCount with no index or orientation dimension of their own. OCCTShapeFixEdgeSameParameter and OCCTShapeFixEdgeVertexTolerance also document “number of edges fixed” while counting explorer occurrences; that one is source-visible but unmeasured (a box returns 0 either way), so it is recorded here as a candidate rather than converted on a pattern match.

Bridge-only plus two Swift wrappers; no kernel patch and no OCCT.xcframework rebuild. OCCTLocOpeFindEdges and OCCTLocOpeFindEdgesInFace gained an optional outIndices parameter. Index-value changes are recorded in SEMVER.md. Tests: Tests/OCCTTopologyTests/Issue613IndexContractTests.swift and Tests/OCCTMeshTests/Issue613MeshIndexContractTests.swift, 25 tests, each proven to catch its own site by reverting that site alone.

nbEdges/nbFaces/nbVertices are deprecated in favour of the counters they duplicated (#651)

Shape.nbEdges, Shape.nbFaces and Shape.nbVertices counted bare TopExp_Explorer occurrences (OCCTShapeNbEdges/NbFaces/NbVertices, OCCTBridge_Topology.mm), the same gap #613 closed for its seven entry points, while this project’s own reference docs always documented the deduplicated answer: docs/reference/Document-Completions.md asserted box.nbEdges // 12 and box.nbVertices // 8, not the 24 and 48 the implementation actually returned. Measured on a plain 10 mm box:

nbFaces agreed with faceCount on the box (no face is shared within one solid), and diverged only on a shape with a shared face: 12 against 11 on a two-solid split compound, reproducing #613’s own faceIndex measurement.

Confirmed by the Cluster A census (#664, Scripts/repro/cluster-a-subshape-enumeration/), run specifically to settle this question before any of #638/#642/#651 started: all three are pure occurrence duplicates of edgeCount/faceCount/vertexCount in every fixture measured, with no index, no orientation dimension, and no consumer that reads one and not the other. That is a different shape from #613’s seven sites, which addressed an index fed into another entry point and had no existing correctly-valued sibling to fall back on.

Decision: retire the duplicate spelling, not repoint it in place. Following the precedent #536 set for removeFeatures(faces:)/defeature(faces:) (two public names driving one operation, the newer forwarded and deprecated) rather than #541/#568/#613’s own precedent (repoint the raw value, because those sites had no existing sibling to rename to). Repointing nbEdges/nbFaces/nbVertices in place and keeping both names was considered and rejected: once the value agrees there is nothing left to distinguish the two spellings, which recreates the exact duplication #490/#491/#492 and #536 diagnosed elsewhere in this codebase.

All three are now @available(*, deprecated, renamed:), forwarding to edgeCount/faceCount/ vertexCount respectively, so the value is correct on the way out even though the spelling is retired. The now-orphaned bridge functions OCCTShapeNbEdges/OCCTShapeNbFaces/OCCTShapeNbVertices are deleted, following #506’s precedent for an orphan with no remaining Swift call site (OCCTBridge is a target, not a product, so nothing depends on the C symbol surviving). Recorded as a SemVer exception in SEMVER.md, since the returned value changes even though the build does not break.

Tests: Tests/OCCTTopologyTests/Issue651DeprecatedCounterTests.swift, pinning the corrected value against edgeCount/faceCount/vertexCount on a box and on a shape with a shared face, each proven to catch its own regression by reverting that one counter back to an occurrence walk.

docs/reference/Document-Completions.md, Edge.md, Selection.md and Shape-Features.md updated to match; docs/reference/Document-Completions.md was the page whose own asserted contract this issue was filed against.

The null-handle gate was blind to four of the five ways this bridge reaches a handle (#618)

Scripts/check-null-handle-guards.py printed “All bridge functions guard the geometry handle as well as the wrapper pointer” and exited 0. Its use-detector matched param->field and nothing else, so every site that reaches the handle through an indirection was invisible to it, and this bridge uses four: a cast (reinterpret_cast<OCCTSurface*>(ref)->surface, static_cast, (OCCTSurface*)ref), a pointer alias (auto* s = (OCCTSurface*)surface; ... s->surface), a handle alias (auto& surf = ...->surface;, and the by-value Handle(Geom_Surface) w = ...->surface; copy), and a shared bridge helper. Casts are now normalised away before the walk, aliases are followed, and the detector scores 6/6 on fixtures the old one scored 1/6 on.

The fourth form cuts the other way, and is why the fix is not just “teach it the cast spelling” (#624/#630’s lesson, one issue earlier: a sibling gate that had been taught indirection badly was confidently wrong about seven correct entries). OCCTGeomConvertCurveToAnalytical and occtSurfToAnaSurfResult hand their handle to occtCurveToAnalytical / occtSurfaceToAnalytical, both of which open with if (curve.IsNull()) return false;: checked, just one call frame away. A detector taught forms 1-3 and not form 4 reports both as defects. It now recognises a bridge helper that IsNull()-checks the parameter it is handed as a guard in its own right.

54 candidate (function, argument) pairs across 39 functions (the old detector found 1), of which 21 needed a guard and 33 were cleared by measurement. The issue’s own list of seven suspected-unguarded sites was partly wrong, and measuring first is what caught it: OCCTGeomLibToolParameter3D and OCCTGeomLibToolParameter2D reach GeomLib_Tool::Parameter, which returns false on a null handle, and OCCTApproxSameParameter reaches Approx_SameParameter, which raises a catchable Standard_Failure the function’s own catch (...) already turns into the same false a guard would return. Three of the seven needed nothing. The other four did, along with eleven sites the issue never named.

Guards added to 16 functions (21 (function, argument) pairs): OCCTLocalAnalysisCurveContinuity {,Flags}, OCCTLocalAnalysisSurfaceContinuity{,Flags}, OCCTSplitCurve3dContinuity, OCCTSplitCurve2dContinuity, OCCTConvertCurve2dToBezier, OCCTSplitSurface{Continuity,Angle,Area}, OCCTGeomTools{Curve,Curve2d,Surface}SetWrite, OCCTProjLibProjectOnSurface, OCCTGeomFillNSections{,Info}. Each returns the fallback its surrounding catch (...) already returns. The remaining 33 pairs (23 functions) are recorded in the script’s ALLOWED table, each with the measured reason it does not need one; four of those are not OCCT calls at all (OCCTBRepGraphRepSet* store into a bridge-owned side registry whose else branch deliberately stores a null handle to clear the slot, and BRepGraph_EditorView::SetPCurve documents the null handle as its clear-the-binding contract).

OCCTGeomToolsCurveSetWrite is the one guard here that measurement did not demand: GeomTools_CurveSet::Add guards its own handle, so a null cannot crash it. It is guarded anyway because the alternative was worse than noise. Add silently drops the null, Write() then emits a set with fewer curves than the caller passed, and Curve3D.serializeCurves/deserializeCurves is a round trip, so the surviving indices stop matching the input array. Guarding it also keeps the three identical GeomTools_*SetWrite writers from diverging three ways on null handling, which is the divergence shape this audit exists to remove.

Scripts/repro/556-null-handle-guard-sweep grew from 35 entry points to 57: the 22 the pre-#618 walk never reached, so nobody had measured them. 36 of 57 are now uncatchable signals (was 24 of 35). Along the way: GeomTools_CurveSet::Add guards with return (C.IsNull()) ? 0 : myMap.Add(C) while GeomTools_Curve2dSet and GeomTools_SurfaceSet contain no IsNull anywhere and both crash. An upstream inconsistency between three copies of the same writer.

The script also gains --self-test, matching check-bridge-index.py. It proves both failure modes by injection: six fixtures that must be reported (one per indirection form, including the plain param->field form, so the fix is provably additive) and six that must not (including a guard reached only through a by-value Handle copy, and one only through the shared helper). No public API change; behaviour changes only for inputs no bridge call can currently produce.

Breaking: continuityOrder is retired, because a warning did not stop the numbers changing underneath it (#619)

Source-breaking. Curve3D.continuityOrder, Curve2D.continuityOrder and Surface.surfaceContinuityOrder are now @available(*, unavailable). Any use is a compile error carrying the migration in the diagnostic.

Nothing about the values changes here. They already changed, in #485:

The old scheme was OCCTSwift’s own invention. It matched neither GeomAbs_Shape nor its own doc comment, and disagreed with the continuity property on the same curve for every class except C0. Reporting the real ordinal is right and is not reverted.

What #485 could not do with a deprecation attribute is stop the change being silent. The type stayed Int and the name stayed the same, so every call site kept compiling:

// Before: `2` was C2, so this rejected a C1 curve.
// After:  `2` is C1, so a merely tangent-continuous curve reaches a path assuming curvature.
if curve.continuityOrder >= 2 { useAsC2Spline() }

// And this, the analytic fast path, became unreachable rather than wrong — silently dead code.
if curve.continuityOrder == 99 { useAnalyticFastPath() }

A warning does not stop compilation, and neither outcome above is one a warning prevents: the first is a wrong geometric answer produced silently by a build that succeeded, the second is a branch that quietly stopped being taken. Retiring the spelling turns both lines into errors that name the old encoding, the new one, and the replacement.

There is no error sentinel any more, and that is its own migration hazard. The retired encoding signalled failure out of band, returning -1 from its default: branch and for a null or unreadable handle. continuity returns 0 in the same situations, and 0 is an ordinary C0 measurement. So if continuityOrder < 0 { handleError() } migrates to a branch that can never be taken, and an unreadable curve now reads as a genuinely C0 one. There is no in-band way to tell them apart — check the handle before asking.

Migration — both replacements predate this change and neither is new API:

// A continuity floor. Takes the request vocabulary by type, so the mismatched
// constant cannot be written at all.
if curve.continuityClass.satisfies(.c2) { useAsC2Spline() }

// The analytic fast path.
if curve.continuityClass == .cN { useAnalyticFastPath() }

// A raw ordinal, if that is genuinely what you want — but it is the *new*
// ordinal, so re-check the constant you compare against.
let ordinal = curve.continuity

continuity is unchanged in value: it read the real ordinal before the refactor and still does. Only its doc comment was wrong, which is what let the two spellings disagree unnoticed.

• unavailable rather than deletion. The declaration stays so the compiler can explain itself; deleting it outright would say only “has no member continuityOrder”. Follows EvolvingFilletEdge.init(edgeIndex:) (#520), the same response to the same shape of hazard. The operation count drops by 3 (4,301 → 4,299) — Scripts/count-operations.py does not count a retired spelling as a wrapped operation, and no new API was added.
• Tests: Issue619ContinuityEncodingTests (OCCTCurveTests), Issue619Curve2DContinuityEncodingTests (OCCTGeom2dTests) and Issue619SurfaceContinuityEncodingTests (OCCTSurfaceTests) pin the encoding against geometry whose class is known by construction, and assert the trap is live: a C1 BSpline satisfies continuity >= 2 while continuityClass.satisfies(.c2) correctly refuses it. The #485 suites had their continuityOrder assertions moved onto continuity/continuityClass.
• Recorded as a break in SEMVER.md.

The index gate was reporting seven correct entries, because it could not read a template helper (#624)

Scripts/check-bridge-index.py exited 1 with 0 stale, 7 misfiled, every one of them on the GCPnts_AbscissaPoint line of OCCTBridge.h’s cross-reference index, and every one reported as no bridge function reaches this class. The reading that fits — #477, #549, #600 and #603 did progressively move arc-length measurement off GCPnts_AbscissaPoint — is that the entries had drifted and needed re-filing. They had not.

Adjudicated per symbol, by reading each body and following the call path rather than the name:

All seven still reach the class. occtArcQuadrature (OCCTBridge_Internal.h) is singleSpan ? GCPnts_AbscissaPoint::Length(...) : CPnts_AbscissaPoint::Length(...), so #603 added a second class to these functions rather than replacing the first — which is what the index already said, on the CPnts_AbscissaPoint line directly beneath.

The defect was the checker’s. It classifies each brace-balanced definition by searching its signature for struct|class|union|namespace|enum, and a template <class TheAdaptor> head satisfies that, so the helper was filed as a type named TheAdaptor instead of as a function. A type is only ever reached by a function that names it, and none do, so the helper-indirection chain was cut at its first template link and the class looked unreached. The tell was that OCCTBridge_Modeling.mm’s one template <typename BoolOpT> helper parsed correctly: typename is not in that alternation, class is. without_template_head now strips the head before classification; a template <class T> struct Foo is still read as a type.

The nine arc-length helpers are what the misfiled entries pointed at, but they are not the whole of it. Every template <class ...> definition in the bridge was affected — 15 of them, filed under 6 bogus type names:

Across the whole bridge, 34 OCCT-prefixed functions’ reach sets change: 31 grow, and 3 shrink. The shrinking direction is the one that is easy to miss — the old parser was also false-widening. types['T'] was a real bucket holding everything occtWriteKnotSplits reaches, and the wrapper-type resolution step hands a function the contents of any type it names, so OCCTGeomFillGuideTrihedronACD0, OCCTGeomFillGuideTrihedronPlanD0 and OCCTWireGetCurvePointAt each inherited that bucket purely for containing a local identifier T. Fifteen junk names apiece. No index verdict depended on any of this — the run went 0 stale, 7 misfiled to 0 stale, 0 misfiled and nothing else moved — but a direction check is only as good as its reach sets, so the record should say what actually moved rather than only the part that was being complained about.

No bridge or Swift source changed — the index entry was right, and the note added to it records that the seven reach the class through the helpers rather than by naming it, so the next reader greps the right thing.

Two holes in the script’s own --self-test, both of which had to be closed for #625 to gate on it:

• DIRECTION_TEST did prove the misfiled mode was caught, but all four of its cases named a single symbol, so the entry-level rule misfiled_entries explicitly warns against — “at least one of these reaches the class”, which lets one wrong symbol hide behind correct neighbours — passed the whole suite 16/16 when injected. A fifth case mixes a correct symbol with a wrong one and pins which symbol must be blamed.
• INDIRECTION_TEST covered the plain inline helper but not the template one, so nothing failed when the parse above broke. A case for it now asserts the GCPnts_AbscissaPoint line stays clean.

Both were verified by injecting the regression they describe and confirming 17/18. The suite is 18/18 and the gate exits 0.

A single iso-row stops being documented, accepted, and then silently refused (#620)

Three layers disagreed about the minimum count Surface.drawMesh(uCount:vCount:) accepts. The doc comment said “at least 1”, the Swift guard (Sampling.gridTotal, default atLeast: 1) accepted 1, and the bridge returned 0 for anything under 2. The wrapper’s guard n == total turned that 0 into SurfaceGrid.empty, so drawMesh(uCount: 1, vCount: 20) — in range by its own documentation — came back empty, and the caller had no way to tell “you asked for something unsupported” from “this surface has no mesh”.

The bridge was the layer that was wrong, which is not what the issue expected (“a mesh of one row has no quads”). Measured against the kernel first: despite the name OCCTSurfaceDrawMesh does not mesh anything. There is no BRepMesh, no triangulation and no quad, just a uniform walk of the sampled range calling Geom_Surface::D0, and a single (u, v) is a valid OCCT evaluation — a 1 × 20 iso-row off a sphere is 20 finite points. The 2 was never OCCT’s rule, it was this function’s own divisor: i / (uCount - 1) divides by zero at count 1. And the NaN that produces is worse than a throw would have been, because D0 does not throw on NaN, it returns NaN coordinates silently. Every other member of the same U-major grid family already accepted 1 — OCCTSurfaceDrawGrid guards no count at all, EvaluateGrid and EvaluateGridD1 guard <= 0 — so drawMesh was the family’s sole outlier. OCCTSurfaceDrawGrid, forty lines above in the same file, samples the same bounds and had spelled that divisor defensively since b1cd75d, the commit that introduced both functions. The bound moved to 1 rather than disappearing: below 1, and products past Sampling.maximumSampleCount, are still rejected at the Swift boundary before any allocation, which is #558’s contract unchanged.

That divisor is now occtUniformParameter in OCCTBridge_Internal.h, next to occtSurfaceGridIndex and for the same reason: it had been open-coded ten times in OCCTBridge_Surface.mm in four different spellings, and #620 is what a single copy written without the guard costs. Sharing the expression is what stops an eleventh loop re-deriving the unguarded form.

Nine of the ten are bit-identical substitutions. The tenth reassociates: the Gordon network builder’s f + (l - f) * ((double)j / (guideCount - 1)) becomes ((l - f) * j) / (guideCount - 1), and across ten realistic [FirstParameter, LastParameter] ranges 25-33% of cases differ by 1-2 ulp (≤ 4e-15 over the whole span, exactly 0 on this repo’s own Gordon fixture). One structural consequence beyond the magnitude: the old form always landed the last sample exactly on f + (l - f), while the new one can land 1 ulp past LastParameter (4 cases of n = 2…60 on a 0..2π profile). Harmless here, because the builder SetNotPeriodic()s the curves first so Geom_BSplineCurve::D0 does not throw just outside the range, but it is a boundary the old expression structurally could not cross, so it is recorded at the site rather than left for someone to rediscover.

Three open-coded lines remain, across two sites, both deliberately. OCCTGeomFillAppSurf’s (double)i / (count - 1) is unguarded — the exact #620 shape — but chasing it turned up a separate, larger defect (Surface.appSurf(curves:) segfaults on a single curve regardless of the parameter value, so it is a missing arity guard rather than a divisor bug), which is filed on its own; converting the divisor would not fix it and would muddy that fix. OCCTGeomFillCoonsPatchEval’s two lines are a different contract, not the same expression: their single-sample branch is 0.5, the patch midpoint, where every other site’s is the low end. The helper’s own doc says so, so the next sweep does not fold them in on shape alone.

Recorded, not fixed: the Gordon family has no behavioural test coverage at all. All five Gordon tests assert only nil-ness and status ordinals — not one checks a point, pole, degree or bound — and networkSurfaceBuildsOrReportsStatus, the only test reaching the changed line, accepts any status but .notStarted; on the repo’s own makeNetwork() fixture the builder returns KnotAlignmentFailed, so it never builds a surface. Nothing in the repo would have caught the 1-ulp change above, or one many orders of magnitude larger. Filed separately.

A second wrong claim, caught reviewing the first fix. The new contract sentence said uCount: 1 is “the single iso-row at uMin”. That holds only for a bounded surface: the bridge clamps infinite bounds to ±100 before deriving parameters, so on a plane domain.uMin is about -2e100 while the single row sits at -100. Same defect class as #620 itself — a claim true of the fixture in front of you and false in general — so the docs now name the sampled range (the domain, with infinite bounds clamped) rather than the domain, and a test pins the clamped value on an unbounded surface. The first version of that test checked only finiteness, which passes under either reading and so could not contradict the doc.

The sibling site keeps its 2. OCCTSurfaceCreateBezier carries a visually identical uCount < 2 || vCount < 2, and that one is the kernel’s: a Bezier’s degree is its pole count minus 1 and must be at least 1, so Geom_BezierSurface raises Standard_ConstructionError on a single-pole direction (measured; 2 × 2 builds a bilinear patch). Surface.bezier(poles:weights:) already guarded the same bound, so that site had no three-layer mismatch at all — only a doc that was silent about the bound rather than wrong about it. Both look-alike guards now say in a comment which kind they are, so the two are not “made consistent” by a later sweep. The accompanying test pins the public contract only, and says so: relaxing the bridge guard alone leaves it passing, because Surface.bezier rejects in Swift and never reaches the bridge — and if it did, OCCT would throw and catch (...) would return nullptr, so nil comes back either way. No black-box test can separate those two layers, and claiming otherwise would be the same kind of overstatement this entry is about.

The reference page that kept documenting the continuity default #491 replaced (#626)

Two pages under docs/reference/ restate Surface.approxWithDetails. #491 flipped both of its continuity defaults from C1 to C2 — so that it and Surface.approximated stop fitting to different smoothness when neither is given a continuity argument — and updated Surface.md. Shape-HLR-Geom.md went on declaring uContinuity: ParametricContinuity = .c1, vContinuity: .c1.

That page is in this branch’s changed set: its quasiUniformParameters entry was rewritten thirty lines below the stale default. A reader following it and omitting the arguments expects a C1 fit and gets a C2 one, which per #572 is not cosmetic — continuity is one of the inputs deciding how far the fitted surface moves. It also reinstated, in the documentation layer, the exact divergence #491 existed to remove.

The interesting part is not the one-line correction. A per-type reference page that restates a signature is a copy, and this tree holds 3427 such restatements. Scripts/check-docs-defaults.py parses every one of them, matches it to its declaration in Sources/OCCTSwift, and compares them position by position: 1460 defaults compared, 2 drifted, both of them this one.

A default drifts in three shapes, and all three fail the run, because a gate that reports a defect while exiting 0 is not a gate. The literals can differ. The docs can state a default the source does not have, so a required argument reads as optional. Or the source can state one the docs omit — which is also how a source-side addition hides behind an unchanged page, and it is the reason the comparison covers restatements carrying no defaults at all rather than only the 876 that do. (--lenient drops that third shape to a warning, for a tree still paying it down; the other two fail either way.) Layout is not drift: SIMD3(0, 0, 1) and SIMD3(0,0,1) compare equal.

All of that depends on comparing against the right declaration, because several share one name and label list: writeOBJ(to:deflection:) is both Document.writeOBJ (deflection 1.0) and Shape.writeOBJ (0.1). Resolving that by accepting agreement with any candidate cannot invent a failure, but it can swallow one, and it did — twice, at two different depths. First across types, letting a page state Shape.writeOBJ’s default for Document.writeOBJ and exit 0. Then, once a hint selected the right type, across the overloads within it: deprecating a method by keeping its old signature verbatim, defaults included, is the ordinary way to deprecate, and the stale page went on matching the retained twin. Both are the #626 shape walking through the gate built for it.

So the owning type is resolved from the nearest heading’s qualifier, then outward through the enclosing section headings (CurveAdaptors.md holds ## WireCurve and ## EdgeCurve, each with an identically titled ### points(count:)), then the page filename — and where that still leaves two candidates disagreeing about a default, the restatement is reported as unverified and fails, rather than being quietly decided by whichever one happened to match. A twin that merely lacks a default is still disambiguated by the doc’s own defaults, so the ordinary deprecation shape stays quiet. On this tree: 2713 resolved uniquely, 504 by heading, 163 by filename, and 0 unverified.

Worth stating exactly, rather than leaving it implied. 129 doc sites across 67 signature groups still hold more than one candidate after narrowing, but 108 of those are skipped upstream — neither side states a default, so there is nothing to compare — and only 21 sites across 9 groups reach the ambiguity guard at all. Of those, 0 disagree on a value, 4 have a twin merely lacking one, and 17 agree outright; the 17 are protected by the rule rather than by luck, since any later divergence between them reports unverified. The carve-out is narrower than “safe”: a single-sided acquisition — one overload gains a default, a bare twin remains, and the page states none — stays quiet. That is the mirror of the documented twin exemption, it can only ever miss a source_only -class defect, and it is strictly better than before this change, when all 108 were not examined at all.

Exit status is 1 on any drift, on an unverified restatement, or on growth in the unmatched bucket — a restatement stops being compared the moment its labels stop matching, so an unpinned bucket there would absorb a rename silently. --self-test runs a 13-case battery in memory, covering each shape above and each mechanism the gate depends on; every case was checked by reverting the mechanism it guards and confirming the battery goes red, because a case that passes with its subject removed is not a test. It is committed because three gate scripts on this branch have now shipped confidently wrong, and an uncommitted battery regresses without saying so. Nothing runs this script yet — wiring the gate scripts into CI is #625, whose own note warns against installing a gate that passes unconditionally.

ContinuityClass.isParametric was flagged as the same root cause and is the same shape of miss. #623 fixed satisfies(_:) and gave derivativeOrder an explicit warning that its nil means “no parametric order”, not “meets no floor”, because guard let o = derivativeOrder else { return false } reproduces #623 verbatim. isParametric is that property’s structural sibling with the identical trap — it is false for the geometric classes, so guard measured.isParametric ahead of a .c0 check reports a tangent-continuous curve as not even connected — and the warning was added to only one of the two. It now carries it as well, pointing at satisfies(_:) the same way.

The one grid layout finally covers the third type holding a grid (#617)

#486 declared U-major (occtSurfaceGridIndex, iu * vCount + iv) THE surface-grid buffer layout of this codebase, and gave SurfaceGrid / SurfaceGridD1 an .at(u:v:) accessor for it, precisely so two bridge functions could not go on writing opposite layouts while each header called its own “row-major”. A third type holding the same shape of buffer was left out of that sweep.

BRepGraph.FaceGridSample hands back four parallel flat buffers (positions, normals, Gaussian and mean curvature) that OCCTBRepGraphSampleFaceUVGrid wrote transposed, iv * uSamples + iu. The Swift type documented no layout and offered no accessor, so the only guidance a caller had was the convention #486 had just declared, which was the wrong one for this one type.

Two things make this worse than a plain inconsistency. docs/reference/BRepGraph-Editor-Identity.md already documented the U-major index (index = u * vSamples + v) for this type, so the bridge was contradicting its own published reference page, not just a sibling type. And the failure is not uniform: a caller reading with the layout-conforming stride gets a silent wrong answer at every aspect ratio (a normal or a curvature attributed to the wrong place on the face, no trap), while the neighbouring slip of using the wrong count as the stride (u * uSamples + v) stays in range on a 3×10 grid and runs off the end of the same 30-element buffer on a 10×3 one. #617’s own report has these two expressions crossed; the arithmetic is now pinned in a test.

Converted the bridge to U-major rather than documenting the transpose, so the codebase keeps one rule, and routed it through the shared occtSurfaceGridIndex so the formula is not re-spelled at a third site. FaceGridSample gains the .at(u:v:) accessor its siblings have, resolving the index through the same shared Swift-side surfaceGridIndex, plus an explicit layout line and worked snippets on the type, the method and the reference page. OCCTBridge.h’s declaration now states the literal index instead of being silent.

No consumer depended on the old order. Every in-repo caller and all three ecosystem callers (PadCAMEngine’s PadCAMMLExport, OCCTSwiftScripts’ occtkit graph-ml and GraphML) sample a square grid and either map the arrays element-wise into a JSON payload or reduce them order-independently (a mean position/normal face signature), so none reads a specific (u, v). The observable change is limited to the order of the flat arrays those exporters serialize, which was never a documented contract on the emitted payload.

A tangent-continuous surface stops being reported as not even connected (#623)

ContinuityClass offers two ways to ask “is this at least X”, and they disagreed. satisfies(_:) short-circuited on the nil derivativeOrder that the geometric classes carry, returning false before it ever read the requested floor:

surface.continuityClass                  // .g1
surface.continuityClass.satisfies(.c0)   // false
surface.continuityClass >= .c0           // true

So a caller gating on “is this at least positionally continuous?” through the API the docs steer them to rejected every G1 and G2 result — surfaces smoother than the C0 ones it accepted.

The old justification, “a g1/g2 result is not a parametric guarantee at any order”, is right for C1 and above and wrong for C0. G1 entails G0 entails positional continuity, and positional continuity is exactly what C0 is; there is no parametrisation subtlety at order zero, a curve is either connected or it is not. The nil branch now floors at order 0 instead of failing unconditionally, so .g1/.g2 satisfy .c0 and still correctly refuse .c1 and above. derivativeOrder is unchanged — it still reports nil, because a geometric class genuinely has no parametric order; the floor lives in satisfies alone.

Sweeping the full 7×7 matrix of satisfies against >= found one more disagreement than the reported cell, and it is not a bug. Of the 49 (measured, required) pairs, 28 name a ParametricContinuity floor that both APIs can answer. Before: three disagreed — (.g1, .c0), (.g2, .c0) and (.g2, .c1). After: exactly one, (.g2, .c1), and it is correct. GeomAbs_Shape ranks G2 (3) above C1 (2), but curvature continuity does not entail first-derivative continuity, so the parametric floor rightly refuses what the ladder allows. That is a genuine difference in what the two APIs are for, not drift, and both doc comments now say so: satisfies(_:) tests a measured class against a requested parametric floor, </>= ranks two measured classes by their place in the ladder, and outranking is not entailing. The one exception is named in both.

A third contract in the same file, ContinuityAnalysis.holds(_:) and the GeomAbs_Shape-ordinal junction-analysis bitmask behind it, asks exact-class membership rather than a floor or a ranking and is deliberately untouched; a regression test pins that it stayed independent.

Both readings are OCCT’s own, not an inference: dox/user_guides/modeling_data/modeling_data.md says at line 1281 that C0 “is the same as G0 (geometric continuity), so the last one is not represented by separate variable”, and at line 1289 that “Geometric continuity (G1, G2) means that the curve can be reparametrized to have parametric (C1, C2) continuity”. The first is why a geometric class clears the C0 floor; the second is why it clears nothing above it, since the existence of a reparametrisation is not a promise about the parametrisation in hand. Both are now quoted in the satisfies(_:) doc, and derivativeOrder carries an explicit warning that its nil means “no parametric order”, not “meets no floor” — the hand-rolled guard let o = derivativeOrder else { return false } reproduces #623 verbatim.

Issue623ContinuityFloorTests (Tests/OCCTSurfaceTests/) carries the matrix sweep plus two monotonicity directions, and the tests are explicit about which of them actually guard this bug. Monotonicity in the requested order (whatever a class satisfies, it satisfies everything weaker) holds for any implementation shaped f(measured) >= required.rawValue, the buggy one included, so it guards a future rewrite that loses downward closure rather than a regression here. Monotonicity in the measured class (if a weaker measurement clears a floor, a higher-ranked one should too) is the invariant the unconditional false actually broke, and it does fail under the injected bug — 4 violations against the fixed code’s 1, that 1 being the documented G2/C1 cell, which violates it too and so is pinned rather than asserted away. The soundness direction (a floor check may be stricter than the ladder, never looser) passes vacuously under a too-strict implementation and guards the opposite failure mode: an over-correction that has a geometric class clear a floor the ladder never reaches. The matrix is what would have caught this; the single cell would not have. Issue485SurfaceContinuityTests had pinned the old answer as correct and is corrected.

Breaking: the nearest point on a curve, for the entry points #539 left behind, and the whole 2D side (#615)

#539 established that GeomAPI_ProjectPointOnCurve::LowerDistance() reports an extremum, which on a bounded curve is neither necessarily the nearest point nor necessarily present at all, and introduced occtNearestPointOnCurveRange — the minimum over ShapeAnalysis_Curve, every extremum in range, and both curve ends. Three entry points were converted. The shared helper behind three more was not, and its 2D twin was never touched.

So the two spellings of one question disagreed. Measured through the public Swift API on #539’s own repro geometry, a half circle of radius 5 over [0, π] queried from below at (0, -6, 0):

A caller seeding a trim or a split from nearestParameter landed on the opposite side of the arc from where projectPoint said the nearest point was. The two spellings disagreed about which point is nearest and about whether there is one.

Both defects, both dimensions, one helper each. occtNearestProjectionOnCurve3d now routes through occtNearestPointOnCurveRange; the new occtNearestPointOnCurve2dRange gives the 2D side the equivalent treatment.

The 2D candidate set is the extrema plus both ends, and cannot be more. ShapeAnalysis_Curve has no 2D projection — its Project overloads take Geom_Curve or Adaptor3d_Curve only, and its Geom2d_Curve members (FillBndBox, SelectForwardSeam, GetSamplePoints, IsPeriodic) do something else entirely. That is the “all extrema + the two ends” row #580 measured at 188/189 rather than the 189/189 the third source buys; the one case it misses is Extrema failing to converge on a BSpline, where an end then wins by a fraction of a percent, and there is no 2D-native second algorithm to break that tie. (A Geom2d_Curve could in principle be lifted into the z = 0 plane and run through the 3D ShapeAnalysis_Curve; not done, since that buys one case in 189 at the cost of a per-call curve conversion.)

Breaking: nil no longer means “no perpendicular foot”. A point past the end of a bounded curve is nearest to that end, and a circle’s centre is equidistant from every point on it; all of these now answer with a real parameter and a true distance. nil (and Point2D.distance(to:)’s .infinity) is left meaning what it means for the entry points #539 converted: no curve to answer about. Affects Curve3D.nearestParameter(to:), Curve2D.nearestParameter(to:), Curve2D.project(point:), Curve2D.project(_:), Point2D.distance(to:) and the deprecated parameterAtPoint/closestParameter spellings, which no longer have a reachable .nan case on a real curve. They stay deprecated for the reason they always were: no Double can carry a failure signal, because every value is a legitimate parameter on some curve.

Curve2D.allProjections(of:) still reports nothing where the other four now answer, and that is correct. It asks for the extrema, which has been a different question since #539, and on a bounded curve queried from beyond its end the honest answer is that there are none. Before #615 all five agreed only because the other four were asking the extrema question too.

Curve3D.locateNearestPoint: the fallback changed, the primary search deliberately did not. The primary reports the lowest-distance extremum inside a ±10% window around initParam. The guess bounds the window; it does not rank what is found in it, so the extremum returned is not necessarily the one nearest the guess — measured on a ramped sine BSpline, a guess of 90.9114 returns param 79.9751, 10.94 away, over an extremum 0.13 away at 91.0378, because the far one is closer to the query point (10.07 against 15.19); 22 of 46 multi-extremum windows behave so. The window is what makes the answer local, and a windowed minimum can still be a global maximum: with a guess of π/2 on the arc above it reports 11, and that is pinned by test.

Adding the window’s two ends to that minimum was considered and rejected — not because it would redefine initParam, which it would not, since the function already minimises over the window and the ends are all the change adds. It was rejected because (1) it does not make the function correct under its own name, answering 10.865697905689686 where the true nearest point is 7.8102 away, and (2) a window’s ends always evaluate, so the minimum would always be found and the fallback would become unreachable — deleting the one path in this function that #615 fixes. Making the search global outright would leave initParam meaning nothing and the function a duplicate of nearestParameter.

The full-range fallback is a different matter: it fires only when the window holds no extremum, at which point the function has already abandoned locality, so it must give the whole curve’s answer. Measured, a guess of 0 — sitting on the true nearest point — used to fall through and return the point diametrically opposite it (π/2, distance 11); it now returns 0 at 7.8102. A [3, 8] segment queried at (100, 0, 0) returned nil for every guess and now returns param 8, distance 92.

Bridge-only: no kernel patch, no OCCT.xcframework rebuild. Regression suites Issue615NearestParameterRangeTests (OCCTCurveTests) and Issue615Curve2DNearestPointTests (OCCTGeom2dTests), including a 2D-vs-3D cross-check on the same geometry in the z = 0 plane — the comparison neither side had, and the reason the 2D defect survived #539. Proved by injection: restoring both LowerDistance helper bodies fails 17 of the 32 tests across the five affected suites with 41 issues, and the test pinning the preserved windowed primary path keeps passing, as it must. The 2D sweep’s ground-truth anchor was separately proved non-vacuous by over-reporting the distance in the helper: 9 failures with abs(), 0 without it.

The 21 result-buffer capacities #558’s sweep never reached (#622)

#558 bounded 28 sampling entry points and introduced Sampling.capacity(_:) / Sampling.requested(_:atLeast:). A review found Shape.raycast(origin:direction:tolerance:maxHits:) with the identical footgun and named three more sites. Re-running #558’s own measurement against the current tree found 21, not 4 — and two of the four the review named do not survive it at all: MedialAxis.drawArc was already bounded by #558 itself, and both quoted Document.swift line numbers land on unrelated code. The named list was neither complete nor correct, which is the same lesson #558 recorded when its census said 14 and its measurement said 28.

The reason the sweep stopped short is a scoping one, not an oversight: #558 scoped itself to samplers, and these 21 are result-buffer capacities on picking, spatial search, projection, intersection, hatching, text conversion and directory listing. Same mechanism throughout — a caller-supplied number sizes a Swift allocation and is then cast to the int32_t the bridge takes its capacity in, so Array(repeating:count:) traps on a negative and Int32(_:) traps past Int32.max.

Measured one case per process, since a trap takes the whole harness down with it. 18 of the 21 are drivable from a standalone binary; all 18 failed at Int(Int32.max) + 1 — 2 aborted immediately with Fatal error: Not enough memory and 16 ground past a 40-second timeout on an allocation nothing can serve. 12 of the 18 also aborted on -1, inside Array(repeating:count:), before any bound could be consulted. The remaining 3 (Selector.pick’s three overloads) need a live selector and were converted on inspection, then covered in-process. After the fix all 18 return their documented value at both inputs.

The sites, by owning type: Shape.raycast, Shape.allDistanceSolutions, Shape.selfIntersectionPairs, Curve3D.extrema / .intersections(with:maxHits:) / .splitAtContinuity / .projectPointAll, Curve2D.splitAtContinuity, Surface.intersections(with:maxCurves:) / .projectPointAll, KDTree.kNearest / .rangeSearch / .boxSearch, Selector.pick (all three overloads), HatchPattern.generate, UnicodeUtils.convertFromUnicode, DirectoryIterator.list, FileIterator.list, and LogSample.sample.

The contract is #558’s, not a fifth one. 20 of the 21 are capacities: the algorithm decides how many results exist and the number only truncates, so they clamp into 0...Sampling.maximumSampleCount and an absurd capacity returns the same answer rather than an empty one. The exception is LogSample.sample(from:to:count:), whose bridge fills the buffer exactly — that is a request, so it rejects outside 1...ceiling rather than silently handing back 10 million values for a 10-billion request. Exactly the split #558 drew between Curve3D.drawAdaptive and MedialAxis.drawArc.

let box = Shape.box(width: 10, height: 10, depth: 10)!
let ray = (origin: SIMD3(0.0, 0, 20), direction: SIMD3(0.0, 0, -1))

// A capacity is clamped, so an unservable one still returns the real answer.
box.raycast(origin: ray.origin, direction: ray.direction, maxHits: 10_000_000_000).count
    == box.raycast(origin: ray.origin, direction: ray.direction).count   // true
box.raycast(origin: ray.origin, direction: ray.direction, maxHits: -1)   // [] -- used to abort

// A request is rejected, never silently coarsened.
LogSample.sample(from: 1, to: 100, count: 16).count                      // 16
LogSample.sample(from: 1, to: 100, count: 10_000_001).count              // 0, not 10,000,000

Two behaviour changes beyond “stops aborting”, both at a zero-or-negative count:

• Shape.allDistanceSolutions(to:maxSolutions:) returns [] rather than nil for a capacity of 0 or less. The bridge answers -1 for maxSolutions <= 0 and the old guard count >= 0 turned that into nil, so “no room was offered” was reported as “the measurement failed”. Every sibling in this set returns its documented empty value for no capacity, and nil is now reserved for an actual failure.
• KDTree’s three searches gain an effective result ceiling of 10,000,000. The bridge returns min(results.Size(), maxResults) with no truncation flag, so a caller who previously passed a huge capacity against a >10-million-point cloud and got a complete answer now silently gets 10,000,000 of them. The silence is pre-existing (there was never a “there were more” signal); the ceiling is new.

A separate, pre-existing defect surfaced while building the fixture and is not fixed here: Curve3D.extrema(with:maxCount:) SIGSEGVs (uncatchable) on two parallel curves at any capacity — measured at maxCount 2, 20, 100, 1e4, 1e6, 1e7 and Int32.max + 1, all signal 11, including the method’s own default of 20. The bridge’s own loop is correctly bounded by min(NbExtrema(), maxCount), so the crash is inside GeomAPI_ExtremaCurveCurve’s construction: the documented BRepExtrema_ExtCC parallel hazard, on the GeomAPI path. It has nothing to do with the count bound, and the regression fixture uses skew curves deliberately so that it tests the bound rather than the crash. Filed as #636.

Also measured, also not fixed here, for the same “do not invent a contract” reason — now filed as #640. The math solver/optimizer family has the same trapping shape, at 13 entry points in Sources/OCCTSwift/Document.swift: MathSVD.solve (:5699), MathJacobi.eigenvalues (:5744), MathHouseholder.solve (:5919), MathOptimizer’s solveSystem, minimize, minimizePowell, particleSwarm, globalMinimize, solveSystemNewton, minimizeNewton and gaussSetIntegration, and MathSolver.leastSquares (:14193) and .uzawa.

These are problem dimensions that must agree with the caller’s own matrix / startPoint arrays, not sampling capacities, and clamping a dimension to 10,000,000 would hand back a garbage-dimension solve rather than truncating a result set — so Sampling.* is the wrong tool and applying it would have been precisely the fifth behaviour #622 asked to avoid.

A consistency check against those arrays is not on its own the remedy, which is where an earlier draft of this note was wrong. A degenerate array satisfies the consistency relation exactly and still aborts:

MathJacobi.eigenvalues(matrix: [1.0], n: -1)   // matrix.count == n*n holds exactly: 1 == 1
                                                // still aborts: Can't construct Array with count < 0

The same holds for MathSVD.solve and MathHouseholder.solve. A positivity bound is needed as well. And MathSolver.leastSquares has no consistency check at all, so Int32(rows) / Int32(cols) drive an out-of-bounds read of matrix inside the bridge — memory unsafety rather than a clean trap, and the reason #640 is not merely a tidiness issue.

Regression suite: Tests/OCCTMiscTests/Issue622AllocationBoundsTests.swift, 13 tests covering all 21 entry points. They run in-process only because the fix is what lets them: before it, every assertion in them would have aborted the test harness rather than failing. They compare .count == 0 rather than reading .isEmpty, for the reason #558 recorded — Swift Testing prints the captured sub-expression on failure, and a regression returning 10 million results would print all 10 million of them.

Confirmed by injection, one bound at a time: with the ceiling removed from the bound it covers (and the lower bound left in place, so the edit still compiles and the injection is exactly “the ceiling is gone”), all 13 tests stopped passing — 12 aborting with signal 5 and raycast dying mid-run before it could report an assertion. Each was restored by exact reverse replacement and re-verified afterwards.

The raycast case dies at the Int32(capacity) conversion (“Not enough bits to represent the passed value”), not at the buffer allocation: calloc hands back lazily-zeroed pages, so the nominally ~189 GB [OCCTRayHit] costs nothing until it is touched. The trapping conversion is reached first. Worth recording, because it means the allocation size is the wrong thing to reason about when judging which of these entry points is dangerous — the int32_t cast is what fires, and it fires identically whether the element is 8 bytes or 88.

The math dimension family traps on a consistent-but-negative dimension, and one site reads out of bounds (#640)

#622’s own writeup deliberately left the math solver/optimizer family unfixed: its numbers are problem dimensions that must agree with the caller’s own arrays, not sampling capacities, so Sampling.requested/capacity is the wrong tool and clamping one would hand back a garbage-dimension solve. That premise is correct. The remedy it suggested, a consistency check against the caller’s arrays, is not, measured:

MathJacobi.eigenvalues(matrix: [1.0], n: -1)
// matrix.count == n * n holds exactly: 1 == (-1) * (-1)
// still aborts: Fatal error: Can't construct Array with count < 0

A consistency check alone cannot exclude this shape: whenever one factor of a product is zero, the other is unconstrained, so rows: 0, cols: -1 (or the symmetric n: -1 case above, where matrix.count is 1 either way) satisfies matrix.count == rows * cols for any value of the other factor. MathSVD.solve and MathHouseholder.solve have the identical gap. A positivity bound closes it, alongside the consistency check, not instead of it.

MathSolver.leastSquares is worse: it had no consistency check at all, so a rows/cols pair that is positive but does not match matrix/rhs’s real length sails straight through and reaches the bridge’s matA[i*nCols+j]/b[i] loops, which read unconditionally. That is an out-of-bounds read, not a trap: confirmed in a standalone process, rows: 1000, cols: 1000 against a 1-element matrix crashes with Bus error: 10; smaller mismatches silently returned nil from a garbage-fed IsDone() instead, never a reliable failure either way.

Re-deriving the census by reading each candidate bridge function, rather than trusting the trap-shaped count either side had produced, found 20 affected entry points, not 13. #634’s own writeup had already grown the count from 10 to 13 under review (MathSVD.solve, MathJacobi. eigenvalues, MathHouseholder.solve were unnamed anywhere until then); measuring by allocation shape and by trapping Int32(_:) conversion, as suggested, reproduces that 13. A third lens, does a bridge function index a raw pointer up to a caller-supplied count with no check that the backing Swift array is actually that long, found five more, invisible to both prior lenses because none of them constructs a [Double] sized by the vulnerable dimension:

• MathGauss.determinant / MathCrout.determinant return a scalar Double; the unconditional matrixData[i*n+j] loop is exactly leastSquares’s shape, just with nothing to trap on. Both crash with Bus error: 10 at n: 1000 against a 1-element matrix, confirmed in a standalone process.
• MathSolver.eigenvalues(diagonal:subdiagonal:) / .eigenvaluesAndVectors derive their dimension from diagonal.count (never negative), but read subdiagonal[i] for i in 0..<diagonal.count with no check that subdiagonal is that long: the /// comment already said “must be same length”; it was never enforced. Measured: a 50-element diagonal against a 1-element subdiagonal returns eigenvalues up to 1.17e+131, silently.
• MathSolver.gaussMultipleIntegration derives nVars from lower.count and reads upper[i]/order[i] up to it the same unguarded way. .gaussSetIntegration has both this gap and the trapping one (nEquations sizes its result array).

All 20 now require the dimension argument to be positive and every array it indexes into to match it exactly, closing the trap and the read together:

Also in scope, reached by a different lens: findAllRoots(samples:) (both overloads) is a sampler by name and by role, not a problem dimension, despite superficially trapping the same Int32(_:) way. It is routed through Sampling.requested instead, matching #558’s own family, and rejects with [] rather than trapping past Int32.max. Checked alongside it and confirmed correctly excluded: kronrodIntegrate/kronrodIntegrateAdaptive/integGauss/integKronrod/ integKronrodAdaptive’s points/gaussPoints parameters trap the identical way at Int(Int32.max) + 1, but select a quadrature rule order inside OCCT: no bridge function indexes an array by them, and a negative value is rejected cleanly via IsDone() == false, measured, not assumed. #634’s “kernel-side, not a Swift buffer” reasoning holds for these; it did not hold for findAllRoots.

Regression suite: Tests/OCCTMathTests/Issue640MathDimensionBoundsTests.swift, 17 tests covering all 20 entry points plus a positive control per function. Proved by injection at four representative guards spanning both failure shapes: removing MathJacobi.eigenvalues’s positivity bound crashes the whole swift test process (exited with unexpected signal code 5, matching raycast’s own #622 precedent) rather than failing one test; removing solveSystem’s startPoint.count == variables check and eigenvalues’s subdiagonal.count == diagonal.count check both instead produce ordinary, reportable test failures with the exact garbage values quoted above; removing findAllRoots’s Sampling.requested call reproduces the same whole-process crash as the positivity case. All four restored and re-verified green. A fifth injection, removing only MathGauss.determinant’s consistency check and leaving positivity, did not reproduce the crash inside swift test’s process (unlike the standalone probe, which crashed reliably at the same input): the read is undefined behaviour, not a guaranteed crash, and its outcome depends on the process’s own memory layout. This is the same point the out-of-bounds-read finding makes at the API level, one level down in the tooling used to demonstrate it.

PR #716 review follow-up: three new closure-return-length traps, a mis-measured integral, and a shared validator (#640)

An automated review of #716 (the PR above) found ten distinct defects, the most severe of which was the PR reintroducing its own bug class in three new places: guarding a caller’s argument arrays against a dimension mismatch, then indexing a closure’s return value against that same dimension with no check at all. A closure returning a short array trapped the process exactly the way #640 exists to prevent, just relocated from the caller’s arguments to the caller’s closure. Fixed at every site that shape occurs: solveSystem/solveSystemNewton’s values/jacobian callbacks, minimize/minimizeNewton’s gradient/hessian, and gaussSetIntegration’s values. minimizeFRPR shares the identical OCCTMathMultiVarGradCallback shape but was not itself named by the review; fixed and tested alongside the others for the same reason. Every guard was proved in a standalone process (the #705 technique, temporarily pointing Sources/OCCTTest/main.swift at a case-selecting probe): removing any one of them reproduces Fatal error: Index out of range, a process trap, not a test failure; restoring it returns nil.

The review’s own finding 2 uncovered a real defect, not a wrong literal. It read a new regression test, gaussIntegrationLengthBounds(), as asserting the double integral of x + y over the unit square is 0.5, and pointed out the true value is 1.0 by symmetry. Both observations were correct, and neither was the actual story: measured directly against the pinned kernel, gaussSetIntegration(nEquations: 1, lower: [0, 0], upper: [1, 1], order: [10, 10]) integrating x + y genuinely returns 0.5 – but not because it computes any correct 2-variable integral. math_GaussSetIntegration’s own header documents “the case M>1 is not implemented”: a probe built directly against the class confirms its constructor only ever varies the first integration variable (Lower.Value(Lower.Lower())), leaving every other component of its working vector pinned at its initial value, 0. So 0.5 is ∫x dx over [0, 1] with y silently held at 0 the entire time, never ∫∫(x + y) dx dy. OCCT’s own runtime check for this (Standard_NotImplemented_Raise_if(NbVar != 1, ...)) does not survive this project’s No_Exception production kernel build (the same class of gap #487/#555/#603 measured elsewhere), so instead of failing loudly it silently computed the wrong thing. Changing the test’s literal from 0.5 to 1.0 would have enshrined a different wrong answer – gaussSetIntegration can never legitimately produce 1.0 for that call, because it never touches the second variable at all. The actual fix is a new guard: gaussSetIntegration now requires lower.count == 1, returning nil for any call with more than one variable, matching what the class actually supports (one variable, any number of equations – a true “set of functions”, each integrated over the same one-dimensional domain). gaussMultipleIntegration is unaffected: its own class, math_GaussMultipleIntegration, integrates recursively over every dimension and was confirmed correct at 2 variables independently. The pre-existing Tests/OCCTIntegrationTests/ OCCTIntegrationTests.swift’s GaussSetIntegrationTests.integrateSet() predated #640 and carried the identical two-variable call and the identical 0.5 assertion; fixed to a valid one-variable, two-equation case ([x, x^2] over [0, 2], giving [2.0, 8/3]) plus an explicit assertion that the old two-variable shape now returns nil.

The remaining seven findings were all confirmed and fixed:

• Finding 1: both findAllRoots overloads called Sampling.requested(samples) without atLeast: 1, so the default floor of 2 applied even though this file’s own doc comments and the reference docs already documented the valid range as 1...10,000,000. samples: 1 was silently rejected – the closure was never called – before returning []. Fixed by passing atLeast: 1 at both call sites.
• Finding 7: MathGauss.determinant/MathCrout.determinant returned a bare Double, so the 0.0 sentinel for an invalid dimension was indistinguishable from 0.0, the correct determinant of a genuinely singular matrix. Both now return Double?; nil means invalid input, .some(0.0) means a real, correctly-computed zero.
• Finding 8: every positivity guard in this family computed n * n or rows * cols with the plain * operator, which traps on overflow for a sufficiently large positive dimension (e.g. n: .max) – the exact process-trap #640 exists to eliminate, reintroduced by the guard meant to prevent it. Fixed by routing every such guard through the new MathDimension type below, which uses multipliedReportingOverflow(by:) (the same idiom Sampling.gridTotal already carries) and rejects rather than traps.
• Finding 9: the “dimension positive, and every array it sizes matches exactly” check (or, for rows/cols, “the flat array is exactly their product”) was hand-duplicated at 18 call sites with no shared validator, unlike the Sampling family this same PR already reuses for findAllRoots. Sources/OCCTSwift/MathDimension.swift factors it into four functions – valid, consistent, validSquare, validRectangle – and all 18 sites now share it, fixing finding 8’s overflow gap everywhere at once rather than site by site.
• Finding 10: the 18 changed doc comments carried no fenced swift snippet, which CLAUDE.md makes mandatory for public API changes since context7 only harvests fenced snippets. All 18 gained one, modeled on Sampling.maximumSampleCount’s doc.
• Also removed: docs/SEMVER.md’s recorded-exception entry for this issue. The maintainer ruled that mechanism is for breaks shipping within a major line; this work ships in v2.0.0, a major, where breaking changes are permitted outright, so no exception entry is needed – this note is the migration record instead. The counters at the top of docs/SEMVER.md are restored to their pre-#640 values (thirteen recorded exceptions), and the pre-existing counter drift #640’s own PR fixed (a stale hardcoded number in #639’s entry, once out of sync with the count at the top of the file) is kept: that entry now reads the count in prose rather than restating it as a number that can drift again.

Full swift test: 5384 tests (5373 baseline + 11 new – 7 in Issue640MathDimensionBoundsTests.swift, 4 in a new MathDimensionTests suite exercising MathDimension directly, the same way Issue558SamplingCountBoundsTests.swift exercises Sampling.requested/capacity/gridTotal directly). swift run Censuses cluster-a: 45 rows. cluster-b: 16 rows. All four gate scripts and their three --self-tests pass from the repo root.

A fillet radius law goes to the edge’s own slot, in the edge’s own contour (#612)

filletEvolving, filleted(edges:startRadius:endRadius:) and filletedVariable all wrote their law with SetRadius(law, NbContours(), 1). Both coordinates were wrong, independently.

The contour. NbContours() is “the contour that exists after the most recent Add”, which is the edge’s own contour only when every Add creates one — a tangent-continuous edge extends an existing contour instead. Measured on a rounded-slot prism (two straight sides joined by two semicircular ends, extruded 20mm), adding a top-rim edge, a bottom-rim edge, then a second top-rim edge:

The third edge’s law was written to contour 2, replacing the bottom rim’s own. Asking for top rim 2mm and bottom rim 5mm returned 10271.088459 — byte-identical to filleting both rims at 2mm — against the intended 9899.533264.

The slot. SetRadius’s third argument, IinC, is the edge’s index within the contour and selects a distinct per-edge slot. Hardcoding it to 1 sent every edge of a tangent chain to the same slot, so only the last survived. On the same rim, filleting the straight side at 2mm and its tangent arc at 5mm:

Add(Radius, E), which backs blendedEdges, resolves that slot itself, so it always honoured the very request filletEvolving could not express. There was never a “one law per contour” limit to work around — the conflict was an artefact of the hardcoded 1. #612’s own example (a taper on one edge, a constant on its tangent neighbour) is an ordinary request and now builds, at 10171.225408.

The slot is visible on a single edge too: a 1 → 4 taper on one added edge measures 10273.238348, 10297.711861, 10343.333856, 10402.168644 at slots 1, 2, 3, 4.

The linear entry point was observably wrong after all. Its batch shares one (startRadius, endRadius), so with a constant law two edges of a contour rewrite the same number and nothing moves — but a genuine taper does not: two tangent-continuous edges at 1 → 4 measured 10273.238348, exactly what filleting the first alone produces, against 10297.711861 with each law in its own slot. It now uses OCCT’s own one-call Add(R1, R2, E), which is Add(E) plus the same slot resolution plus SetRadius — verified identical to resolving the slot by hand, and it declines an unfilletable edge by construction. OCCTShapeHistoryFromFilletEdgeVariable moves to the same overload: its SetRadius(radii, 1, 1) was in fact safe, because a single added edge always lands at index 1 of its contour’s spine (measured on all four edges of a tangent rim) and a literal 1 is bounds-checked upstream, but the idiom is gone.

And filletedVariable on such an edge did not merely pick a wrong index — it SIGSEGV’d. When OCCT declines an edge outright (a free-boundary edge of an open shell; 4 of the 12 edges of a box missing one face), Contour(E) is 0 and NbContours() is 0, so the call became SetRadius(law, 0, 1) — the unchecked low side of the contour index #505 measured. That is an OS signal, uncatchable in process. Confirmed by re-injecting the old code: swift test exits with signal 11. Such an edge is now resolved to no slot and skipped, which is exactly what Add(Radius, E) already does with it — measured identical to the digit, surface area 465.09733552923257 over all 12 edges of that shell, whichever entry point applies it, so the edge-list fillet family agrees. A batch in which every edge is declined leaves zero contours and fails in Build(), so an all-refused request still returns nil rather than the unfilleted input.

Measure an open shell by area, not volume: it is not a solid, so BRepGProp::VolumeProperties fabricates a number for it — the very defect class #605/#609 exist to reject — and that number is not even a property of the shape. It ranges 746.83 to 748.28 depending on which of the six faces is dropped, while the surface area is 465.097 for all six.

A NaN parameter bound stops being a plausible arc length (#548)

Curve3D.length(from:to:) documents itself as the entry point that tells failure apart from a real measurement, and #408 built the -1.0 sentinel of arcLength(from:to:) / arcLengthBetween(_:_:) on top of that guarantee. It held for the curve types the tests used.

GCPnts_AbscissaPoint::Length(adaptor, u1, u2) does not validate its bounds, and what it does with a non-finite one depends on which of its three internal branches the curve takes. Measured against the pinned kernel (Scripts/repro/548-nonfinite-length-bounds/), on a 5-point interpolated BSpline (domain [0, 485.39], length 528.75) and the analytic types:

The discriminator is not “spline” but “composite”. A 4-pole Bezier propagates NaN like a circle; what separates the BSpline is NbIntervals(GeomAbs_CN) == 4, which sends it down GCPnts_AbscissaPoint::length’s GCPnts_AbsComposite branch. That branch reduces the caller’s range with std::min/std::max, and those return their first argument when the comparison is false: a NaN upper bound collapses the interval onto the start parameter (hence 0), and a NaN lower bound makes both bounds NaN, which turns every per-span skip test false and integrates every span in full (hence the whole length). Not the domain clamping the issue supposed.

Both bounds must now be finite, checked in the bridge by occtValidParameterRange before any adaptor is built, so the contract no longer depends on the integrator’s own NaN handling. .nan and ±.infinity report nil from Curve3D.length(from:to:) and Curve2D.length(from:to:), and -1.0 from Curve3D.arcLength(from:to:) / arcLengthBetween(_:_:), Curve2D.arcLength(from:to:) and Shape.edgeArcLength(from:to:). Finite ranges are untouched, including the reversed, overshooting and wholly-outside ones #506 pinned.

Shape.edgeArcLength gains a failure sentinel. It was the only member of the family with neither an optional nor a sentinel, so a NaN bound on a straight edge returned NaN itself into caller arithmetic. Both spellings (edgeArcLength and edgeArcLength(from:to:)) now report -1.0 on failure instead of 0, matching every other arc-length function in the bridge — 0 is what a genuine zero-width interval measures.

Also measured here, fixed in #600 below: the documented “parameters outside the curve’s domain are clamped to it” holds only on composite curves. A 10-long segment measures 20 over [f, l + span], and a Bezier 122.14 long measures 1002.29 — polynomial extrapolation past its poles.

An out-of-domain range measures the curve, not its extrapolation (#600)

Filed out of #548’s measurements. Curve3D.length(from:to:) documented (since #477) that “parameters outside the curve’s domain are clamped to it, so a range wholly outside measures 0 rather than extrapolating the curve’s polynomial”. That was measured on an interpolated BSpline and holds only for curves with more than one GeomAbs_CN interval, because GCPnts_AbscissaPoint::length intersects the requested range with the curve’s own knots in that branch and in no other. Measured over [f, l + span], one domain width past the end (Scripts/repro/600-out-of-domain-length/):

One rule now, applied in the bridge instead of falling out of which branch a curve’s type takes: a ranged arc length measures the part of the range that lies on the curve. A curve whose parameter domain covers a whole period exists at every parameter, so those measure the whole range and wind — a circle over [0, 4π] still travels two circumferences, which confining would have broken.

The last row is why “confine unless periodic” was not enough. A closed interpolated BSpline is periodic and composite, so GCPnts confined it to its knots and returned one period for a request of two — silently answering half of what was asked, with no failure reported. Winding is computed in occtAdaptorLengthBetween (whole turns × one period’s length, plus the remainder wrapped into the domain) rather than delegated. Verified against a chord-sum reference.

Periodicity alone is not the test. A Geom_TrimmedCurve over half a circle reports IsPeriodic() == true with Period() == 2π, inheriting the basis curve’s periodicity, so the domain must cover a whole period before a range is allowed to wind. Otherwise an arc would measure round the part of the circle its caller trimmed away, which is what it used to do.

All four ranged entry points share the measurement, so a curve, its 2D equivalent and an edge built from it now answer an out-of-domain range identically. Curve2D.arcLength(from:to:) keeps its own range check (a reversed range still fails — that is #549’s decision, not this one’s) but no longer evaluates past the domain: 4771.88 for a BSpline 457.26 long, before.

Found while measuring, filed as #603: GCPnts_AbscissaPoint::Length integrates a single-span conic with one Gauss quadrature over the whole domain and lands 0.34% high on an 8×3 ellipse (36.4894 against a true 36.36686, confirmed by both a Richardson-extrapolated chord sum and a 2M-point Simpson quadrature of the elliptic integral), 1.49% on a 10×1 and 1.74% on a 1×0.05. Sub-ranges are accurate to ~1e-6 and summing two equal halves of the period recovers full accuracy, so it is the single quadrature — the #477 defect, on a curve type with no GeomAbs_CN boundaries to split at. Not fixed here: an accuracy question, not a range-semantics one — fixed in the #603 entry immediately below.

Arc length stops being one quadrature per span (#603)

Curve3D.length on a full ellipse was up to 1.7% wrong, and it was the whole-curve measurement that was wrong — the same ellipse’s sub-ranges were exact.

CPnts_AbscissaPoint::Length integrates |C'(u)| with one fixed-order Gauss rule over the whole range it is handed (order 10 for a conic, 5 for a parabola, 2 × Degree for a Bezier). #477 moved this family onto GCPnts_AbscissaPoint::Length, which splits at the GeomAbs_CN interval boundaries and applies that rule per interval — but a conic has exactly one interval, so the rule still had to cover the entire domain in one go. Measured against a 16-point composite Gauss-Legendre quadrature over 40,000 panels, cross-checked against a Richardson-extrapolated chord sum (Scripts/repro/603-single-span-quadrature/):

A parabola is the worst case in the family, and the only one wrong in the other direction — it gets the lowest order CPnts_AbscissaPoint’s order() hands out to anything curved. The issue named it as worth measuring and had not measured it.

It is not a conic defect, and not a “single span” defect either. The error is set by how much |C'| varies across one integration interval: the 8 × 3 ellipse is 0.337% out over [0, 2π], 0.0001% over [0, π] and exact over [0, π/2]. So a multi-span curve is affected too wherever its spans are wide — a 5-point interpolation is 100× worse than the 40-point curve #477 was tested on. #477 is completed here, not superseded.

Each GeomAbs_CN interval is now measured, then halved, quartered, … until two successive levels agree to 1e-9 relative (occtAdaptorArcLength, Sources/OCCTBridge/src/OCCTBridge_Internal.h). Subdividing the whole range instead does not work and fails silently: on a uniformly-knotted curve the domain midpoint is a knot GCPnts already splits at, so the level-2 sum repeats the level-1 sum bit for bit and a convergence test ratifies an answer that never moved (measured: 110.963893077 at both levels, truth 110.970568312).

The inverse moved with it, and had to. OCCT’s root finder inverts the very quadrature this replaces (CPnts_MyRootFunction::Value is one Gauss rule over [u0, X]), so before this the length and its inverse were wrong by the same amount and parameterAtLength(length) still landed on the curve’s last parameter. Fixing only the length would have moved that to 6.2438 on an 8 × 3 ellipse whose domain ends at 6.2832, and to 6.0358 on a 10 × 1 — 0.33% and 1.0% short in arc. So Curve3D.parameterAtLength, Curve2D.parameterAtLength, Shape.edgeParameterAtArcLength, Shape.edgeParameterAtFraction, EdgeCurve.parameter(atAbscissa:) and WireCurve.parameter(atAbscissa:) walk the same subdivided pieces and hand the last, narrow one to the kernel’s solver, which is accurate at that width. A target longer than the curve keeps its old answer (the kernel reports a parameter outside the curve’s own domain, yet reports success; turning that into a failure is a contract change #603 has no measurement to justify).

Every entry point in the family shares the measurement: Curve3D.length, length(from:to:), totalArcLength, arcLength(from:to:), arcLengthBetween(_:_:), Curve2D.length, length(from:to:), arcLength(from:to:), Shape.edgeArcLength (both spellings), Wire.length, EdgeCurve.length and WireCurve.length. #600’s winding is computed from an accurate period, so two turns is exactly twice one.

Cost: roughly 5×, with a floor of three quadratures per interval where there was one — an 8 × 3 ellipse goes 0.11 µs → 3.5 µs, a 200-span BSpline 89 µs → 452 µs. A line, a circle or a 2-pole Bezier/BSpline keeps its closed form (GCPnts_LengthParametrized), converges on the first split with nothing to remove, and stays at 0.02 µs.

Measured rather than assumed, on the two neighbours the issue lists as downstream. GCPnts_UniformAbscissa is not affected — on the worst ellipse its samples are uniform in true arc to 1.9e-10, so sampling by arc length was already right and is untouched. BRepGProp::LinearProperties is affected and is not fixed here: it runs its own integrator and still reports 41.243158 for the 10 × 1 elliptical edge. Shape.linearProperties().length therefore now disagrees with Shape.edgeArcLength on such an edge, where before both were wrong together; reimplementing mass properties is separate work.

The kernel fix ships too (Scripts/patches/0021-*, OCCT.xcframework rebuilt): a new header-only CPnts_AdaptiveIntegration.hxx does the same doubling, used by all four CPnts_AbscissaPoint::Length overloads and by CPnts_MyRootFunction::Value/Values. Both, or neither: the root function’s Value(X) is the same integral, so it currently inverts exactly the bias Length has — which is why GCPnts_UniformAbscissa spaces points uniformly in true arc (2.90e-14 on an 8 × 3 ellipse) while computing a total 0.337% wrong, and why changing Length alone would have broken the sampler. Measured both ways; changed together its spacing is unchanged to the digit. CPnts_AbscissaPoint::Length called directly, where nothing splits at all, goes from 1.0e-1 out on a 200-point interpolation to 2.8e-8. Kernel cost: GCPnts_AbscissaPoint::Length 0.24 µs → 7.2 µs on an ellipse, 87 µs → 444 µs on a 200-span BSpline, GCPnts_UniformAbscissa at 500 points 2.71 ms → 6.20 ms. Filed upstream as Open-Cascade-SAS/OCCT#1420.

The bridge subdivision stays for now, and is redundant once that binary is pinned. ci.yml resolves the pinned released kernel, which has no patch 0021 until a release ships the rebuild, so removing it would fail this issue’s own regression tests there. Layered on the fixed kernel it costs almost exactly 2× (8 × 3 ellipse 3.3 µs → 6.6 µs) and changes no answer — retire it in the release commit that bumps Package.swift’s url:/checksum:.

The 2D arc length that measured 8082 for a curve 353 long (#549)

Curve2D.arcLength(from:to:) and Curve2D.length(from:to:) answered differently on a reversed range: the first reported -1.0, the second measured the span. #506 removed the 3D spelling of that divergence and filed this one as the 2D half, a consistency question rather than a bug report, since both behaviours were documented and each doc page was accurate about itself. Measuring the pair first, as the issue asked, made it a correctness question as well. On a 5-point 2D interpolation (domain [0, 318.433], length 353.508):

The reversed-range rejection was the visible half of a pre-bounded Geom2dAdaptor_Curve(curve, u1, u2). The other half was that it evaluated a multi-span curve’s polynomial past its knots and reported the result as an ordinary success: the defect #477 removed from the 3D path, still live in 2D because the two dimensions were fixed one at a time.

OCCTCurve2DLength is gone, with tombstone comments naming the survivor, and Curve2D.arcLength(from:to:) now delegates to length(from:to:), the shape Curve3D.arcLength(from:to:) has had since #408. That was the last pre-bounded arc-length call site in the bridge. New suite Issue549Curve2DArcLengthRangeTests (OCCTGeom2dTests) pins the divergent ranges against a chord-sum reference and checks the 2D answers against the 3D ones on the same points in the z = 0 plane; #409’s suite keeps the -1.0-not-0.0 sentinel it was written for, on an input that still fails. Proved by injection: restoring the pre-bounded call reproduces the figures above through the public Swift API and fails 7 of the 11 tests across the two suites. Probe and full figures at Scripts/repro/549-curve2d-arclength-range-order/.

Two things the measurement corrected on the way past. Curve3D.length(from:to:) documented its clamping unconditionally (“Parameters outside the curve’s domain are clamped to it”), which holds only for a curve with more than one GeomAbs_CN interval: GCPnts_AbscissaPoint::length intersects each interval with the requested range there, but a line, a circle or a 2-pole spline returns |u2 - u1| * ratio and a single-span Bezier integrates the range as given, both unclamped. Measured on four curve types in both dimensions (a Bezier reports 41.256 for a range wholly outside its domain), and the 2D and 3D wording now say so. Separately, Scripts/check-bridge-index.py read the sources whole, so a removed function still counted as existing as long as its tombstone comment named it, which the tombstone idiom (#500, #506) puts there on purpose. It strips comment lines from the sources now, which surfaced three stale entries in the GCPnts_AbscissaPoint index line, all three of them removed arc-length spellings. The new --self-test case is exactly that: a real symbol that survives only in a tombstone.

Noticed, not fixed. Routing 2D onto the ranged form gives it #548’s NaN hole too: on a multi-span 2D curve a NaN bound lands on a domain bound instead of poisoning the integral, so length(from: f, to: .nan) reports 0 and length(from: .nan, to: l) the whole length. On a line, a circle, a segment or a Bezier the NaN propagates and both spellings report failure, which is what the new suite pins. Noted on #548 so one fix covers both dimensions.

Breaking: defeaturing refuses a face the shape does not have, instead of dropping it (#578)

Shape.defeature(faces:) inherited OCCT’s own rule for a face that is not part of the input: BRepAlgoAPI_Defeaturing.hxx says “those that do not belong will be ignored”, and it means it. A request mixing one of this shape’s faces with another shape’s succeeded, removed the one that belonged, and raised no warning of any kind — a success indistinguishable from a real removal, handed back on a shape still carrying the feature the caller asked to remove. The index-addressed spelling of the same operation, withoutFeatures(faces:), has failed the whole call on one bad index since #497; #536 made defeature(faces:) canonical without closing that gap, because a membership rule turned out not to be the line of validation it looks like.

Why it needed measuring first. AddFaceToRemove takes a TopoDS_Shape, and its own documentation calls it “the shape to extract the faces for removal” — the argument need not be a face. Measured on the pinned kernel: a compound holding a face, the input’s own shell and the whole input solid are all accepted and each means the faces it contains, while an edge, a vertex and an empty compound are refused because they contain none. So a rule cannot ask that each element be one of this shape’s faces; it has to explore first, and then decide what a carrier mixing belonging and foreign faces means. Two further measurements make the check implementable and exact: replacing a carrier with the faces it explores to is the same request BREP for BREP, and the input’s own TopExp face map hashes on IsSame, so it accepts the fillet face reversed and rejects the same face measured off an identically-built twin. Probe, full matrix and the rejected alternative at Scripts/repro/578-defeature-face-membership/.

The rule now applied, in occtDefeaturingFacesFromShapes (the #497 skeleton, which now takes the input shape so it can build that map):

Every element of the request must name at least one face, and every face it names must be a face of this shape. Otherwise the whole call returns nil and nothing is removed.

The alternative the issue posed — accept a carrier yielding some belonging faces and quietly keep those — was rejected because it preserves the exact failure mode being removed, one level further down where it is harder to see. Exactly four kinds of request change, and all four were being partly discarded in silence: a foreign face alongside a real one, a compound mixing the two, and an edge or an empty compound alongside a real face. Nothing whose elements all belong behaves differently, carriers included — the whole-solid and shell forms stay accepted, and stay a no-op, because “remove every face” is a question about the algorithm rather than about membership and the kernel’s answer to it is to hand the input back unchanged.

Nothing is filed upstream: the kernel documents what it does and does it. The strictness is this bridge’s contract, and it is now the same contract at both spellings.

New suite Issue578DefeatureFaceMembershipTests (OCCTModelingTests) pins the whole matrix, and Issue536DefeaturingSpellingsTests’ two membership tests — which pinned the old behaviour — are replaced by one that holds the two spellings to the new rule together. Proved against two injections: restoring the pass-through fails six tests across both suites, and injecting the rejected alternative fails exactly one, the mixed-carrier test that exists to pin the design decision.

The index entries that named a real symbol belonging to a different class (#565)

#510 fixed the 135 index entries in OCCTBridge.h that named symbols which never existed. This is the second defect class in the same index: an entry naming a real symbol from a neighbouring class. It passes an existence check and misleads exactly the way a fabrication does — you look up a class, get sent to a function that has nothing to do with it, and conclude the class is wrapped there. #501 hit it directly (GCPnts_UniformAbscissa → OCCTCPntsUniformDeflection*, a symbol that exists and wraps CPnts_UniformDeflection).

17 entries corrected. Every one named a symbol that exists, so the #510 gate called them all clean:

Six classes had no entry at all because a wrong one was standing in for them: ShapeAnalysis_Wire (39 call sites), BRepFill_PipeShell (24), BRepOffsetAPI_MakeOffsetShape, BRepOffset_MakeOffset, Law_Interpolate, LProp_CurAndInf. Geom2d_Direction and Geom2d_VectorWithMagnitude moved to docs/occtswift-wrapping-gaps.md as genuinely unwrapped.

The direction check now gates, per symbol rather than per entry. An entry-level rule (“at least one of these reaches the class”) lets a wrong symbol hide behind its correct neighbours — which is the whole shape of the defect, and GCPnts_UniformAbscissa was only caught in #501 because it happened to be its entry’s sole symbol. Two injected mistakes proved this: adding OCCTShapeFixWireframe to the correct ShapeFix_Face entry went unreported until the rule changed.

Four forms of indirection had to be resolved first, because a check that cannot tell “wrong class” from “reached indirectly” fails on correct entries and gets switched off: wrapper-type fields (XCAFDoc_ShapeTool is OCCTDocument::shapeTool, 66 call sites), file-local static helpers (TDataStd_NamedData, the near-miss that almost got its entry wrongly deleted in #510), static facades (ShapeCustom::SweptToElementary is how ShapeCustom_SweptToElementary is reached), and multi-class headings (RWObj_CafReader/Writer covers RWObj_CafWriter, not RWObj_Writer). Where a class is genuinely reached only through another OCCT class, the entry carries a (via X) aside — and that aside is itself checked, not a silent skip. --self-test grew from 5 cases to 15: five existence shapes, four mis-attribution shapes, and six correct shapes asserted not reported.

A parenthesised aside is commentary, not an attribution. The existence check reads names inside asides by design (that is how #508’s OCCTGCE2dMakeLine* was caught), but the direction check must not: (OCCTWireOffset drives BRepOffsetAPI_MakeOffset, not this) names a symbol precisely to say it does not wrap the class.

A tombstone comment was resurrecting two deleted symbols. real_symbols stripped comments from the header but not from the sources, so // OCCTCurve3DLength lived here: … — left where #506/#549 deleted the function — kept a removed symbol passing the existence check forever. Stripping source comments too flags exactly the two names it should (OCCTCurve3DArcLength*, OCCTCurve3DLength, both still listed under GCPnts_AbscissaPoint) and nothing else.

Filed out of this, not fixed here: Shape.centerOfMass returns the bounding-box centre (#605). OCCTShapeGetCenterOfMass was filed under BRepGProp and does not use it — it takes the midpoint of BRepBndLib’s bounding box, under a comment claiming GProp_GProps::CentreOfMass() “appears to return (0,0,0) for some shapes”. Ground truth on the pinned kernel says otherwise: for a 10-cube at the origin plus a 2-cube 20 units away, CentreOfMass() returns 0.158730159, the analytic answer to nine digits, while both Shape.centerOfMass and properties().centerOfMass return 8.0 — the bounding-box midpoint, off by 50x. The workaround was reading a correct zero (a box centred at the origin) as the bug it was working around; every existing test uses a box, where the two coincide.

Comment-only change to OCCTBridge.h (index block) plus Scripts/check-bridge-index.py and docs/occtswift-wrapping-gaps.md; no declaration, no .mm, no kernel patch, no xcframework rebuild.

The approximation consumers did move when #522 landed, and at the continuity that was supposed to be safe (#572)

Patch 0019 (#522) fixed AdvApp2Var_ApproxF2var::mma2ce1_ filling both Jacobi-maxima buffers from the V slot, which made every interior truncation error the surface approximator computed evaluate to exactly zero. #572 asked whether the five kernel classes that construct a GeomConvert_ApproxSurface and never re-check MaxError() moved with it, expecting that they could not have taken a wrong shape because they run at C1 or C2, above the collapse.

They took a wrong shape. Measured on the real wrapper paths, against a stock and a 0019 kernel built as matching -O0 single-TU override links:

Every path that moved moved toward its tolerance, by 1.6x to 5x, and every path that did not move was already meeting it. None of the three reaches its tolerance even now: they cap out at degree 14 and 16 or 24 segments. What changed is that the degree search climbs to that cap instead of stopping at the NDMINU floor with every candidate scoring zero, and that the caller is now told.

Continuity was the wrong axis to predict on. The zeroed error does not only lower the degree floor, it disables the subdivision decision: mma2ce2_’s tolerance test can never fire on a patch interior, so the fit neither raises its degree nor cuts the patch at any continuity. And C0 is reachable at GeomConvert_1.cxx:960, which derives its request from the surface rather than hardcoding one (Geom_OffsetSurface reports IsCNu(N) as its basis surface’s IsCNu(N + 1), so an offset of a B-spline that is C1 but not C2 in U asks for C0) and does not collapse there. The axis that predicts movement is whether the site allows subdivision and whether the input needs any.

Three rows of the issue’s own site table did not survive measurement, which a backtrace probe in GeomConvert_ApproxSurface::Approximate settled rather than a source reading:

• Shape.sweep cannot reach GeomFill_Sweep.cxx:296. It uses the two-argument BRepOffsetAPI_MakePipe, and ForceApproxC1 is only on the five-argument one. PipeShellBuilder.setForceApproxC1(true) is the sole lever, and it additionally needs the spine’s tangent break to sit inside one edge, since BRepFill_Sweep splits the sweep at spine vertices.
• BRepOffset_Offset.cxx:1626 is dead. It sits inside if (Polynomial), that argument defaults to false on every Init overload, and the one in-tree caller takes the default. Neither Shape.offset at any join type nor Shape.thickSolid constructs it.
• GeomLib.cxx:1517 has no OCCTSwift entry point. Its reachable-from list is wider than the issue recorded (fillets through ChFi3d, plus BRepFill_Sweep, BRepOffset_Tool and BRepLib, not just “GeomLib conversions”), but every one of those hands it a surface that is already a B-spline, which is the branch above the construction.

ShapeUpgrade_UnifySameDomain.cxx:3629 needs a base surface that closes in a direction it is not periodic in and is not already a B-spline, which no BRepPrimAPI primitive produces (Uperiod comes from IsUPeriodic()). An extrusion of a closed but clamped B-spline curve reaches it, and its fit is exact on both kernels.

Two regression suites pin the paths that moved, both checked against the released pre-0019 kernel with OCCTSWIFT_REMOTE=1. No production code changes. Reproducer, both transcripts and the probe census: Scripts/repro/572-approx-consumer-sweep/.

faces() dropped a shared face’s second orientation, inverting normals on split solids (#614)

#541/#502 converged every face accessor onto one enumeration, TopExp::MapShapes. That map compares with TopoDS_Shape::IsSame — “same TShape with the same Locations. Orientations may differ” (TopoDS_Shape.hxx:265-271) — and NCollection_IndexedMap::addImpl returns the existing index and leaves the stored key untouched on a repeat (NCollection_IndexedMap.hxx:684-710). So a face occurring in one shape both FORWARD and REVERSED collapsed to a single entry carrying whichever orientation was reached first.

That is correct for an index and wrong for a normal, because OCCTFaceGetNormalAtUV reverses the surface normal exactly when the face reads REVERSED. Measured on the pinned kernel — a BRepAlgoAPI_Splitter cutting an origin-centred 10mm box (Shape.box spans −5..5) with the z=4 plane, the plainest two-body result there is:

The two occurrences are IsSame and not IsEqual. A renderer or CAM pass building outward normals by walking faces() got an inward-facing wall for the second body, and any per-face accumulation silently lost a facet.

That second half was reachable through public API, not just in principle. The face-list CAM helpers filter on normal-derived predicates, so they inherited the collapse — on the same compound:

The upper solid’s floor was simply absent.

Fixed by following the split OCCT itself draws, rather than inventing one. The kernel already separates these two jobs and this bridge now matches it:

• Index → orientation-insensitive. TopExp::MapShapes(S, T, M) is the only type-filtered mapping function OCCT publishes and it accepts only the IsSame hasher’s map — there is no oriented overload (TopExp.hxx:57-60). Upstream’s own canonical stable sub-shape index, the one BREP file persistence writes, is that same map (TopTools_ShapeSet.hxx:192). Shape.faces() stays on it, so no index moves and #541 is untouched.
• Normal → orientation-sensitive, read off the traversal. BRepGProp::VolumeProperties, where a face’s orientation sets the sign of the volume integral, takes it from ex.Current() (BRepGProp.cxx:322-325); and where it deduplicates, it keeps one IsSame map per orientation (aFwdFMap/aRvsFMap, BRepGProp.cxx:318-338) so a shared wall’s two sides both survive. The oriented indexed map (NCollection_IndexedMap<TopoDS_Shape>, deprecated alias TopTools_IndexedMapOfOrientedShape) is used upstream only for internal algorithm bookkeeping — TopOpeBRepBuild, TopOpeBRepTool, BOPAlgo_Builder, BRepCheck_Wire, ChFi3d, BRepTools_ReShape — never as a public sub-shape enumeration.

New API, all additive:

• Shape.orientedFaces() -> [Face] — the geometry enumeration: one entry per occurrence, each carrying the orientation it has in its parent. A shared wall appears twice, once per owner, each time with the orientation that makes Face.normal(atU:v:) point out of that owner. An entry’s array position is an occurrence number, not a face index, but each Face still carries the correct Face.index into faces() — so an occurrence stays addressable by every face-index-taking method, and entries sharing an index are the sides of one shared face. On any shape that shares no face this returns exactly faces(), same order, same indices.
• Face.orientation -> Shape.Orientation — the flag the normal reverses on, so the two sides of a shared wall can be told apart.
• Bridge: OCCTShapeGetOrientedFaces, OCCTShapeGetFaceOccurrenceCount, OCCTFaceGetOrientation.

• horizontalFaces(), upwardFaces() and facesByZLevel() now read orientedFaces() — they select on the face normal, so they are geometry consumers. Contract change: all three select over occurrences and so can return two Face values carrying the same Face.index; dedupe on index (or use faces()) if you need one entry per distinct face. On any shape whose faces are not shared all three are unchanged, entry for entry.

  These three are not the complete set of normal-derived consumers of faces(). AAG.buildGraph() (FeatureRecognition.swift:96) also derives normal, isHorizontal, isUpward, isDownward, isVertical and zLevel from faces(), and AAG.detectPockets() selects on them — both public via Shape.buildAAG() and Shape.detectPocketsAAG(). It is not fixed here: faceIndex and adjacencyList are array positions, so moving that graph to the occurrence enumeration changes its identity model. Measured on the z=4 split compound, detectPocketsAAG() returns 2 or 1 depending only on the order the halves were compounded in (upward+horizontal nodes [2, 8] vs [2]), while upwardFaces() correctly returns 2 either way. Tracked as #642.

  One correction to an earlier draft of this entry: upwardFaces() was described as unable to repeat an index, on the reasoning that a shared wall’s two sides have opposed normals. That reasoning holds only when the repeats come from parents bounding opposite sides. Reached twice through parents imposing the same orientation, both entries qualify — Shape.compound([box, box]).upwardFaces() returns indices [5, 5]. Separately, isUpwardFacing tests n.z > cos(tolerance), so at tolerance >= π/2 the threshold is non-positive and admits faces that do not point up at all, including both sides of a vertical shared wall: upwardFaces(tolerance: 1.6) returns 10 entries over 9 distinct indices on a two-solid split. Both are pinned by tests.

Shape.faces()’s own behaviour is unchanged; its documentation now states which of the two contracts it holds. Per-solid enumeration (compound.solids then .faces()) was already correct and is pinned by a regression test so the compound-level fix cannot regress it.

The third “closest point on an edge” entry point, and the edge it was measuring to (#580)

Shape.pointEdgeExtrema(point:edgeIndex:) makes the same promise Curve3D.projectPoint and Edge.project(point:) make, and #539 fixed those two while leaving this one open on a contract question. That question is now measured, and the answer carried two defects rather than one.

It reported the minimum over BRepExtrema_ExtPC’s extrema, which is not the minimum over the edge. Extrema are perpendicular feet, so they exclude the edge’s own two ends, and the one in range can be a maximum:

Over 189 edge/point combinations against a dense brute-force reference, it was right 101 times, wrong 34 and silent 54. The measured trap: filtering the extrema to the IsMin ones scores 101 — exactly what it already scored — because the cases that filter drops are the ones it then leaves with no candidate at all. Adding the ends is what fixes it.

It now routes through #539’s occtNearestPointOnCurveRange, so all three entry points reach one implementation and cannot disagree about the same edge and the same point: 189/189. Repairing in place with BRepExtrema_ExtPC::TrimmedSquareDistances was the smaller diff and tops out at 188 — Extrema_ExtPC does not converge on a BSpline queried from (2, 0, 0), leaving the nearer end to answer 2 against a truth of 1.996434, where GeomAPI_ProjectPointOnCurve finds the interior minimum.

solutionCount keeps its meaning, its source and its value; the nil guard is what changed. OCCT models the extrema and the ends as separate things on one object, so “how many extrema were found” was never the wrong number — the ends were simply never consulted. It is no longer a success flag: zero now travels to the caller as the informative state it is (the nearest point is an end) instead of erasing the answer. Note that a non-zero count does not mean the nearest point is one of those feet — the half-circle row above reports solutionCount == 1, and that one extremum is the maximum it used to answer with.

And the second defect, found while fixing the first. edgeIndex walked a bare TopExp_Explorer, which counts one entry per occurrence: a box’s 12 edges are 24 occurrences, since each belongs to two faces. Measured on the pinned kernel, that diverges from the enumeration Shape.edges() and Shape.edge(at:) read (#541’s contract) from index 9 onwards — edgeIndex: 9 measured to the edge through (10, 0, 5) where every other entry point names the one through (5, 0, 10). Not a shared-sub-shape curiosity like #541’s splitter fixture: a plain box.

Behaviour changes for callers. nil now means only “no such edge index, or an edge with no 3D curve”, matching what #539 settled for Edge.project(point:). solutionCount is no longer usable as a success test — it never was, since the guard made solutionCount > 0 unfalsifiable for any non-nil result. edgeIndex 9 and above name different edges on any shape whose edges are shared between faces, which is every solid.

New suite Issue580PointEdgeExtremaTests (OCCTAnalysisTests), 8 tests, plus the pre-existing BRepExtremaExtPCTests.pointToEdge rewritten — its “loop until we find one that gives a valid extremum” was itself a workaround for this defect, and its #expect(result.solutionCount > 0) was unfalsifiable under the guard it was testing. Proved rather than assumed: reinstating the old implementation fails 7 of the 10, and the 3 that pass are exactly the deliberately-unchanged ones (a point with a perpendicular foot, an out-of-range index, and the pre-existing in-range case). Bridge-only — no kernel patch, no OCCT.xcframework rebuild.

Five knot-splitting spellings collapse onto two, and the “strictly weaker” duplicate turned out to be the stronger one (#562)

GeomConvert_BSplineSurfaceKnotSplitting and Geom2dConvert_BSplineCurveKnotSplitting were each wrapped twice, by two families added three releases apart: Surface.knotSplitting and Curve2D.splitIndicesAtDiscontinuities (canonical), and a v0.105.0 set of five (Surface.bsplineKnotSplitsU/bsplineKnotSplitsV/bsplineKnotSplitValues, Curve2D.bsplineKnotSplits/bsplineKnotSplitValues). All five are now deprecated and forward to their canonical sibling; their five bridge functions are deleted.

The premise that the five were strictly weaker did not survive measurement. Curve2D.bsplineKnotSplitValues sized its buffer from the analyzer’s own count, where splitIndicesAtDiscontinuities read a fixed 256 entries and took whatever came back — and the bridge returned the count it had written, so truncation was indistinguishable from a curve with exactly 256 splits. On a cubic with 300 interior knots at multiplicity 3 (302 splits):

Forwarding without fixing that would have regressed the deprecated spelling, so OCCTCurve2DSplitAtDiscontinuities now reports the true count and the Swift caller re-reads at it — the #481 contract every other member of this family already shared. That is a C-layer contract change: a direct bridge caller that treated the return as “how many were written” must now clamp it. OCCTBridge is not an SPM product, so no Swift package is affected.

What the deleted family carried that the canonical calls did not: the raw knot-table indices. The analyzer reports indices and OCCTSurfaceKnotSplitting converted them to parameters, so the raw form was reachable only through bsplineKnotSplitValues — which constructed the analyzer three more times to get it, once per count call and once for the values. KnotSplitResult now carries uSplitIndices/vSplitIndices alongside the parameters, from the one construction that was already happening, with uSplitParams[i] == bsplineUKnot(index: uSplitIndices[i]) by construction. That answers the issue’s open question about whether the index-returning form was worth keeping: the information was, the three extra entry points were not.

Both deleted values functions also took no buffer capacity at all — each wrote NbSplits() entries into a buffer the caller had sized from a separate call, which was only safe because the analyzer is deterministic. Recorded in the bridge header so it is not reintroduced.

OCCTBridge.h’s cross-reference index named none of the three *KnotSplitting conversion classes, which is half of why the double-wrap went unnoticed for three releases — the index is the map used to find every call site of a class (#510). It gains GeomConvert_BSplineCurveKnotSplitting, GeomConvert_BSplineSurfaceKnotSplitting, and a --- Geom2dConvert --- section that did not exist at all, censused by call site across its six classes.

Tests: Issue562Curve2DKnotSplitDuplicateTests (OCCTGeom2dTests, 4 tests) and Issue562SurfaceKnotSplitDuplicateTests (OCCTSurfaceTests, 5 tests). Expectations are absolute — the fixture’s own knot indices and knot table — rather than agreement between the two spellings, which stopped being evidence the moment one started forwarding to the other. Three injected defects (written-count truncation, 0-based indices, V continuity collapsed onto U) each fail the tests that should catch them; the last is caught by the new suite alone and by none of the existing #403 or #480 coverage.

The healing conversions were returning a straight chord through an offset sphere (#570)

#522 fixed the kernel writing the U Jacobi maxima into the V workspace slot, which zeroed every patch’s interior truncation error, so GeomConvert_ApproxSurface::MaxError() only ever described the boundary iso-curves. That established the number was wrong. Three kernel healing sites make an accept/reject decision on it, which is where a zero stops being a wrong diagnostic and becomes a wrong shape — and nobody had checked them, because every existing test of those entry points uses a box or a cylinder.

Measured against a stock and a patched kernel across ten fixtures, two of the three returned a materially wrong surface:

The fixture is a face on an offset sphere over its full domain. 24 is the offset sphere’s own diameter: the fit was a straight chord across the full 2π of longitude, accepted as meeting a Precision::Approximation() tolerance of 1e-6. The restriction result was worse — a single pole in a periodic direction is the whole U direction collapsed to a point, accepted against a 0.01 tolerance it missed by three orders of magnitude — and it was identical at C0, C1 and C2, because the degree-priority loop degrades continuity toward 0 whenever the requested one cannot meet the tolerance within maxDegree. Requesting C2 was not protection.

Six public entry points reached it, all confirmed against the released kernel: Shape.convertedToBSpline(), Shape.withSurfacesAsBSpline(offset:), Shape.convertToBSplineAdvanced(_:offsetMode:) and all three bsplineRestriction* overloads.

The third site is why the other two were reachable at all. ShapeCustom_ConvertToBSpline does not build an approximation itself — it calls ShapeConstruct::ConvertSurfaceToBSpline, forcing GeomAbs_C0 for any offset surface (ShapeCustom_ConvertToBSpline.cxx:148, a 1999 workaround for a hang). So that path did not degrade into the collapsing continuity; it started there. Requesting the offset surface’s own continuity instead returns identical results before and after the patch — the collapse never reaches C2/C3.

No code changed. Patch 0019 already fixes every row above, so what this issue ships is the measurement, the reproducer at Scripts/repro/570-healing-approx-accept/, and seven regression tests pinning the corrected values. Run against the last released kernel, six of the seven fail with exactly the figures above and the seventh — an offset sphere trimmed clear of its poles, which was never affected — passes.

The 1999 workaround stays. Timed on both kernels, the request it suppresses completes in under 5 ms on all seven offset fixtures with no hang, and its results are identical either side of 0019. That is not evidence the hang is gone; it is no evidence the hang ever existed for these inputs. The comment blames a hang, #522 is not a hang, and retiring a hang guard needs a reproduction of the hang. Post-0019 the workaround also costs nothing measurable — forced C0 returns a slightly coarser fit (1.2e-7 against 1.4e-8) that is comfortably inside tolerance either way.

Breaking: plate surfaces honour the tolerance they were given (#571)

Six bridge functions build a surface with GeomPlate_MakeApprox — Shape.plateSurface(through:), plateSurface(constrainedBy:), plateSurface(through:orders:), plateSurface(through:curves:), plateSurface(points:) and Surface.plateThrough(_:). Five of them passed Nbmax = 1 and dmax = tolerance * 10, and between them those two arguments made tolerance unenforceable.

Nbmax caps the number of Bezier patches, and 1 is the one value that disarms the algorithm. AdvApp2Var_ApproxAFunc2Var::ComputePatches derives its cut decision from that cap; at 1 every branch leaves it at “do not cut”, so AdvApp2Var_Patch::CutSense returns the same answer whether or not the G0 criterion was satisfied. The criterion is still evaluated and still reported through CriterionError() — it simply cannot act. Measured on a 25-point wavy plate at tolerance: 0.01: the criterion came back at 0.098 against its own 0.01 threshold, violated, and the surface was returned unchanged. Nbmax = 2 or more fits the same plate to 0.0044.

dmax sets that threshold, as seuil = max(Tol3d, 10 * dmax). tolerance * 10 therefore asked the criterion to accept 100x the tolerance the caller requested — and it is not merely dead weight once subdivision is allowed: at Nbmax = 20 that value reproduces the bad single-patch answer exactly, while tolerance * 0.1 gives the good one. tolerance * 0.1 makes 10 * dmax == Tol3d, so the threshold is the caller’s own tolerance. It is the value the sixth site already used.

All six now share one helper (occtPlateApproxSurface) with one contract. What changes for callers:

Surfaces from these six entry points therefore move, and callers who stored derived geometry should regenerate it. Two related contracts are now explicit rather than implicit:

• maxSegments: 1 is clamped to 2. Shape.plateSurface(points:maxSegments:) is the one entry point that exposes the cap, and 1 there is not a coarser request but the value that voids tolerance entirely.
• The approximation’s continuity is passed explicitly, and stays GeomAbs_C1. It is the continuity of the joins between patches, a different axis from the constraint order handed to GeomPlate_PointConstraint/GeomPlate_CurveConstraint — so plateSurface(constrainedBy:continuity:) still applies the caller’s .g0/.g1/.g2 to the boundary constraints only, and does not forward it to the fit. Only C0, C1 and C2 are accepted there at all: G1, G2, C3 and CN each throw AdvApp2Var_ApproxAFunc2Var : UContinuity Error (measured), which is why occtGeomAbsFromSurfaceContinuity — whose order-1 answer is GeomAbs_G1 — must not feed it.

This is not fallout from #522, though that is what prompted the audit. GeomPlate_MakeApprox is the one consumer of the defective approximator that does not go through GeomConvert_ApproxSurface, so it took #522’s always-zero interior error without appearing in any census built by grepping for that class. Fingerprinting the control net of 54 plate fits either side of the 0019 patch — a stock override-link against the patched kernel — shows every one identical. Only the reported ApproxError() moved, rising 1.03x to 5.37x as the interior contribution is counted for the first time. At the implicit C1 default the degree floor is already 8, so #522’s collapse could not reach these sites, exactly as #571 predicted.

Two plate suites carrying .disabled("Plate surface operations cause segfault in OCCT") are re-enabled: 18 tests, 13 consecutive clean runs, and they pass against the pre-fix arguments too, so the annotation was stale rather than describing something this change cured. They cover two of the six sites. Reproducers and both transcripts: Scripts/repro/571-plate-approx-contract/.

The cross-reference index stops naming 135 symbols that never existed (#510)

OCCTBridge.h opens with a hand-maintained index mapping each wrapped OCCT class to the bridge symbols that wrap it. It is the map you use to find every call site of a class, and 135 of its symbol references named nothing at all — so a re-audit by symbol name returned zero hits and read as “no call sites, nothing to check”. That is not hypothetical: it is how #484’s fourth, still-unpatched ShapeFix_Face call site was missed. Every one is now rewritten against a measured census of which bridge functions actually reference the class, or removed where no wrap exists:

ShapeFix_Shell was the only entry with no wrap behind it. TDataStd_NamedData → OCCTLabelNamedData* looked identical — no such symbol, no obvious neighbour — but is wrapped, as OCCTDocumentNamedData*, through two lowercase static helpers. A census that only attributes a class to the enclosing OCCT-prefixed function cannot see that, so “no call site found” is a prompt to grep by hand, not a verdict.

The checker that was supposed to prevent this could only see 129 of the 135. check-bridge-index.py split each entry on commas and slashes and required every piece to be a bare symbol. Anything else was skipped without a word: continuation lines of a wrapped entry, headings naming several classes at once (RWObj_CafReader/Writer), and any name carrying an annotation (OCCTShapeFill* (Shape.fill)). It now checks every OCCT-prefixed name anywhere in an entry, which raised what it actually inspects from 454 symbols to 660 and turned up the remaining six — including TDataStd_Integer/Real/AsciiString → OCCTLabel{Set,Get}Integer/Real/AsciiString and TDataStd_IntegerArray/RealArray → OCCTLabel*Array*, naming an OCCTLabel* family that does not exist anywhere in the bridge, and XCAFDoc_ColorTool → OCCTXCAFShape*Color*, a second sighting of the OCCTXCAFShape* prefix that has never named anything. --self-test injects a fabricated name in each of the five shapes an entry can take and asserts it is reported; the parser this replaces catches one of the five and calls the other four clean. The sixth is #508’s GC_MakeLine2d → OCCTGCE2dMakeLine*, whose real wrappers (OCCTCurve2DMakeLineThroughPoints, OCCTCurve2DMakeLineParallel) were already two lines away in the same file.

A second defect class remains, filed as #565: the checker verifies that a named symbol exists, not that it wraps the class the entry files it under. A mis-attributed entry that happens to name a real symbol from a neighbouring class is still invisible, and it misleads exactly the way a fabricated one does.

The cylindrical-hole drill selected parts of the cut result, not parts of its tool (#532)

Kernel patch 0020. Every BRepFeat_MakeCylindricalHole mode that chooses which piece of the drilling tool to keep — PerformThruNext, PerformUntilEnd, the ranged Perform(Radius, PFrom, PTo) and PerformBlind — drove BRepFeat_Builder with SetOperation(Fuse), i.e. BOPAlgo_CUT, and then called PartsOfTool(). That method collects the solids of the builder’s shape, which holds the tool split by the object only after the COMMON pass; after a CUT it is the finished workpiece. So the selection loops compared barycentres of bored plates and registered those plates as “kept parts of the tool”, and PerformResult() then took the kept-parts path with a keep set containing no tool part at all. The caller got the input back with the cylinder’s faces imprinted on it — reported as BRepFeat_NoError throughout.

BRepFeat_Form and BRepFeat_RibSlot, the kernel’s other two users of the same builder, both call the two-argument SetOperation(myFuse, bFlag) with bFlag true. The patch is that call at the four part-selecting sites. Perform(Radius) selects no parts and is untouched, which is why .throughAll was the one extent that already drilled a stack correctly, and why the defect read as “multi-body” rather than “part selection”.

Two corrections to how #532 was originally scoped. PerformBlind is affected too — it was not named because the report came out of #496, which had newly wrapped only the other two extents. And the trigger is not “more than one body”: it is “the cut result has two solids”, which a single solid reaches — an 8mm bar drilled at r = 5 is severed by its own bore, and every part-selecting mode then removed nothing from it.

Measured on a compound of two 50 × 50 × 20 plates on the drill axis, where one bore removes 1570.7963:

A single plate is byte-identical before and after — its cut result was one solid, so the branch never ran. A channel and a hollow box, both one solid with two spans on the axis, give the same answer before and after while the selection loop goes from one part to two real tool parts.

One behaviour change beyond the bug. A radius so large the bore swallows the whole solid used to be .invalidPlacement for .untilEnd and .thruNext: under CUT the oversized tool emptied the builder’s shape, so nbparts was 0 and the “the tool meets nothing” guard fired. Under COMMON nbparts is 1 and both extents now return the empty result .throughAll and drilled(at:direction:radius:depth:) always returned. The #496 divergence “through-all status is a false green for the thru-next drill” was that accident, not a contract, and its test now pins the converged answer.

Issue532CylindricalHolePartSelectionTests (Tests/OCCTModelingTests), 7 tests, three of which deliberately cover geometry the fix must not disturb. Run against the last released kernel first: the four that pin the defect fail there and the three non-regression tests pass, which is the proof the suite is measuring the patch. Reproducer and full before/after tables in Scripts/repro/532-cylindrical-hole-part-selection/; a second, unreachable-as-written defect in PerformThruNext’s fallback brace nesting is reported there rather than changed.

One edge-index contract and one radius law for all five fillet entry points (#520)

The five BRepFilletAPI_MakeFillet edge-list functions disagreed on what an edge index means, on what an unresolvable one does, and two validated no radius at all. Settling those three questions turned up two defects the issue did not know were there.

filletedVariable never applied its radius profile. It mapped each relative parameter onto the edge’s own curve parameter range and called SetRadius(radii[i], param, 1). There is no (Real, Real, Integer) overload of SetRadius, so param was truncated to an int and taken as the contour index; the profile was discarded and the caller got a constant radius. Measured on a 20mm box, edge 0:

Two live SIGSEGV paths. A contour added by the law-taking Add(edge) overload that never receives a radius crashes Build(). It is an OS signal, so the bridge’s catch (...) never saw it and no nil could come back. Both routes were reachable from Swift: filletEvolving with an empty radiusPoints (the old code took neither of its two branches for a count of 0), and filletedVariable on any edge whose curve parameter range does not start at 0, where every truncated contour index exceeded NbElements() and every SetRadius was silently dropped. Box edges all start at 0, which is why the existing tests never saw it; the edges a boolean cut produces do not (6 of the 21 edges of one box cut by another).

Both radius-law entry points now resolve their edges through occtFilletAddEdges and apply their profile through the new occtFilletSetRadiusProfile (OCCTBridge_Internal.h), the same SetRadius(UandR, contour, 1) call OCCTShapeHistoryFromFilletEdgeVariable was already making correctly two functions away. So the same profile now gives the same shape through either entry point, which is pinned by a test.

Three contract changes.

Radius and parameter validation on the two radius-law functions. Neither inspected a single element before. This is not the redundant guard #489 measured for Add(radius, edge): through the profile overload a negative radius is not caught by OCCT at all, reporting IsDone() == 1 and handing back a shape BRepCheck_Analyzer rejects. The parameters are checked against the [0, 1] contract both doc comments already stated, and required to strictly increase, because OCCT renormalises a 3+ point profile with (U - Uf) / (Ul - Uf): equal parameters divide by zero, and descending ones silently reverse the law (7960.426609 against 7963.730821 for the ascending equivalent).

An index that names no edge of the shape rejects the call. Three of the five skipped it and reported success, filleting fewer edges than the caller asked for — a request honoured in part, presented as honoured in full, the same defect class as #439/#442/#443. The other two already rejected, so this is what makes the family agree.

EvolvingFilletEdge.edgeIndex is 0-based, matching Edge.index and every sibling; it was the one 1-based edge index in the family. Reinterpreting the same numbers would have quietly filleted the neighbouring edge for every existing caller, so the old spelling is @available(*, unavailable) instead: init(edgeIndex:radiusPoints:) fails to build with a message naming the base change, and init(edge:radiusPoints:) takes the Edge itself, the idiom filleted(edges:radius:) already uses. The four call sites in this repo’s own tests failed exactly that way and were migrated.

Ground truth for all of the above is in Scripts/repro/520-fillet-edge-index-contracts/. The new Issue520FilletContractTests suite was run against unmodified code first (#489’s lesson): 10 of its 13 then-runnable cases failed, 1 took the test process down with a SIGSEGV, and 2 passed — one of those for the wrong reason, since a 0-based index was out of range under the 1-based contract. Each guard was then re-checked by injecting the mistake back: the index guard fails 3 tests, the radius guard 2, the parameter guards 2, the empty-law guard SIGSEGVs 3 runs out of 3, and restoring the truncating loop both fails the profile test and SIGSEGVs the re-parameterised-edge test.

Bridge-only: no kernel patch, no xcframework rebuild, nothing filed upstream — passing a double where OCCT’s signature takes an int is our defect, not OCCT’s. Scripts/count-operations.py now skips @available(*, unavailable) declarations, which are retired spellings rather than entry points; the total stays 4295. The skip-an-out-of-range-index idiom survives outside this family, in OCCTShapeHistoryFromChamferEdges, OCCTShapeOffsetPerFace and the 2D fillet/chamfer vertex functions; those are a separate family and are left for their own issue rather than widened into this one.

Breaking: one meaning for a face index (#541)

A face index in this API is now one thing: a 0-based position in the enumeration Shape.faces(), Shape.faceCount and Shape.face(at:) all read — TopExp::MapShapes, one entry per distinct face (TopoDS_Shape::IsSame). It used to be three things, and the three disagreed.

Shape.faces() drove its own bare TopExp_Explorer, one entry per occurrence in the topology tree, and wrote the array position into Face.index. faceCount / face(at:) and most index-taking entry points read the deduplicated map. A handful read that map 1-based.

This is the case #502 (Pass 1b’s sub-shape traversal fix) deliberately left, because face indices are an addressing token the API hands out and takes back, and auditing every consumer is not a one-line change.

The defect was worse than #541 reported. Measured on the pinned kernel (Scripts/repro/541-face-index-contract/), fifteen fixtures walked both ways. The issue’s reproduction is a hand-built Shape.compound([face, face]), but one ordinary modelling operation produces the divergence: a single BRepAlgoAPI_Splitter run cutting a box with a plane leaves two solids sharing the one cut face — 12 occurrences over 11 distinct faces. And because that duplicate is not the last occurrence, every index after it is shifted:

So a caller selecting a face from faces() and handing it to drafted(faces:), shelled(openFaces:) or withoutFeatures(faces:) — all map-backed — drafted, opened or deleted a face it had not selected, with no error. #541’s reported symptom (face(at:) returning nil for an index faces() handed out) turns out to be the milder half.

The control matters as much: across the ten fixtures that share no face — primitives, a hollow solid, both booleans, a compsolid, a sewn sheet, two placements of one body — the two enumerations are identical at every index, compared face-by-face rather than by count. Converging them moves nothing on any shape that does not share a sub-shape.

What changed. OCCTShapeGetFaces reads occtMapSubShapes. The fourteen entry points that walked their own explorer to resolve an index (OCCTShapeClassifyPoint2D, OCCTShapeFaceDomainEdgeCount, OCCTShapeBuildLoops, OCCTShapeDraftModification, the three BRepExtrema_Ext*F extrema, the three LocOpe splitters, three ShapeFix/BRepAlgo healers and OCCTBRepCheckSubShapeValid) read occtFaceAt / occtEdgeAt / occtSubShapeAt instead. The 1-based entry points and index outputs moved to 0-based. Two new helpers in OCCTBridge_Internal.h carry the contract in one place.

Six silent behaviour changes, each recorded in SEMVER.md with its migration:

// faces() no longer double-counts a shared face
let pieces = block.split(by: knife)!            // one splitter run
let assembly = Shape.compound(pieces)!
assembly.faces().count      // was 12, now 11 — and now equal to assembly.faceCount
assembly.faces().allSatisfy { assembly.face(at: $0.index) != nil }   // was false, now true

// adjacency indices are 0-based, so they index face(at:) directly
for i in box.adjacentFaces(forEdge: edge) {
    box.face(at: i)!        // was box.face(at: i - 1)
}

// the buildWires sentinel moved off 0, which is a real face
box.buildWires(faceIndex: -1)   // every edge of the shape (was 0)
box.buildWires(faceIndex: 0)    // face 0's edges (was rejected)

Also 0-based now: splitByWireOnFace(_:faceIndex:), offsetPerFace’s faceOffsets keys (where an out-of-range key now fails the call instead of being silently skipped — the same silent-success failure #497 fixed for defeaturing), EvolvingFilletEdge.edgeIndex (the one fillet/chamfer entry point in the file that was 1-based), the Poly_Connect mesh family’s faceIndex (their triangle and node indices stay Poly_Triangulation-native 1-based, as do the triangle indices they return), and Selector.PickResult.subShapeIndex, whose “whole shape” sentinel moved from 0 to -1.

Shape.contents was left counting what it counts, and is now documented as doing so. ShapeAnalysis_ShapeContents is a fourth answer and a fifth: NbFaces tracks the explorer, while contentsExtended()’s nbSharedFaces strips the location before deduplicating, so unlike IsSame it also collapses two placements of one face. On a compound of a box with a moved(dx:dy:dz:) copy of itself the three read 12 / 12 / 6. It answers a different question — a complexity metric — and its docs now say so, with the warning that none of its numbers is an index bound.

Regression tests in Tests/OCCTTopologyTests/Issue541FaceIndexContractTests.swift; run against the unfixed bridge, seven of the ten failed and the three controls passed. Full suite green (4880 tests); the only fallout was one existing test whose helper subtracted 1 from adjacentFaces(forEdge:), and the selector tests that asserted the old sentinel.

Not an upstream defect — both OCCT primitives behave exactly as documented, and the kernel is not involved in the base convention at all. No kernel patch, no xcframework rebuild.

Every sampling entry point now bounds the count a caller can supply (#558)

#479 bounded two entry points and recorded that “the same shape is live at fourteen other sampling entry points”. Measuring the family before fixing it found twenty-eight, not fourteen: a caller supplies a count, it sizes a Swift allocation, and it is then cast to the int32_t the bridge takes its count in. [Double](repeating:count:) traps on a negative and Int32(_:) traps past Int32.max, so both ends abort the process rather than returning the documented empty value.

Measured one case per process, since a trap takes the whole harness down with it. Every one of the 28 either trapped or ground on an unservable allocation past 30 s at Int(Int32.max) + 1, and 20 of them trapped on -1. The fourteen the issue did not name are Edge.quasiUniformParameters(count:) (the same method, on the same GCPnts_QuasiUniformAbscissa, as the Curve3D one that was named), Curve3D.samplePoints(first:last:maxPoints:), Surface.drawGrid(uLineCount:vLineCount:pointsPerLine:), Shape’s edgePolyline, allEdgePolylines, edgePoints, contourPoints, uIsoCurvePoints, vIsoCurvePoints and coonsAlgPatch, Wire.orderedEdgePoints(at:maxPoints:), both MedialAxis drawers, and QuadricIntersection.coneSpherePoints.

The ceiling moves out of ArcLengthCurveAdaptor into Sampling.maximumSampleCount, still 10,000,000 and still the measured number #479 justified. EdgeCurve.maximumSampleCount / WireCurve.maximumSampleCount keep working and resolve to it, so nothing #479 shipped breaks.

The bound is not one rule, because the parameters do not mean one thing:

Two things the measurement changed about the fix as the issue specified it:

• The issue recorded Surface.drawMesh as returning .empty for a negative count. It does, but only when the negative goes to both factors. (-1) * (-1) is 1, a perfectly plausible total, so the allocation succeeds and the bridge rejects the counts on its own. drawMesh(uCount: -1, vCount: 3) is -3 and aborts the process. Bounding only the product would have left that live, so each factor is checked individually as well. Confirmed by injection: with the per-factor check removed, the new suite aborts with Fatal error: Can't construct Array with count < 0 at exactly that case. The same masking applies to Surface.drawGrid and MedialAxis.drawAll.
• MedialAxis.drawArc’s parameter is named maxPoints, but it is a request. The bridge does numPoints = maxPoints and fills the buffer exactly, so it returns precisely the count asked for (and nothing at all below 2), unlike the genuinely adaptive samplers that share the name. It was written as a capacity first; the verification sweep caught it returning a full 10,000,000 points for a clamped absurd input, which is the coarsening the clamp was supposed to be immune to. It rejects instead.

The multiplications are overflow-checked rather than assumed in range: Int wraps into a trap of its own well before the ceiling is reached, and drawGrid’s two line counts are bounded before being added for the same reason.

Regression suite: Tests/OCCTCurveTests/Issue558SamplingCountBoundsTests.swift, 21 tests. They run in-process only because the fix is what lets them: before it, every assertion in them would have aborted the test harness rather than failing. They compare .count == 0 rather than reading .isEmpty because Swift Testing prints the captured sub-expression on failure, and a regression returning 10 million points would print all 10 million (measured at over 5 GB while injecting a deliberate bug to confirm the suite catches it; #479 hit the same hazard at 880 MB).

The closest point on a curve is now on the curve (#539)

Curve3D.projectPoint(_:precision:), Curve3D.distance(to:precision:), Edge.project(point:) and Edge.distance(to:) all promise the closest point, and none of them delivered it. They had picked a different OCCT call each, and each call is wrong in its own way about a curve that has ends:

Truth for those four rows: 92, 7.81, 4.47, 19.60. A distance < tolerance proximity test read the first three as “the point lies on the curve”.

Three distinct defects, not one. ShapeAnalysis_Curve::Project solves on the basis curve for an analytic type, so a parameter outside the domain comes back as though it were on the curve — passing the range does not help, the 7-argument overload documents itself as extending it, and its AdjustToEnds flag changed no measured answer either way. GeomAPI_ProjectPointOnCurve honours the range but returns extrema rather than minima, so the only extremum in range can be a maximum, and it finds nothing at all when the nearest point is an end. And on a parabola or hyperbola both answered with the worst point in range — the defect a parameter clamp, which is what the issue proposed, would not have touched.

Both entry points now share one occtNearestPointOnCurveRange, which takes the minimum over three candidate sources: ShapeAnalysis_Curve’s answer where it landed inside the range, every extremum GeomAPI finds inside the range, and the range’s own ends. Correct on all 51 curve/point combinations swept against a dense brute-force reference (line, circle, ellipse, parabola, hyperbola, Bezier, BSpline and offset curves, trimmed and not), where ShapeAnalysis_Curve alone was right on 37 and GeomAPI alone on 25. Periodic bases need no special handling and get none: Geom_TrimmedCurve normalises its own domain and Project returns the representative nearest it, verified over ten seam-crossing and beyond-one-period cases.

Behaviour changes for callers. Edge.project(point:) and Edge.distance(to:) stop returning nil for a point with no perpendicular foot — every one of a box’s twelve edges used to answer nil for a corner probe outside the box. nil now means what the documentation always said it meant: an edge with no 3D curve. Ordinary in-range projections, unbounded curves and closed curves are unchanged, which is why no pre-existing test moved: every one of them queried a point that has a perpendicular foot.

Curve3D.nearestParameter(to:) (#500) is deliberately untouched and still reports nil for the points above. The two are different questions — the nearest point, which exists for every query point, versus the nearest perpendicular foot, which does not — and Issue500Curve3DNearestParameterTests pins the distinction, updated here to the corrected answer it recorded as-is.

Measured here, fixed in #580. Shape.pointEdgeExtrema(point:edgeIndex:) (BRepExtrema_ExtPC) is a third entry point documented as finding “the closest point on the edge” with the same defect: 11 for the half-circle query above, and IsDone() false for both trimmed-segment queries. It was left out of this change because fixing it meant first deciding what its solutionCount, the extrema count it deliberately exposes, should say when the answer is an end — so that decision was measured here rather than left open, and acted on in #580 above, in the same release.

New suite Issue539NearestPointOnCurveTests (OCCTCurveTests), 12 tests. Proved rather than assumed: reinstating the two original implementations fails 9 of the 12, and the 3 that still pass are exactly the three asserting what was meant to stay the same.

One defeaturing operation, not one per OCCT layer (#536)

Shape.removeFeatures(faces:) and Shape.defeature(faces:) took the same arguments, returned the same type, and neither doc comment mentioned the other. They were the same operation: defeature drove BRepAlgoAPI_Defeaturing, removeFeatures drove BOPAlgo_RemoveFeatures, and BRepAlgoAPI_Defeaturing::Build is a 30-line forwarder that hands its shape, its faces, its history flag and its parallel flag to a BOPAlgo_RemoveFeatures member and returns that member’s result — with Modified, Generated, IsDeleted, HasModified, HasGenerated, HasDeleted and History all one-line delegations to the same member. The bridge had wrapped both layers of one algorithm and given each its own Swift name. This is the sixth spelling of the operation #497 consolidated, left out of that pass because it reached a different OCCT class.

Measured, not read off the source. A deprecation has to answer “is there any input on which they can differ”, not “do they agree on a box”, so both paths were driven exactly the way their bridge wrappers drove them — including the different completion tests, IsDone() against !HasErrors() — over every face of a filleted box in turn, a through hole, a boss, two holes at once, and the requests that fail (no faces, a face from another shape, a mixed request, an input that is not a solid, the same face twice). Identical in every case, compared as full BREP serialisations rather than volumes. The option defaults the forwarding depends on match too (myFillHistory true on both constructors, myRunParallel false from the shared BOPAlgo_Options base), which is what made the two unconfigured objects the same object. Probe and full output at Scripts/repro/536-defeature-removefeatures-unify/.

defeature(faces:) survives — it is the class OCCT documents for application use, it is where the history-carrying sibling already lives, and since #497 it shares one bridge skeleton with the rest of the family. removeFeatures(faces:) is deprecated and forwards to it, with a renamed: fix-it. OCCTBOPAlgoRemoveFeatures is deleted rather than kept for a future caller: OCCTBridge is a target, not a product, so nothing outside this package can link it, and #506 measured what keeping an orphan costs — it freezes whatever contract it had, and this one had drifted already, silently skipping a null entry in the faces array where the surviving path fails the call. That particular drift was not reachable from Swift, since [Shape] has no null elements; it is what an orphaned copy looks like after one side gets a fix, which is the argument against keeping it.

Not fixed, and now written down. A face that is not part of the input is dropped from the request rather than refused: a request mixing one real face with one foreign face succeeds, removes the real one, and emits no warning at all, while a request of nothing but foreign faces fails because nothing is left to remove. That is more forgiving than the index-addressed withoutFeatures(faces:), which since #497 fails the whole call on one bad index. Making the two agree is not a line of validation: AddFaceToRemove takes a TopoDS_Shape and its own documentation calls it “the shape to extract the faces for removal”, and the kernel duly accepts a compound, a shell or the whole input solid as a face carrier — measured. Deciding what a membership rule does with those is its own question, so it was filed separately as #578 and settled there; the behaviour was documented on defeature(faces:) in the meantime, along with the fact that membership is identity, not geometry (a face measured off a separately built but identical shape is foreign).

New suite Issue536DefeaturingSpellingsTests (OCCTModelingTests) compares the two spellings face by face on three fixtures, pins all four spellings of one removal against each other, and pins the membership contract above. Proved against three injections rather than assumed: a forwarder that returns its input unchanged, one that drops the last requested face, and a defeature that reports failure as the input shape each fail the tests that cover them, and only those.

Breaking: one resolution behind the adaptor-backed local properties too, and the raycast normal it was quietly erasing (#529)

#494 converged all 28 GeomLProp_SLProps / GeomLProp_CLProps / GeomLProp_CLProps2d constructions in the bridge onto Precision::Confusion() and recorded the BRepLProp_* half as a separate job on the grounds that it is “a different class family”. It is not. In OCCT 8.0 BRepLProp_SLProps.hxx is nine lines long:

using BRepLProp_SLProps = GeomLProp_SLPropsBase<BRepAdaptor_Surface>;

The same header-only template GeomLProp_SLProps aliases, over an adaptor instead of a Geom_Surface handle. Same Resolution argument, same meaning, so the 18 sites passing a literal 1e-6 were asking whether a quantity exists at a threshold a decade looser than the sites they sit beside. Measured on the pinned kernel, that decade is exactly where they disagreed: on a cone face approaching its apex, Shape.faceLPropMeanCurvature(u: 0, v: 1e-6) returned 0 — its spelling of “undefined” — where Face.meanCurvature(atU: 0, v: 1e-6) returned -8.66e5 for the same point of the same face, and the disagreement ran down to v = 3e-7. All 18 now build through occtFaceLocalProps / occtEdgeLocalProps, alongside #494’s occtSurfaceLocalProps and friends.

The census in the issue was three counts off, in the direction of more work rather than less:

raycast(tolerance:) was erasing its own normals. OCCTShapeRaycast forwarded the caller’s tolerance twice: to IntCurvesFace_ShapeIntersector::Load, where it is the intersection distance it is documented as, and to BRepLProp_SLProps, where it becomes the resolution — which CSLib::Normal uses as a sine tolerance on the angle between the two parametric directions. That quantity is dimensionless and saturates. Measured: raycast(tolerance: 1.0) against a sphere reported no normal for either hit, so both fell back to (0, 0, 1); at 5.0 a box’s downward face came back pointing up. The intersection tolerance now stops at Load. RayHit also gains normalDefined, because the (0, 0, 1) fallback is otherwise indistinguishable from a real upward normal at a genuinely singular hit point. (Additive: RayHit’s memberwise initialiser is internal, so no caller constructs one.)

The curvature-inversion defect #494 found is on this side too, and 1e-6 made its window a decade wider. LProp_CurveUtils::Curvature() returns RealLast() to mean infinite curvature at a cusp, on a path that never assigns the myCurvature field; CentreOfCurvature() tests only |Curvature()| <= resolution, which the sentinel passes, and then divides by that unassigned field. Normal() rejects the sentinel by name and throws; CentreOfCurvature() hands back a point of (nan, inf, nan) as a success. Both edge entry points that invert a curvature now gate on occtCurveCurvatureIsInvertible, the predicate #494 added. Measured on a cubic Bezier whose first two poles sit a controlled distance apart, at u = 0:

Source-breaking, in four places, all of them entry points that could not previously say “there is nothing here”: Shape.edgeNormalLP(at:) and Shape.edgeCentreOfCurvature(at:) return SIMD3<Double>? rather than SIMD3<Double> (they returned (0, 0, 0) — not a direction, not a point — where the quantity does not exist), and Shape.edgeLPropD1(at:) joins them. Not a signature change but a behaviour one: Shape.edgeLPropValue(at:) was already declared optional and never returned nil; now it does.

Two of the three Topology.mm sites were orphans and are deleted rather than converged. OCCTShapeGetHorizontalFaces and OCCTShapeGetUpwardFaces reimplemented Face.isHorizontal / Face.isUpwardFacing over the same midpoint normal, and nothing called them: Shape.horizontalFaces and Shape.upwardFaces filter faces() through the Face predicates. Same reasoning as #506 — OCCTBridge is a target, not a product, and an orphan freezes whatever contract it had when it was orphaned, so leaving them would have meant maintaining a second 1e-6 behind a symbol with no callers.

The surviving Topology.mm site’s change is inert, and that is a measurement, not an assumption. CSLib::Normal tests the two first derivatives for nullity against gp::Resolution() — a fixed ~1e-300 epsilon, not the caller’s value — and uses the caller’s value only as the sine tolerance above. A surface whose derivatives merely shrink keeps a defined normal all the way down, which is why tightening the value changes nothing for the normal-only sites. Swept over every face of a box, cylinder, sphere, apex cone, frustum, torus, hemisphere, a fully filleted box and the 662 faces of unify-crash-mmd-kiha10-body5.brep: zero faces changed definedness, zero changed direction, and the horizontal (18) and upward (9) counts on the real fixture are identical before and after. The one geometry that does move is a nearly singular parameterisation — a linear extrusion skewed by 5e-7 radians, whose normal is undefined at 1e-6 and defined at Precision::Confusion().

New suites AdaptorLocalPropsParityTests and AdaptorNormalDecisionTests (OCCTAnalysisTests), 11 tests, following #494’s LocalPropsParityTests pattern: each adaptor-backed entry point is asserted to agree with its Geom_-backed counterpart about definedness exactly, and about value to a relative tolerance — not bit for bit, because a BRepAdaptor_Curve evaluates a Bezier or BSpline through a cache the raw handle does not use, which moves the last ULP (measured: 0.67461923686773151 against 0.6746192368677314 for the same curvature). Proved against three separate injections rather than assumed: restoring the 1e-6 resolution fails 4 tests, removing the two invertibility gates fails 1 (on the (nan, inf, nan) centre), and restoring the raycast tolerance forwarding fails 2. Four tests are controls and pass under all three.

Probes and full figures at Scripts/repro/529-breplprop-resolution/. Bridge-only: no kernel patch, no OCCT.xcframework rebuild.

Noticed, and fixed separately. The face-side curvature getters (faceLPropMaxCurvature and its four siblings) still spelled “undefined” as 0, where the Face counterparts return nil: the silent-zero class #486 and #494 have both hit, and more source-breaking signatures on top of the four here. Filed as #583 rather than folded in; see the next entry.

Breaking: a curvature of zero and no curvature at all stop being the same answer (#583)

Shape.faceLPropMaxCurvature(u:v:) and its four siblings returned the value bare and used 0 (or (0, 0, 0) for faceLPropValue(u:v:)) to mean three different things at once: the curvature is undefined at this point, the handle was null, and this Shape is not a face. #529 had just made them agree with Face.meanCurvature(atU:v:) and friends about whether a quantity exists; they still had no way to say so.

That encoding has no spare value to spend, which is a measurement rather than a style objection. Read through the same BRepLProp_SLProps the bridge builds:

So the sentinel collided with the answer across whole faces of the two commonest solids in the test suite, not at some pathological parameter; and faceLPropIsUmbilic(u:v:) answered false, “the principal curvatures differ here”, at points with no principal curvatures to compare.

Source-breaking, in six places. The five the issue names return an optional: Shape.faceLPropValue(u:v:) → SIMD3<Double>?, and faceLPropMaxCurvature(u:v:), faceLPropMinCurvature(u:v:), faceLPropMeanCurvature(u:v:), faceLPropGaussianCurvature(u:v:) → Double?. The census turned up a sixth in the same block: faceLPropIsUmbilic(u:v:) → Bool?, whose false was the same conflation one type down. faceLPropValue is the one whose contract narrows rather than changes: the point does not depend on the curvature gate, so it is still reported at a cone apex and a sphere pole, and nil there means only “not a face”.

Migration is if let at the call site; the previous behaviour is ?? 0, which is what every caller that ignored the distinction was already getting.

New suite AdaptorCurvatureDefinednessTests (OCCTAnalysisTests), 4 tests, and the three AdaptorLocalPropsParityTests workarounds come out: the parity claim is now (adaptor != nil) == (geom != nil) on every sampled point, the way the edge half of that suite already asserted it, instead of comparing values only where the Geom_ side happened to report one. Proved against two injections rather than assumed: making the curvature gate unreportable (undefined comes back as a successful 0) fails 2 tests, and making the catch unreportable (a non-face Shape comes back as a successful 0) fails 1. Seventeen and eighteen tests respectively are controls and pass under both.

Not changed here, and fixed as #595 (next entry). Six entry points on other types keep the same bare double: Curve3D.curvature(at:), Curve3D.localCurvature(at:), Curve2D.curvature(at:), Shape.edgeCurvatureLP(at:), Surface.gaussianCurvature(atU:v:) and Surface.meanCurvature(atU:v:). The last two disagree with both Face.gaussianCurvature(atU:v:)/meanCurvature(atU:v:) and with their own neighbour Surface.principalCurvatures(atU:v:), which is already optional. A straight edge’s curvature is genuinely 0 and a fully degenerate curve’s is undefined, so the collision is identical; each is a separate public type with its own break surface, so folding them in would have repeated exactly the mistake this issue exists to avoid.

Probe and full figures at Scripts/repro/583-lprop-zero-sentinel/. Bridge-only: no kernel patch, no OCCT.xcframework rebuild.

Breaking: the same zero, on four more public types (#595)

The follow-up #583 filed. Nine entry points now report whether there is a curvature to report, instead of answering 0 when there is not:

Migration is if let; the previous behaviour is ?? 0.

The census was six and measured nine. Three decide “undefined” with a hand-rolled magnitude gate rather than an OCCT predicate, so a grep for Is*Defined() — which is how the issue’s list was built — cannot see them:

• Curve3D.torsion(at:) answered 0 where the first two derivatives are parallel and there is no osculating plane to twist out of. A planar curve’s torsion is genuinely 0, and every circle and ellipse is planar, so the collision runs the other way from the curvature rows and is just as ordinary. It sits four lines below curvature(at:) on the same type; leaving it would have broken Curve3D’s source compatibility twice for one defect.
• Surface.curvatures(u:v:) returned a bare (0, 0). Its own documented contract is that it agrees with gaussianCurvature(atU:v:) and meanCurvature(atU:v:) “including on whether curvature is defined at all” — which it shares one GeomLProp_SLProps with, and could not say.
• Wire.curvature(at:) already returned Double?, but only its -1.0 error path reached that optional. The null-derivative branch — a cusp, where the formula divides by zero — returned 0.0, a straight wire’s real answer. No signature change; the branch stops lying. It has no infinity sentinel to offer instead: BRepAdaptor_CompCurve computes the formula directly rather than through GeomLProp_CLProps, so nothing is the honest answer.

The collisions are ordinary geometry, not constructed pathologies. Measured through the same kernel classes the bridge builds:

The edge row is the one worth reading twice: a sphere carries a degenerate edge at each pole, that edge has no 3D curve at all, and Shape.edge* traversal does not skip it.

A cusp is not an absence and is unchanged. OCCT reports RealLast() there, meaning infinite curvature, and Double.greatestFiniteMagnitude still comes through as a value. It is a real, distinct answer that a Double? has no room for, and it is why the curve half of this family looked better covered than it was.

Curve3D.localCurvature(at:) is deprecated onto curvature(at:), and OCCTCurve3DLocalCurvature is deleted. #494 converged their resolutions, after which the two built the same GeomLProp_CLProps at the same occtLocalPropsResolution() and gated on the same IsTangentDefined(). Per #562’s rule, the axis to check before collapsing is the one nobody listed: here that is the null-handle guard, and it is unreachable from Swift since both wrappers pass a live handle. Measured over the same four curves, including both degenerate rows, the two spellings disagreed on 0 of them.

OCCTWireGetCurvatureAt, OCCTCurve2DGetCurvature, OCCTCurve3DGetCurvature, OCCTCurve3DGetTorsion, OCCTEdgeLPropCurvature, OCCTSurfaceGetGaussianCurvature, OCCTSurfaceGetMeanCurvature and OCCTSurfaceCurvatures return bool with the value as an out-parameter, the shape OCCTFaceGetMeanCurvature and (since #583) OCCTFaceLPropMeanCurvature already use. C-layer contract change; OCCTBridge is not an SPM product (#486).

Deliberately excluded. Edge.dihedralAngle(between:and:at:) has the same hand-rolled shape but returns -1, outside its documented 0...2π range, and its wrapper already maps that to nil — a distinguishable sentinel that already reaches the caller as an absence. The Local*/GeomLProp* families already carry an isDefined out-parameter (#494).

Banked, not changed. Two thresholds stay exactly where they are, because this pass changes how an absence is spelled, not where the boundary between presence and absence falls: OCCTCurve3DGetTorsion compares a squared magnitude against the linear Precision::Confusion() (an effective gate of 3.16e-4 on |d1 x d2|), and OCCTWireGetCurvatureAt keeps its literal 1e-10 on |d1|, the last hand-rolled resolution in the local-properties family after #494 and #529 converged the rest.

New suite Issue595CurvatureDefinednessTests (OCCTAnalysisTests), 9 tests. Proved against two injections: making every definedness gate unreportable fails 8 of the 9 (the cusp test is the control, correctly, since a cusp is not gated); making every catch unreportable fails 1, the not-an-edge case, with 8 controls.

Probe and full figures at Scripts/repro/595-curvature-zero-sentinel/. Bridge-only: no kernel patch, no OCCT.xcframework rebuild.

The PrecisCode census counted a commented-out call site and missed a live one (#573)

OCCTBridge_Surface.mm carries a census of how OCCT itself splits on GeomConvert_ApproxSurface’s PrecisCode argument. It is load-bearing: it is the stated justification for #491 settling both surface approximation entry points on 0. It was built by grepping for the class rather than by reading each hit, so it counted BRepFill_Sweep.cxx:1162, which sits inside a /* */ block spanning :1064 to :1179 and is not compiled, and it missed BRepOffset_Offset.cxx:1626 and the second GeomConvert_1 site (:960) entirely. The live set is 2 sites passing 0 and 6 passing 1:

#491’s conclusion is unchanged, but its stated reason was slightly wrong. The split is not “caller’s tolerance versus hardcoded internal tolerance”: BRepOffset_Offset takes the caller’s TolApp and still passes 1, because it gates on IsDone() and never checks the fit against the tolerance it was given. What the two groups actually divide on is whether the site verifies the result, which is the property that puts this bridge in the 0 group. The comment now records that, names both commented-out mentions so the next reader does not re-add them, and says why the two Draw/QA harness sites and GeomPlate_MakeApprox (which drives AdvApp2Var_ApproxAFunc2Var directly and has no PrecisCode, see #571) are outside the list.

Comment-only, no behaviour change. The same correction is applied to Scripts/repro/491-approx-wrapper-drift/ and to #491’s entry below; #522’s own notes had already been corrected. The eight other bridge comments that cite OCCT source (13 line references between them) were checked the same way and all point at live code that says what the comment claims, including the one that correctly describes AdvApprox_ApproxAFunction.cxx:550 as commented out upstream.

Breaking: the last five entry points that quietly dropped an unresolvable index (#568)

A sub-shape index naming nothing now rejects the request everywhere, not just in the fillet family. #520 settled that for the five BRepFilletAPI_MakeFillet edge-list functions and #541 for Shape.offsetPerFace; five sites in the neighbouring families still skipped the entry and built from whatever resolved.

Why this is not tidiness. Measured on the pinned kernel (Scripts/repro/568-index-skip-idiom/), every builder behind these sites reports an ordinary success for a batch it was never told was short. The partial result is IsDone, non-null and BRepCheck_Analyzer-valid; it differs from the complete one only in geometry the caller has no reason to re-measure:

Shape.drafted was the worst of the five, and only the measurement showed it. Handed no faces at all, BRepOffsetAPI_DraftAngle still reports IsDone() and returns the input shape unchanged (volume 8000 for the same box). So a draft naming only faces the shape does not have (the ordinary result of passing Face values taken from a different shape) succeeded and drafted nothing. The other four at least fail an empty batch (MakeChamfer throws “There are no suitable edges for chamfer or fillet”; MakeFillet2d fails IsDone), and Shape.shelled had its own empty check, which is why for those the mixed batch was the only case that escaped.

The census the issue filed was three ways off, each found by measuring rather than reading:

• Shape.offsetPerFace was on the list but had already been fixed by #541, which also settled the “is a dictionary of overrides different?” question the issue asked: an override naming no face is an invalid request, not an absent override.
• Two entries were filed against OCCTWireFilletAll2D / OCCTWireChamferAll2D, which take no indices at all. Their line numbers pointed at OCCTFace2DFillet / OCCTFace2DChamfer, which do, and those are what is fixed here. Same failure mode as #565’s own mis-filing: trust the line, not the name.
• Two sites the issue did not list, OCCTShapeDraft and OCCTShapeShellWithOpenFaces, spell the skip as an if (idx >= 0 && idx < map.Extent()) { … } wrap rather than a continue, so a census grepping for the continue spelling missed them, including the draft, the most severe of the five.

One resolution helper, not five loops (the issue’s second question). occtUseSubShapesByIndex and occtMappedSubShapeAt (OCCTBridge_Internal.h) resolve a caller’s index array through occtMapSubShapes, the enumeration #502 and #541 already made canonical, and refuse on the first index that names nothing. occtFilletAddEdges is now a five-line wrapper over it, since only the TopoDS_Edge cast was ever fillet-specific, so the fillet family and these five share one statement of the contract rather than agreeing by coincidence. OCCTFace2DChamfer is the one site whose entries name two sub-shapes each, so it reads the map through occtMappedSubShapeAt directly.

Bridge-only: no kernel patch, no OCCT.xcframework rebuild. No operation count change.

Migration. A call that used to succeed by dropping indices now returns nil. Filter your own indices against Shape.faces().count / Shape.edges().count / face.vertices().count if you want the old best-effort behaviour. The difference is that you now choose it.

Three orphaned arc-length bridge functions deleted, and they were not spare copies (#506)

OCCTCurve3DArcLength, OCCTCurve3DArcLengthBetween and OCCTCurve3DLength are gone. #408 routed totalArcLength, arcLength(from:to:) and arcLengthBetween(_:_:) through length / length(from:to:), which call OCCTCurve3DGetLength / OCCTCurve3DGetLengthBetween, leaving all three declared, compiled, and unreachable from Swift. #461 kept them “for C-ABI stability”. That rationale does not survive contact with the packaging: OCCTBridge is a target, not a product, so nothing outside this package can link those symbols through SwiftPM. The layer’s actual stability contract is now written down rather than asserted per PR, in docs/architecture/overview.md under design decision 6.

Keeping them was not free. Retaining an orphan freezes whatever contract it had when it was orphaned, and these three were frozen before two separate fixes. All three returned 0 on failure, the collapse of “the computation failed” into “the curve is genuinely zero length” that #408 fixed. OCCTCurve3DLength also measured through a pre-bounded GeomAdaptor_Curve(curve, u1, u2) instead of passing the range to GCPnts_AbscissaPoint::Length(adaptor, u1, u2), and the two forms disagree wherever the range is not an ordinary in-domain interval. Measured against the pinned kernel on a 5-point interpolated BSpline, 360.99 long:

So the “dead copy” still extrapolated a BSpline’s polynomial past its knots, the behaviour #477 removed from every reachable path, and still read a reversed range as zero length. One rewire or one copy-paste and both defects were back, with no test anywhere to catch it. Probe and full figures at Scripts/repro/506-arclength-adaptor-divergence/.

New suite Issue506ArcLengthBridgeContractTests (OCCTCurveTests) pins the surviving behaviour on exactly the four ranges where the forms diverge, with the clamping assertions checked against a chord-sum reference rather than against the implementation’s own answer for the whole domain. Proved against two injections rather than assumed: restoring the pre-#408 wiring fails the cross-spelling test on all three divergent ranges (0 against 173.76, 8489.78 against 360.99, 1.34 against 0), and rewiring length(from:to:) itself onto the pre-bounded form, the accidental-rewire case, fails all four tests.

Noticed, not fixed. length(from:to:)’s NaN handling is curve-type dependent: a NaN bound reports nil on a line, a segment and a circle, but on a BSpline GCPnts_AbscissaPoint::Length returns a plausible number (0 for a NaN upper bound, the whole length for a NaN lower bound), so the failure-versus-zero distinction #408 established holds for the curve types its own tests use and not for BSplines (#548). Separately, Curve2D.arcLength(from:to:) measured through the 2D pre-bounded adaptor deliberately, documented as range-checked, so the 2D and 3D spellings of the same call differed on a reversed range (#549, fixed above in this same release once the 2D form turned out to extrapolate as well). Both are #408/#409 contract questions rather than duplication, so they were filed rather than folded in here.

The PointsToBSpline index entry, and the controls it hid that do nothing (#507)

OCCTBridge.h’s cross-reference index credited GeomAPI_PointsToBSpline to a single function, OCCTCurve3DFit, which does not exist anywhere in the repo. A census of what actually constructs that class found five call sites, not one: OCCTCurve3DFitPoints (the real name behind the index entry), OCCTPointsToBSplineWithParams, OCCTPointsToBSplineWithParameters, the 14-function OCCTBSplineApproxInterp* family, and OCCTWireCreateBSpline, which the issue’s own site list did not have either. All five are now indexed.

Two neighbouring entries were wrong in the same way and are corrected with them. GeomAPI_PointsToBSplineSurface credited OCCTSurfacePlateThrough, which does not use that class at all (it is GeomPlate_BuildPlateSurface plus GeomPlate_MakeApprox, and is now indexed there instead), and omitted OCCTPointsToSurfaceBSpline and four of the five OCCTSurfaceNLPlate* functions. Geom2dAPI_PointsToBSpline had no index entry at all despite backing three functions. The GeomAPI_PointsToBSpline expansion section header covered four functions across three different OCCT classes; it now names all three.

The larger find was behind the mis-attribution. Approx_BSplineApproxInterp was removed in OCCT 8.0.0p1 and its 14-function bridge family was reimplemented on GeomAPI_PointsToBSpline, but the header, the Swift wrapper and docs/reference/GeometrySolvers.md still documented the removed solver’s controls as live. Five of them do nothing: interpolatePoint(_:withKink:), setParametrizationAlpha(_:), setMinPivot(_:), setClosedTolerance(_:) and setKnotInsertionTolerance(_:). performOptimal(maxIterations:) is perform() with the iteration count discarded. nbControlPoints and continuousIfClosed are advisory. setConvergenceTolerance and setProjectionTolerance are one shared tolerance, not two knobs, and the projection one can only tighten it. The reference page also attributed maxError to GeomAPI_PointsToBSpline::MaxError, a method that class does not have: the bridge computes it by projecting each input point back onto the fitted curve with GeomAPI_ProjectPointOnCurve.

Every one of those claims is now a test. The existing four tests asserted only isDone, which is why the drift went unnoticed, so BSplineApproxInterpContractTests pins each contract by comparing densely sampled fits for exact agreement, with a control test proving the comparison does register a real change when the fit tolerance moves. Checked against a deliberate reimplementation of SetAlpha on Approx_ParametrizationType: the no-op test fails and the other six stay green. The deviation that injection produced was 2.2e-14, so exact equality rather than a tolerance is what catches it.

No behaviour changed.

The 12 bridge symbols that never said “OCCT”, and the index entry for a symbol that never existed (#508)

Of ~1161 bridge function declarations, twelve began OCT rather than OCCT — the whole GC_MakeCircle2d/Ellipse2d/Hyperbola2d/Parabola2d family, consistently misspelled across the header, the .mm, and the Swift call site since v0.105.0. Nothing was broken; the mismatch was internally consistent end to end, which is exactly why it survived.

The obvious fix was to insert the missing C. Instead the family is now OCCTCurve2DMake*, matching OCCTCurve2DMakeLineThroughPoints/OCCTCurve2DMakeLineParallel — the GC_MakeLine2d wrappers declared two lines away, the direct sibling of these four classes. The old name was a second inaccuracy layered on the first: GCE2d is a different OCCT package, and v0.156.0 already moved these implementations off it when OCCT 8.0.0 deprecated GCE2d_X into a using alias for GC_X2d. That release deliberately kept the C names for ABI reasons that no longer apply, so a grep for the package these functions were named after led away from the code, not to it.

The header’s cross-reference index carried a matching but distinct error: its one GC 2D entry read GC_MakeLine2d → OCCTGCE2dMakeLine* (bridge symbols retain GCE2d historical name). That prefix has zero occurrences anywhere in the repo — it named neither the conic family nor the line functions it claimed to describe. All five GC_Make*2d families are now indexed under their real symbols.

Scripts/check-bridge-index.py, written for #484/#510 to catch precisely this, could not see the entry: it stripped only a (vX.Y.Z) suffix, so the trailing prose aside left the symbol glued to the annotation and the entry was silently skipped rather than reported stale. It now strips any parenthetical, which also un-hides two further entries that were being skipped for the same reason (both resolve). The stale count is unchanged at 135 — the #510 backlog, untouched here.

Documentation for this family named a fourth variant, gce_MakeCirc2d/gce_MakeElips2d/ gce_MakeHypr2d — a real OCCT package, but not the one these twelve call. Corrected to the actual GC_Make*2d classes, along with two rows elsewhere in API_REFERENCE.md left stale by the same v0.156.0 migration (Curve2D.segment is GC_MakeSegment2d; Curve2D.ellipse constructs Geom2d_Ellipse directly and never went through GCE2d_MakeEllipse).

Four tests close the coverage hole the audit found alongside the naming drift: gceCircleParallel, gceEllipse(s1:s2:center:) and gceHyperbola(s1:s2:center:) had no test at all. They assert measured geometry rather than non-nil, and were verified to fail against injected defects — a flipped parallel-offset sign, and swapped S1/S2 apex points. No public Swift API changed; OCCTBridge is not an SPM product, so the C-layer rename reaches no consumer.

The 2D solvers’ circle radius: measured per family, guarded in all of them (#553)

The last unresolved part of the 2D circle-radius family, split out of #514. About 25 sites in OCCTBridge_Geom2d.mm build a gp_Circ2d from caller-supplied doubles as an input to a tangency, bisector, intersection or extrema solver rather than as geometry being returned. #514 stopped there on purpose: a zero-radius circle handed to such a solver is geometrically a point, and several of them have a documented answer for a point argument, so guarding blindly could have removed a query some callers were legitimately making.

So it was measured, per family, against OCCT’s own point overload of the same query. The probe is at Scripts/repro/553-gcc-zero-radius-circle/. No family answers the point question:

The duplication has a cause worth recording: tangency to a circle of radius 0 satisfies the enclosing and the outside qualifier at once, so the solver enumerates each solution twice. And the hyperbolas of major radius 0 are the same degenerate conic occtValidHyperbolaRadii refuses to construct on the other side of this file, so the bisector families were handing back curves the construction API would not accept.

Every one of those families already has a point entry point in the same API — GccAnaBisector.ofPoints, ofLineAndPoint, Curve2DGcc.lineParallelThrough, linePerpendicularThrough, Shape.circleThrough3Points, the point/point line solvers, and the mixed circle/point overloads. Naming a point as a point already has a spelling, and a degenerate circle is not it. Guard, in every family — a decision reached per family, which converged.

Negative was never the gap. gp_Circ2d’s constructor is constexpr in the header, so its Standard_ConstructionError_Raise_if(theRadius < 0.0, …) does run in a bridge translation unit — the same finding #514 made for gp_Elips2d — and the existing catch already turned it into an empty result. GC_MakeCircle2d reports gce_NegativeRadius, a status rather than a macro, so No_Exception does not void that either. The new guards change what zero does, nothing else.

Two more radius contracts in the same file were converged onto the same predicate while the family was open:

• The radius of the circle a solver must find. OCCTGccCircle2d2TanRad, OCCTGccCircle2dTanPtRad and OCCTGccCircle2d2PtRad each spelled radius <= 0 inline; four siblings did not check at all. Measured, GccAna_Circ2d2TanRad and GccAna_Circ2dTanOnRad asked for radius 0 return solution circles of radius 0. All seven now share occtValidCircleRadius.
• Four producer sites #514 did not reach. BRepBuilderAPI_MakeEdge2d reports IsDone() for a zero-radius arc and returns a zero-length edge with both vertices at the centre; GC_MakeCircle2d(ax, 0) succeeds. Curve2D.gceCircleParallel needed the offset checked as well: measured, GC_MakeCircle2d takes the absolute value of radius + dist, so radius 5 offset by -5 gives radius 0 and by -6 gives radius 1 — a circle the caller did not ask for, not a refusal.

Every affected Swift entry point now documents its radius contract with a runnable snippet; none of them mentioned it before. A rejected radius returns an empty array (or nil for the producers), which is what these entry points already returned for “no solutions”, so no call site has to move.

22 tests in Tests/OCCTGeom2dTests/Issue553GccZeroRadiusTests.swift, run against a build with the zero rejection removed: 16 fail, and the 6 that do not are the four valid-input controls, the negative-radius test, and the two cases where OCCT’s own wrong answer is itself an empty set (circleTangentCircle2Points and distanceFromPointToCircle), which no assertion can discriminate. Both are noted as such in the test file.

Not changed: extractBisecSolution’s default branch writes (0, 0) for a GccInt_Pnt solution instead of its coordinates. Section 13 of the probe hunts for one — identical, concentric, externally tangent, internally tangent and crossing circles, a point on the circle, a point at the centre — and none of them, nor any zero-radius case, produces one. Left alone rather than fixed speculatively.

The nine 2D conic sites that took a dimension and never checked it (#514)

Split out of #487, which fixed the three gce_Make*2d factories and converged the four conic dimension predicates onto one definition. The rest of the 2D family builds a conic from caller-supplied dimensions at nine more places, and none of them checked. All nine now use the same shared predicates: occtValidCircleRadius, occtValidEllipseRadii, occtValidHyperbolaRadii, occtValidParabolaFocal.

The gap was the zero boundary specifically, not “no precondition at all”. The issue’s premise was that gp_Elips2d’s own Standard_ConstructionError_Raise_if is compiled out. That is true of a call made from inside OCCT, where No_Exception is defined, and it is what #487 measured for gce_MakeElips2d. These nine sites construct the gp_*2d themselves, in a bridge translation unit, where the constructor is constexpr in the header and the check does run: gp_Elips2d(ax, 5, -3), (3, 5) and gp_Parab2d(ax, -2) all raise today and are already caught. What the check never covered is zero, which every downstream algorithm then accepts:

Conic2D gains a way to say the conic does not exist. All-zero coefficients cannot carry it: the equation 0 = 0 holds at every point of the plane, so they read as a conic, and they were also what the catch block already wrote. The three bridge functions return bool; in Swift there are three new factories that return Conic2D?:

// new
if let e = Conic2D.ellipse(center: .zero, direction: SIMD2(1, 0),
                           majorRadius: 5, minorRadius: 3) { … }

// old spelling, still compiles, now deprecated
let e = Conic2D.fromEllipse(center: .zero, direction: SIMD2(1, 0),
                            majorRadius: 5, minorRadius: 3)

fromCircle / fromLine / fromEllipse are @available(*, deprecated, renamed:) and forward, returning the all-zero struct where the new spelling returns nil. Not a breaking change: no existing call site has to move, and no signature changed.

Conic2D’s documented equation was wrong. It named a·x² + b·x·y + c·y² + d·x + e·y + f = 0; OCCT’s IntAna2d_Conic::Coefficients returns a·x² + b·y² + 2c·x·y + 2d·x + 2e·y + f = 0, so b is the y² term and c the cross term, and the cross and linear terms carry a factor of 2. A caller who built a conic from the documented order got a different curve. The values themselves never changed; a regression test now pins the order against a radius-5 circle (1, 1, 0, 0, 0, -25).

Scope: the three circle siblings sitting in the same three code blocks (OCCTMakeEdge2dFullCircle, OCCTConvertCircleToBSpline2D, OCCTConic2dFromCircle) are included, along with OCCTConic2dLineCircleIntersect, which shares the same gp_Circ2d construction and would otherwise have been the one entry point in its own block still accepting radius 0. The ~25 remaining 2D circle sites are Geom2dGcc tangency-solver inputs, a different question, filed separately. The 3D equivalents are unsurveyed, as #514 noted.

18 tests in Tests/OCCTGeom2dTests/Issue514Conic2dDegenerateTests.swift. They were run against a build with every guard stripped back out: the 10 rejection tests fail, and the 8 that pin valid input (including “a hyperbola may have minor > major” and the coefficient order) still pass.

The 3D conic sites that took a dimension and never checked it (#554)

The 3D counterparts of #514, which surveyed only the 2D side. Twenty-two sites across OCCTBridge_Curve3D.mm and OCCTBridge_Modeling.mm build a 3D conic from a caller-supplied dimension, or rewrite one on a live curve, and none of them checked it. All twenty-two now use the same four shared predicates: 11 ellipse, 6 hyperbola, 4 parabola, 1 circle. #399’s earlier pass covered the Curve3D factories only.

The census is wider than the issue’s nine gp_Elips sites, because three separate families have the same gap by three different mechanisms, and OCCT’s own checks survive this build to three different degrees:

That third row refines #487’s rule rather than restating it: No_Exception voids the macro, not every OCCT precondition. Geom_Ellipse::SetMajorRadius throws from inside OCCT’s own translation unit because the check is spelled by hand.

Zero satisfies every check any of the three writes (minor < 0 || major < minor is false for (0, 0)), which is why it is the one degenerate input that arrived intact by every route.

The sharpest case is GC_MakeArcOfEllipse’s two-point form, where IsDone() is not merely insufficient but actively misleading. That form inverts each endpoint back to a parameter, which divides by the minor radius; at zero both bounds come back NaN and the maker still reports success. The if (!maker.IsDone()) return nullptr line the bridge relied on therefore passed, and Curve3D.arcOfEllipse(…, from:to:) returned a live curve whose parameter range was [nan, nan] and whose every evaluation was NaN. Measured against the pinned kernel, with the identical call on a healthy (5, 3) ellipse as the control:

Every site was placed by asking #553’s question, not by which OCCT class it calls. #553 settled whether a degenerate conic can be a meaningful query rather than a broken construction, and answered it by probing whether OCCT actually returns the degenerate answer. Applied here the same question splits this family in two, and the split does not follow the “pure query” line it looks like it should:

• The three Extrema entry points are guarded, because OCCT does not answer the degenerate question: Extrema_ExtPElC reports NbExt() == 0 against a (0, 0) ellipse rather than the one extremum at its centre, and Extrema_ExtElC reports IsParallel() regardless of what the line does. Same failure shape #553 measured across the Gcc families, and the same conclusion.
• BndLib and ElCLib are excluded, because they do answer it. ElCLib::Value(1.0, gp_Elips(ax, 5, 0)) is (2.70151, 0, 0), a point on the collapsed segment, which is exactly what that curve is; BndLib::Add returns the true box of it. Both are also void with nowhere to report a rejection, so guarding them would mean widening a signature in order to refuse an input OCCT handles correctly.

The second bullet is the one worth stating explicitly, because “it is only a query” is not the reason — #553 has already shown that a query can be exactly where the wrong answer hides.

Also excluded, and pinned by a test so the exclusion stays deliberate: the four GC_Make* three-point forms. They take no dimension at all, and OCCT’s own status already rejects a degenerate point triple (measured: coincident points, and an S2 lying on the major axis, both report !IsDone()).

No API signature changed, and nothing that used to succeed on valid input now fails. Every affected entry point already had somewhere to say no: nil for the 13 factory and edge builders, false for the 6 setters, and the existing -1 error return for the 3 Extrema functions, which the Swift layer already maps to [].

26 tests in Tests/OCCTCurveTests/Issue554Conic3dDegenerateTests.swift. They were run against a build with every guard stripped back out: 19 fail, and the 7 that pass are exactly the controls — valid input still accepted, the negative and inverted cases OCCT already rejected, the three-point forms, the ellipse major setter that Geom_Ellipse’s own throw already covered, and the BndLib/ElCLib exclusion.

The null-handle guard, swept across the whole geometry-wrapper surface (#478)

#416 added the missing IsNull() guard to OCCTCurve3DTransform and #488 to OCCTSurfaceTransform; #478 asked whether the same shape existed elsewhere rather than fixing a third site alone. It did, in 14 bridge functions, found by walking every function that takes an OCCTCurve3DRef / OCCTCurve2DRef / OCCTSurfaceRef and dereferences the handle it carries:

Each checked the wrapper pointer and then dereferenced the Handle inside it. Their own siblings, in the same files, check both. OCCTCurve3DStartPoint and OCCTCurve3DEndPoint had no guard at all, not even the wrapper. All 14 now open with if (!x || x->handle.IsNull()). These are uncatchable: the enclosing catch (...) cannot intercept a signal, and the kernel’s own Standard_NullObject preconditions are compiled out of this No_Exception build.

Still latent, and now measured rather than assumed. All 228 sites that bind a handle into an OCCTCurve3D / OCCTCurve2D / OCCTSurface wrapper were classified:

The last five are GeomConvert_BSplineCurveToBezierCurve::Arc (twice), GeomConvert_CompCurveToBSplineCurve::BSplineCurve, Geom2dConvert_ApproxArcsSegments::GetResult and Geom_TrimmedCurve::BasisCurve: each is constructed from a handle the caller checked, so none can return null there, but that rests on the class’s contract rather than a check at the site. No bridge call hands back a wrapper carrying a null handle, so nothing here closes a reachable crash. The cost asymmetry is the argument: one condition against a SIGSEGV.

The sweep also found a second, larger class it does not fix: 49 functions guard the wrapper and then pass the unchecked handle to an OCCT API that dereferences it internally, 28 of them without even the wrapper check (Geom2dAdaptor_Curve adaptor(c->curve), new Geom_TrimmedCurve(basis->curve, ...), and so on). Same crash, one hop further out, equally latent. Filed separately rather than folded in here.

Curve2D’s two transform families now share one buildTrsf2D, which is why its dispatcher had drifted in the first place. It was the last of the three geometry types still duplicating the construction, after Curve3D (#416) and Surface (#488). The five immutable functions (OCCTCurve2DTranslate, Rotate, Scale, MirrorAxis, MirrorPoint) reached it through Geom2d_Geometry’s per-operation convenience methods while the in-place OCCTCurve2DTransform built its own gp_Trsf2d, composing the scale case by hand as SetScaleFactor(S) + SetTranslationPart(C * (1 - S)) where the other family used gp_Trsf2d::SetScale(C, S). Verified equivalent before switching, over factors {2.5, 0.25, 1, -1, -3, 0, 1e-9, 1e9} against three centres including (1e6, 1e-6): identical scale factor, identical translation part, identical transformed coordinates, to the bit. They disagree only on the internal gp_TrsfForm tag at S = 1 and S = -1, which is a dispatch hint, not a result.

Two new suites in Tests/OCCTGeom2dTests, because one is not enough. Issue478Curve2DTransform ParityTests holds the two families together across all five kinds, on a segment and on a Bezier. Issue478Curve2DTransformGeometryTests checks each transform against coordinates computed in Swift, with no bridge call in the expectation. Both were run against injected defects: a one-family drift fails the parity suite, while a defect inside the shared buildTrsf2D moves both families identically and leaves the parity suite entirely green, failing only the geometry suite. A parity assertion stops being evidence the moment the thing it compares becomes shared.

The other half of the null-handle sweep, and a checker so it stays swept (#556)

#478 fixed the 14 bridge functions that guard the wrapper pointer and then dereference the Handle it carries. #556 is the class it deliberately left behind: functions that guard the wrapper and then pass the unchecked handle to an OCCT API which dereferences it internally.

60 functions, 73 (function, argument) pairs, all now opening with if (!x || x->handle.IsNull()):

The issue counted 49 functions across 5 files; the same walk, run again, finds 61 across 6.

The issue’s headline example is a false positive, twice over. #556 opens with makeQualifiedCurve (Geom2dAdaptor_Curve adaptor(c->curve), “no guard at all”), and argues from Geom2dAdaptor_Curve.cxx:272 that load “has no null precondition at all […] it is an unconditional dereference in every build configuration”. Lowercase load is private. Every caller reaches it through the public Load, header-inline at Geom2dAdaptor_Curve.hxx:108, which opens with a bare if (theCurve.IsNull()) throw Standard_NullObject();, not macro-guarded, so unlike the kernel’s precompiled .cxx preconditions it is not compiled out by No_Exception, which only ever applied to the Release kernel build and never to bridge translation units. And all 12 of makeQualifiedCurve’s call sites, across 7 functions, already reject both the null pointer and the null handle before calling it. It is the one site in the whole sweep left unguarded, now with a comment saying why: its return type (Geom2dGcc_QualifiedCurve, by value) has no null-safe fallback, so the precondition has to live in the callers.

The class is worse than “latent” elsewhere, though. Scripts/repro/556-null-handle-guard-sweep/ drives a null handle into all 35 distinct OCCT entry points these 60 functions call, each in a forked child: 24 crash with an uncatchable signal, 5 raise a catchable Standard_Failure, 6 return normally. Geom2dAdaptor_Curve is in the mild group. new Geom_TrimmedCurve, new Geom_OffsetCurve, new Geom_RectangularTrimmedSurface, ShapeAnalysis_Curve::IsPeriodic, BRepLib_MakeEdge2d, GeomConvert::CurveToBSplineCurve, BRepAlgoAPI_Section and ShapeConstruct_Curve::ConvertToBSpline are not. ShapeAnalysis_Surface is the one to remember: constructing it from a null handle returns normally and the crash lands at the first ValueOfUV, so a probe that only constructed it would have cleared that entire 11-function family.

Three findings the issue’s own reproduction recipe could not reach, because it walks scalar parameters only:

• OCCTCurve2DPointAt is a dereference site (curve->curve->D0(t, pt), with no guard at all) that #478’s sweep missed outright. Fixed here rather than left for a third pass.
• Five functions take an array of wrappers. OCCTGeomFillGordon and OCCTGeomFillGordonReport checked !profiles[i] and passed the handle unchecked; OCCTConcatenateCurves3D, OCCTConcatenateCurves2D and OCCTCurve3DJoinCurves checked curves[i] inside the loop but never curves[0], the element every one of them handles separately to seed the accumulator.
• OCCTBridge_ProjLib_NLPlate.mm was not in the issue’s file list at all.