-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Add an implicit dependency on the '_SwiftConcurrencyShims' library #62883
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
Conversation
@swift-ci smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The concurrency shims have to exist if the concurrency module does because it uses the shims, but I'm also totally fine with explicit behavior over implicit assumptions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
d8b8015
to
10ac586
Compare
@swift-ci smoke test and merge |
@swift-ci smoke test Linux Platform |
10ac586
to
2d54f90
Compare
@swift-ci test |
@@ -92,7 +92,7 @@ func f4(_ j: Wibble) { } // expected-error{{cannot find type 'Wibble' in scope}} | |||
f4(5) | |||
|
|||
func f1() { | |||
var c : Class // expected-error{{cannot find type 'Class' in scope}} | |||
var c : Klass // expected-error{{cannot find type 'Klass' in scope}} | |||
markUsed(c.x) // make sure error does not cascade here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent of the test here is to avoid propagating the original error. Once this additional Clang module is brought in, the name Class
somehow conflicts with name-resolution logic as affected by the newly-added implicit Clang module dependency. Renaming this variable allows us to keep testing the original thing and not worry about it being affected by brought-in clang declarations...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me!
@@ -1,4 +1,4 @@ | |||
// RUN: %empty-directory(%t.mod) | |||
// RUN: %swift -emit-module -o %t.mod/cake1.swiftmodule %S/Inputs/cake1.swift -disable-implicit-string-processing-module-import -parse-as-library | |||
// RUN: %swift -emit-module -o %t.mod/cake1.swiftmodule %S/Inputs/cake1.swift -disable-implicit-string-processing-module-import -disable-implicit-concurrency-module-import -parse-as-library |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These tests were subtly affected by the presence of the new module as well, so I just disabled overall implicit concurrency loading and modified the expected outputs accordingly. The tests are still exercising/verifying the functionality they were before.
3 similar comments
Whenever concurrency mode is enabled in compilation. This avoids instead ad-hoc requests to load this module in SILGen.
2d54f90
to
c5e1b6b
Compare
@swift-ci test |
@swift-ci test macOS platform |
swiftlang/swift-driver#1264 |
Whenever concurrency mode is enabled in compilation