Remove abort on infinite loop during library close

[mattjala]

When the library detects that it cannot make progress closing itself (an "infinite loop closing library"), it now aborts regardless of whether automatic error message display has been enabled via H5Eset_auto2(). Previously the abort was skipped whenever error output was turned off, so an application that had disabled error reporting would continue running in this unrecoverable state instead of terminating.

Fixes #6531

[github-actions]

Review Checklist

This PR touches the following areas. Each needs a sign-off
from its listed owners before merging.

• src ✅ — @jhendersonHDF
• release_docs ✅ — @lrknox

✅ All areas have been signed off.

[Copilot]

Pull request overview

This PR adjusts HDF5 library shutdown behavior so that when an “infinite loop closing library” condition is detected, the abort path is no longer suppressed merely because automatic error output was disabled via H5Eset_auto2().

Changes:

• Move the abort() call outside the if (func) block so it no longer depends on error auto-display being enabled (still under #ifndef NDEBUG).
• Document the behavior change in release_docs/CHANGELOG.md.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/H5.c	Ensures the abort path is not contingent on whether automatic error printing is enabled.
release_docs/CHANGELOG.md	Adds a changelog entry describing the updated shutdown/abort behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jhendersonHDF]

Introduced in 339a81a, but no particular rationale given. I assume the intention is that if the user asked to disable error reporting, then they don't want any error handling path like this to be triggered. The library is still going to terminate either way, so I don't think skipping the abort() carries any danger whatsoever. It's also arguably rude for a library to ever call abort(), even if it's during library termination, since it doesn't give any chance for cleanup and can have any number of effects on downstream code.

I noticed the comments afterward and agree with at least the ones regarding the release note.

[lrknox]

CHANGELOG.md has 2.2.0 release note entries that have been removed in develop; they should also be removed here. Removing abort has been discussed, was removing it settled?

[mattjala]

CHANGELOG.md has 2.2.0 release note entries that have been removed in develop; they should also be removed here. Removing abort has been discussed, was removing it settled?

Yes, we decided that removing the abort makes the most sense.