Make Xcode 26.6 happy. Move HMW destructor to .cpp

[Opt-Mucca]

Description

Moves HighsMipWorker destructor from HighsMipWorker.h to HighsMipWorker.cpp. Destroying the std::unique_pointer to HighsSearch apparently needs more than a forward declaration for Xcode 26.6.

Checklist

• I have read the contributing guidelines
• This PR targets the latest branch
• Tests are passing
• Documentation was updated where relevant
• This PR is not primarily AI-generated (per the AI contributions policy in CONTRIBUTING.md)

Closes #3227

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.20%. Comparing base (819a538) to head (a555cb6).
⚠️ Report is 25 commits behind head on latest.

Additional details and impacted files

@@            Coverage Diff             @@
##           latest    #3228      +/-   ##
==========================================
- Coverage   73.22%   73.20%   -0.02%     
==========================================
  Files         445      445              
  Lines      107826   107878      +52     
  Branches    17262    17277      +15     
==========================================
+ Hits        78951    78968      +17     
- Misses      28599    28634      +35     
  Partials      276      276              

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

🚀 New features to boost your workflow:

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

[filikat]

Great!
This was undefined behaviour before. From https://en.cppreference.com/cpp/memory/unique_ptr: "unique_ptr may be constructed for an incomplete type T[...]. If the default deleter is used, T must be complete at the point in code where the deleter is invoked, which happens in the [...] reset member function of unique_ptr."

[Opt-Mucca]

@mathgeekcoder If I'm understanding the failing test correctly, then I think HiGHS is solving the instance too quickly and the isRunning check is against an already solved instance?

[mathgeekcoder]

@mathgeekcoder If I'm understanding the failing test correctly, then I think HiGHS is solving the instance too quickly and the isRunning check is against an already solved instance?

Yeah, unfortunately I believe that's the case. Honestly, it's a bit of a hacky test (not my proudest work). We can either hack it (by increasing N to make the problem harder) or add forced delay via a callback handler (e.g., simplexInterrupt).

e.g., something like

def test_solver_running_state(self):
    # build model as before (removed for brevity)

    entered = threading.Event()   # solver thread reached the callback
    release = threading.Event()   # test tells solver it may continue

    def hold(e, data):
        entered.set()
        release.wait(timeout=30)  # bounded delay, don't hang CI

    h.HandleUserInterrupt = True
    h.cbSimplexInterrupt.subscribe(hold)

    h.startSolve()
    self.assertTrue(entered.wait(timeout=30), "solver never reached callback")
    self.assertTrue(h.is_solver_running())     # solver is still inside hold()
    release.set()                              # solver can exit hold()

    h.cancelSolve()
    h.wait()

[Opt-Mucca]

@mathgeekcoder I'm happy with that suggested change! I like it more than just increasing N. Should I stuff it into this PR or do you create a separate one?

[mathgeekcoder]

@mathgeekcoder I'm happy with that suggested change! I like it more than just increasing N. Should I stuff it into this PR or do you create a separate one?

Wonderful. I'm happy either way! Though, earliest I can get to this will be next week. If you choose to add it here, I can likely help review before then.

[Opt-Mucca]

@mathgeekcoder we do a separate PR. No stress on the timing. I'm still not 100% confident on doing anything more than copying the suggestion for now (need to take the time to get more invested in highspy at some point......)