Skip to content

Comments

Explicitly delete copy constructors for classes with Poco::NObserver#40958

Draft
rboston628 wants to merge 5 commits intomainfrom
patch-delete-copy-constructor-nobserver
Draft

Explicitly delete copy constructors for classes with Poco::NObserver#40958
rboston628 wants to merge 5 commits intomainfrom
patch-delete-copy-constructor-nobserver

Conversation

@rboston628
Copy link
Contributor

Description of work

Poco v1.15 (published to anaconda.org on 2026-02-17) introduces std::atomic into NObserver, which secretly prevents copying of any class with an NObserver object in it. You can only find this out when you go to build on Windows with MSVC and learn it is trying to create a default copy constructor, leading to an error.

This was discovered while making release candidates for mantid v6.15. As pin as added in 6.15 to enable the package build in PR #40957.

The problem is caused in classes with a NObserver member variable, but without an explicit copy constructor. The MSVC compiler will attempt to create defaults, which is an error. This work deletes the copy constructors in these classes, so that the defaults will not be constructed.

To test:

Run a build with a pin in Poco 1.15.


Reviewer

Your comments will be used as part of the gatekeeper process. Comment clearly on what you have checked and tested during your review. Provide an audit trail for any changes requested.

As per the review guidelines:

  • Is the code of an acceptable quality? (Code standards/GUI standards)
  • Has a thorough functional test been performed? Do the changes handle unexpected input/situations?
  • Are appropriately scoped unit and/or system tests provided?
  • Do the release notes conform to the guidelines and describe the changes appropriately?
  • Has the relevant (user and developer) documentation been added/updated?
  • If the PR author isn’t in the mantid-developers or mantid-contributors teams, add a review comment rerun ci to authorize/rerun the CI

Gatekeeper

As per the gatekeeping guidelines:

  • Has a thorough first line review been conducted, including functional testing?
  • At a high-level, is the code quality sufficient?
  • Are the base, milestone and labels correct?

@rboston628 rboston628 added this to the Release 6.16 milestone Feb 19, 2026
@github-actions github-actions bot added the Has Conflicts Used by the bot to label pull requests that have conflicts label Feb 19, 2026
@github-actions
Copy link
Contributor

👋 Hi, @rboston628,

Conflicts have been detected against the base branch. Please rebase your branch against the base branch.

@github-actions github-actions bot removed the Has Conflicts Used by the bot to label pull requests that have conflicts label Feb 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant