Skip to content

Conversation

susmonteiro
Copy link
Contributor

In some cases, the use of SWIFT_NONCOPYABLE was being overlooked.
Also, if this attribute is present, there's no need to evaluate the conditional parameters. We currently accept that the user adds both SWIFT_NONCOPYABLE and SWIFT_COPYABLE_IF attributes to the same record, but if the first is present, we don't need to evaluate the second one.

@susmonteiro
Copy link
Contributor Author

@swift-ci please smoke test

@susmonteiro susmonteiro force-pushed the susmonteiro/noncopyable-attr branch from 0c9e28f to a1fe79a Compare September 25, 2025 14:43
@susmonteiro
Copy link
Contributor Author

@swift-ci please smoke test

#endif

template<typename T>
struct SWIFT_COPYABLE_IF(T) SWIFT_NONCOPYABLE DoubleAnnotation {};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to diagnose this? Or do we expect users to find themselves in a situation where this is useful?
Also could you add a test that checks that SWIFT_COPYABLE_IF(garbage) SWIFT_NONCOPYABLE DoubleAnnotation still diagnoses the invalid attribute?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will be useful, but it's also not problematic that the user adds both. If we diagnose this, we should also diagnose the case where there's two or more SWIFT_COPYABLE_IF annotations in the same type (we currently merge all the parameters of these annotation) or when the user adds two or more SWIFT_NONCOPYABLE.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the test you suggested, in the current implementation if there's a SWIFT_NONCOPYABLE we never even look at SWIFT_COPYABLE_IF, so we wouldn't diagnose the invalid attribute. I'm positive the same happens with escapable annotations: if a SWIFT_ESCAPABLE or SWIFT_NONESCAPABLE is present, we never parse the SWIFT_ESCAPABLE_IF

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should diagnose swift attributes that are obviously not used as intended.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! I opened an issue: #84559

@susmonteiro susmonteiro force-pushed the susmonteiro/noncopyable-attr branch from a1fe79a to 8bf955f Compare September 26, 2025 10:56
@susmonteiro
Copy link
Contributor Author

@swift-ci please smoke test

@susmonteiro
Copy link
Contributor Author

@swift-ci please smoke test macos

@susmonteiro susmonteiro force-pushed the susmonteiro/noncopyable-attr branch from 8bf955f to cf7d394 Compare September 29, 2025 08:54
@susmonteiro
Copy link
Contributor Author

@swift-ci please smoke test

@susmonteiro susmonteiro force-pushed the susmonteiro/noncopyable-attr branch from cf7d394 to 59f09c7 Compare September 29, 2025 11:57
@susmonteiro
Copy link
Contributor Author

@swift-ci please smoke test

@susmonteiro susmonteiro force-pushed the susmonteiro/noncopyable-attr branch from 59f09c7 to 7e14a8e Compare September 30, 2025 08:29
@susmonteiro
Copy link
Contributor Author

@swift-ci please smoke test

@susmonteiro susmonteiro merged commit e54752a into swiftlang:main Sep 30, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ interop Feature: Interoperability with C++
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants