Support OCCT 8.x #237

Summary

OCCT 8.x released in May-July 2026 and is available on conda-forge for linux-64, linux-aarch64, linux-ppc64le, osx-64, osx-arm64 and win-64.

Current blockers:

1. crates/opencascade-sys/build.rs pins const OCCT_VERSION: (u8, u8) = (7, 8); and panics unless version_major == 7 && version_minor >= 8.
2. Types removed from OCCT 8.0: Handle_Geom_Surface, Handle_Poly_Triangulation, …

What changed in OCCT 8.0 (provisional list)

• Handles. In 7.8.1 every class header ends with DEFINE_STANDARD_HANDLE(Geom_Surface, Geom_Geometry), which on MSVC defines Handle_Geom_Surface as a derived class (the C++/CLI export hack) and as a typedef elsewhere. In V8_0_1, OCCT's own API spells handles occ::handle<T>, and Standard_Handle.hxx defines namespace occ { using handle = opencascade::handle<T>; }. The macro is marked deprecated.
• Constants. Standard_Boolean, Standard_True, Standard_False are deprecated but still defined.
• Language level. C++17 is the minimum (CMakeLists.txt), with 20/23/26 selectable.

Why this also matters for the MSVC bug (#234)

#234 fixes 7.8 by constructing the owned type (new Handle_X(…)) and wrapping the cxx pointer bindings. That is correct for 7.8, but needs gating for 8.0, where Handle_X does not exist.

The durable spelling for the bridge is opencascade::handle<T> (equivalently Handle(T), still defined in 8.0 as #define Handle(Class) opencascade::handle<Class>):

• it is the same type on GCC/Clang as Handle_X in 7.8, so nothing changes there;
• on MSVC it is not the derived class, so the unique_ptr ownership and the cxx member-pointer shims both type-check (which is the whole of Fix Windows/MSVC build: Handle_X is a distinct class under MSVC #234's classes A and B);
• in 8.0 it is exactly what OCCT's headers use (occ::handle is an alias of it).

So one migration (bridge type declarations and wrapper signatures from Handle_X to opencascade::handle<T>) gives 7.8 and 8.0 support and removes the need for #234's approach for newer OCCT. OCCT's own class names are still needed as type X; declarations on the Rust side.

What's needed for 8.x support beyond the handle

• The version gate: either accept both majors with a compile-time probe of Standard_Version.hxx (the build script already parses VERSION_MAJOR/VERSION_MINOR from CMake), or gate per major behind a feature. A single supporting branch looks feasible, but I need to verify what 8.0 API removes beyond the handles.
• occt-sys's pinned OCCT submodule for the builtin feature would need an 8.x option (the 7.8 panic message already points at it).
• Whatever else 8.0 needs/added/changed

Use case

FerroCAD (a FreeCAD-compatible CAD app) runs opencascade-sys against a conda OCCT prefix on ubuntu-latest and windows-latest, with --check-init boot tests and packaging, and is currently carrying a vendored copy of 0.3.0 + #234 to ship a Windows build.

If it helps, I can run an occt=8.0.1 leg (Linux and/or Windows) against a branch and report what fails, that would create a TODO list for migration.

Also needs a decision: dual-version support in one branch/crate ersion, or a dedicated/parallel 8.x-compatible release.