mirror of
https://github.com/apple/swift.git
synced 2025-12-14 20:36:38 +01:00
b3493bfa23
NFC *except* that I noticed a bug by inspection where we suppress `@escaping` when print enum element types. Since this affects recursive positions, we end up suppressing `@escaping` in places we shouldn't. This is unlikely to affect much real code, but should still obviously be fixed. The new design is a little sketchy in that we're using `const` to prevent direct use (and allow initialization of `const &` parameters) but still relying on modification of the actual object. Essentially, we are treating the `const`-ness of the reference as a promise to leave the original value in the object after computation rather than a guarantee of not modifying the object. This is okay --- a temporary bound to a `const` reference is still a non-`const` object formally and can be modified without invoking UB --- but makes me a little uncomfortable.
17 lines
648 B
Swift
17 lines
648 B
Swift
// RUN: %empty-directory(%t)
|
|
// RUN: %target-swift-emit-module-interface(%t.swiftinterface) %s -module-name Test
|
|
// RUN: %FileCheck %s < %t.swiftinterface
|
|
// RUN: %target-swift-typecheck-module-from-interface(%t.swiftinterface) -module-name Test
|
|
|
|
// This test fails if we suppress the @escaping attribute recursively
|
|
// when printing enum element parameter lists instead of only suppressing
|
|
// it when printing the immediate type of the enum payload.
|
|
|
|
public enum A {
|
|
case function(_: (@escaping () -> Void) -> Void)
|
|
}
|
|
|
|
// CHECK-LABEL: public enum A {
|
|
// CHECK-NEXT: case function((@escaping () -> Swift.Void) -> Swift.Void)
|
|
// CHECK-NEXT: }
|