Skip to content

[6.2] Fix a few issues around nonisolated(nonsending) and protocol witness thunks/vtable thunks #81615

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: release/6.2
Choose a base branch
from

Conversation

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented May 19, 2025

Explanation: This PR does three things:

  1. I discovered that we were not validating in the SILVerifier that protocol witness table witnesses were ABI compatible with the requirements. I added that verification. It also showed we had some stale SIL tests that were very old that just were updated incorrectly and thus tripped this verification. I fixed those. This will only come into play when we test release/6.2 with asserts. It will not impact non-release builds.

  2. I changed SILGen to place the correct ActorIsolation on protocol witness thunks. We were using the isolation from the witness, not the requirement. Before this change as a result of placing the wrong isolation in SILFunctionType, we were not inserting the extra implicit isolated parameter on the thunk causing ABI breakage.

  3. While doing this, I also discovered that we were not properly pushing/popping the implicit isolated parameter when producing vtable thunks.

Scope: This modifies how we generate SIL for protocol witness/vtable thunks when nonisolated(nonsending) is involved.

Resolves: rdar://151394209

Main PR: #81542

Risk: Low. This should only impact code that uses nonisolated(nonsending).

Testing: Added compiler tests

Reviewer: @rjmccall

gottesmm added 8 commits May 19, 2025 10:33
Just to make review easier.

(cherry picked from commit 71adae4)
…nabled instead of #ifndef NDEBUG to match the rest of the SILVerifier.

I think this was just an oversight. There is really no reason that this should
not match the rest of the SILVerifier w here we have moved from using #ifndef
NDEBUG to verificationEnabled checking.

(cherry picked from commit e25c664)
I just renamed a few variables and eliminated a bunch of unnecessary
indentation.

Just to make it easier to review the actual functional change.

(cherry picked from commit 634435d)
This will cause tests today to crash since even though we are placing the
isolation now, to make it easier to read, I left in the old isolation selecting
code. This code uses the witness's isolation instead of the requirement's
isolation which is incorrect since the protocol witness thunk needs to look the
requirement from an ABI perspective since the two must be substitutable. The
crash comes from the ABI verification I added in earlier commits.

(cherry picked from commit ff1cbea)
We were using the isolation from the witness not from the requirement which we
are supposed to do. The witness thunk thunks the isolation from the requirement
to the witness so from an ABI perspective it should have the interface implied
by the requirement's isolation since that is what callers of the witness method
will expect.

rdar://151394209
(cherry picked from commit 39a013f)
…for vtables

This ensures that when we generate the vtable thunk for a
nonisolated(nonsending) override (or vis-a-versa), we get the ABI correct. I
also added tests for all of the relevant cases for vtables that we check for
protocols.

rdar://151394209
(cherry picked from commit ef23f97)
@gottesmm gottesmm requested a review from a team as a code owner May 19, 2025 17:36
@gottesmm
Copy link
Contributor Author

@swift-ci test

@gottesmm gottesmm marked this pull request as draft May 19, 2025 17:52
@gottesmm
Copy link
Contributor Author

@swift-ci test windows platform

@gottesmm gottesmm marked this pull request as ready for review May 19, 2025 19:21
@gottesmm
Copy link
Contributor Author

@swift-ci test macOS platform

@gottesmm gottesmm enabled auto-merge May 20, 2025 18:54
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