-
Notifications
You must be signed in to change notification settings - Fork 10.5k
🍒 [5.5] Add Initializers' AFPs #40750
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, a LinkEntity for an AST async function pointer was built by passing an AbstractFunctionDecl. Later, decl was used to construct a SILDeclRef. That arrangement meant that clients could not construct such a LinkEntity whose SILDeclRef::Kind could not be inferred from the dynamic type of the decl from which the SILDeclRef was constructed. In particular, clients could not construct a LinkEntity for the initializer corresponding to a ConstructorDecl. Here, the arrangment is changed so that the LinkEntity for an AST async function pointer is built by passing a SILDeclRef.
Previously, adding a symbol for an async function pointer to the TBD entailed passing an AbstractFunctionDecl to TBDGenVisitor::addAsyncFunctionPointerSymbol. That arrangment limited clients from specifying a different SILDeclRef::Kind than the one which could be inferred from the type of the decl which was passed to the visitor's function. In particular, it prevented clients from specifying that the symbol for an initializer corresponding to a ConstructorDecl should be added to the TBD. Here, the arrangement is changed so that the visitor's function takes a SILDeclRef.
Previously, the async function pointers for initializers were omitted from TBD files. That resulted in a mismatch between the symbols exported from the IR module and those listed in the TBDS. Here, that is corrected. As with regular function pointers, the symbols for the async function pointers for initializers need to be manually added just as the symbols for initializers themselves need to be manually added. rdar://82045176
@swift-ci please test |
@swift-ci please build toolchain |
Linux Toolchain (Ubuntu 16.04) Install command |
@swift-ci please nominate |
macOS Toolchain Install command |
tbkka
approved these changes
Jan 6, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description: Previously, the AFPs for initializers were omitted from TBDs. That resulted in a mismatch between the symbols exported from the IR module and the symbols listed in the TBD file. Here that is fixed by adding those symbols to the TBD file. -- This also causes Swift to crash on Linux builds where these assertions are enabled in toolchain builds, causing issues to our Linux adopters.
Risk: Low
Review by: @DougGregor @nate-chandler
Testing: verified manually on reproducer project provided in SR-15659 (reproduced on 5.5.2, and confirmed Swift with this fix (main) does not exhibit the issue)
Original PR: #38918 by @nate-chandler
Radar: https://bugs.swift.org/browse/SR-15659 rdar://86945821 and rdar://82045176