Skip to content

[5.10] ModuleInterface: prepare to accept access-level on imports in swiftinterfaces #68587

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 4 commits into from
Sep 19, 2023

Conversation

xymus
Copy link
Contributor

@xymus xymus commented Sep 18, 2023

This adds forward looking support for swiftinterfaces and the Access-levels on import features. Ensure the compiler accepts future swiftinterfaces using access-level keywords on imports without the flag. And print the public access-level keyword in Swift 6 mode.

While use of access-level in imports is still gated by a flag for normal
source code, accept it in swiftinterfaces without the flag. This will
make it easier for older compilers to read newer swiftinterfaces created
by a future compiler where that restriction is lifted.

rdar://115455383
If the access-level on imports proposal is accepted as written, all
imports printed in swiftinterfaces will be `public`. Whether or not we
require the explicit `public` keyword in Swift 6 mode, printing it will
have no downside. It also goes along with the mentality that
swiftinterfaces should be more explicit than implicit.

rdar://115455383
@xymus xymus added the 🍒 release cherry pick Flag: Release branch cherry picks label Sep 18, 2023
@xymus xymus requested a review from tshortli September 18, 2023 16:48
@xymus xymus requested a review from a team as a code owner September 18, 2023 16:48
@xymus
Copy link
Contributor Author

xymus commented Sep 18, 2023

@swift-ci Please test

@@ -5,6 +5,10 @@
// RUN: %target-swift-typecheck-module-from-interface(%t.swiftinterface) -I %S/Inputs/imports-clang-modules/ -I %t
// RUN: %FileCheck -implicit-check-not BAD %s < %t.swiftinterface

/// Swift 6 variant.
// RUN: %target-swift-emit-module-interface(%t.swiftinterface) %s %S/Inputs/imports-other.swift -disable-implicit-concurrency-module-import -disable-implicit-string-processing-module-import -I %S/Inputs/imports-clang-modules/ -I %t -verify -swift-version 6
Copy link
Contributor

Choose a reason for hiding this comment

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

This will fail in a non-asserts toolchain, because -swift-version 6 is only supported in the asserts toolchain (like the ones used for testing by default).

See https://github.com/apple/swift/blob/main/test/Driver/swift-version-6-asserts.swift and https://github.com/apple/swift/blob/main/test/Driver/swift-version-6-noasserts.swift for examples of how -swift-version 6 has been tested before. Other tests added REQUIRES: asserts, but that will make the full test not run in noasserts toolchains.

(Introduced in #68523 but commenting here so it doesn't propagate to another branch).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for pointing it out. The fix is up #68591.

This allows us to limit the test to asserts compiler supporting
-swift-version 6.

rdar://115578753
@xymus
Copy link
Contributor Author

xymus commented Sep 19, 2023

@swift-ci Please test

@xymus xymus merged commit 34322fc into swiftlang:release/5.10 Sep 19, 2023
@xymus xymus deleted the print-public-5.10 branch September 19, 2023 22:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🍒 release cherry pick Flag: Release branch cherry picks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants