profile
viewpoint

apple/cups 1183

Official CUPS Sources

apple/swift-crypto 962

Open-source implementation of a substantial portion of the API of Apple CryptoKit suitable for use on Linux platforms.

kylebrowning/APNSwift 368

An HTTP/2 APNS library built on swift-nio

swift-server/swift-backtrace 197

💥 Backtraces for Swift on Linux

LLK/scratch-render 191

WebGL-based rendering engine for Scratch 3.0

apple/swift-nio-ssh 160

SwiftNIO SSH is a programmatic implementation of SSH using SwiftNIO

MrLotU/SwiftPrometheus 51

Client side Prometheus library in Swift

Mordil/RediStack 45

Non-blocking, event-driven Swift client for Redis.

LLK/s2forums 16

This is a fork of DjangoBB customized for Scratch 2.0. DjangoBB is a quick and simple forum which uses the Django Framework (written in Python language). Abbreviation DjangoBB stands for Django Bulletin Board. DjangoBB is distributed under the BSD license.

LLK/scratchr2_translations 13

Translations for the Scratch 2.0 website

CommitCommentEvent

Pull request review commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

 func buy(  ## Detailed design -Property wrappers are essentially sugar wrapping a given declaration with compiler-synthesized code. This proposal retains this principle. Annotating a parameter declaration with a property-wrapper attribute allows the call-site to pass a wrapped value or a projected value, and the compiler will automatically initialize the backing wrapper to pass to the function. The function author can also use the property-wrapper syntax for accessing the backing wrapper and the projected value in the body of the function.+Property wrappers are essentially sugar wrapping a given declaration with compiler-synthesized code. Retaining this principle, a function can now be called with the wrapped and projected values. Namely, annotating a parameter declaration with a property-wrapper attribute changes the declaration’s type to the backing storage, and prompts the compiler to synthesize the wrapped and projected values. When the function is called the compiler will, also, insert a call to the appropriate property-wrapper initializer.

Ok, I see your point. Upon rereading the paragraph, I realize that expecting to hear about the current design (since it's in the section's name), I read about existing behavior, which is then paralleled to new behavior. I find this problematic because the reader will –– up to this point –– be unfamiliar with this new behavior. Thus, what do you think of simply moving the first two periods in the end?


Annotating a parameter declaration with a property-wrapper attribute allows the call-site to pass a wrapped value or a projected value, and the compiler will automatically initialize the backing wrapper to be passed to the function. The function author can also use the property-wrapper syntax for accessing the backing wrapper and the projected value within the body of the function. This behavior merely builds on property wrappers’ being sugar wrapping a given declaration with compiler-synthesized code.

filip-sakel

comment created time in 20 minutes

pull request commentapple/swift

[AST] #SR-13906 (Improvement) Error Messages

@swift-ci Please smoke test

aniketiq

comment created time in 31 minutes

CommitCommentEvent

Pull request review commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

 func buy(  ## Detailed design -Property wrappers are essentially sugar wrapping a given declaration with compiler-synthesized code. This proposal retains this principle. Annotating a parameter declaration with a property-wrapper attribute allows the call-site to pass a wrapped value or a projected value, and the compiler will automatically initialize the backing wrapper to pass to the function. The function author can also use the property-wrapper syntax for accessing the backing wrapper and the projected value in the body of the function.+Property wrappers are essentially sugar wrapping a given declaration with compiler-synthesized code. Retaining this principle, a function can now be called with the wrapped and projected values. Namely, annotating a parameter declaration with a property-wrapper attribute changes the declaration’s type to the backing storage, and prompts the compiler to synthesize the wrapped and projected values. When the function is called the compiler will, also, insert a call to the appropriate property-wrapper initializer.

I think these changes have obscured the meaning/purpose of this paragraph.

Retaining this principle, a function can now be called with the wrapped and projected values

I don't think this makes sense without the context of "Annotating a parameter declaration with a property-wrapper attribute". Also, the fact that a function can be called with a wrapped value or a projected value of a property wrapper doesn't really follow from "retaining this principle"

annotating a parameter declaration with a property-wrapper attribute changes the declaration’s type to the backing storage

This isn't something we want to state unless we're explicitly talking about how the code is compiled. As far as the user is concerned, the function type does not take in the backing storage. That's why had worded the sentence to be about the call-site.

and prompts the compiler to synthesize the wrapped and projected values

The wrapped and projected values are not synthesized, they're provided by the user.

I'm not sure why this last sentence was removed:

The function author can also use the property-wrapper syntax for accessing the backing wrapper and the projected value in the body of the function

This is showcasing how the feature is useful for function authors because they now have property-wrapper syntax in the body of the function.

filip-sakel

comment created time in an hour

push eventapple/swift-evolution

Joe Groff

commit sha 753e81fad04f070a39df867f10ecab90fab84d49

begin review for SE-299

view details

push time in 2 hours

Pull request review commentapple/swift

[docs] Tidy and document permissible conversions based on calling conventions

 ConstraintSystem::matchTupleTypes(TupleType *tuple1, TupleType *tuple2,   return getTypeMatchSuccess(); } -// Determine whether conversion is allowed between two function types-// based on their representations.+/// Check where a representation is a subtype of another.+///+/// The subtype relationship is defined as:+/// 1. any representation R is a sub-type of itself.+/// 2. a thin representation is a subtype of any other representation.+/// 3. a thick representation is a subtype of any other representation.

Sounds good!

varungandhi-apple

comment created time in 2 hours

Pull request review commentapple/swift

[docs] Tidy and document permissible conversions based on calling conventions

 ConstraintSystem::matchTupleTypes(TupleType *tuple1, TupleType *tuple2,   return getTypeMatchSuccess(); } -// Determine whether conversion is allowed between two function types-// based on their representations.+/// Check where a representation is a subtype of another.+///+/// The subtype relationship is defined as:+/// 1. any representation R is a sub-type of itself.+/// 2. a thin representation is a subtype of any other representation.+/// 3. a thick representation is a subtype of any other representation.

Yeah, made a mistake there, it should be "a thick representation is a subtype of any other thick representation"

varungandhi-apple

comment created time in 2 hours

Pull request review commentapple/swift

[docs] Tidy and document permissible conversions based on calling conventions

 ConstraintSystem::matchTupleTypes(TupleType *tuple1, TupleType *tuple2,   return getTypeMatchSuccess(); } -// Determine whether conversion is allowed between two function types-// based on their representations.+/// Check where a representation is a subtype of another.+///+/// The subtype relationship is defined as:+/// 1. any representation R is a sub-type of itself.+/// 2. a thin representation is a subtype of any other representation.+/// 3. a thick representation is a subtype of any other representation.

I think you are correct, at least that is how it was handled before, even examples still have passing a swift closure to @conversion(c) parameter as an error.

varungandhi-apple

comment created time in 2 hours

pull request commentapple/swift-source-compat-suite

Add grpc-swift

Sout compat suite builds a toolchain from the HEAD of main branch and uses it to build the projects.

glbrntt

comment created time in 3 hours

pull request commentapple/swift

LoadableByAddress: fix a crash related to single-element tuples containing a label and a closure.

Build failed Swift Test Linux Platform Git Sha - 132b09b5c80f18aefcbcac67bf08469dae196a70

eeckstein

comment created time in 3 hours

Pull request review commentapple/swift

[Diagnostics] Add specific warning for overriden `NSObject.hash(into:)`

 static bool isNSObjectHashValue(ValueDecl *baseDecl) {   return false; } +/// Returns true if the given declaration is for the `NSObject.hash(into:)`+/// function.+static bool isNSObjectHashMethod(ValueDecl *baseDecl) {+  ASTContext &ctx = baseDecl->getASTContext();++  if (auto baseVar = dyn_cast<FuncDecl>(baseDecl)) {

Nit: this name should be baseFunc ? Also the ctx variable is only used in case is this is true So this could be

static bool isNSObjectHashMethod(ValueDecl *baseDecl) {
   auto baseFunc = dyn_cast<FuncDecl>(baseDecl);
   if (!baseFunc)
      return false;

   if (auto classDecl = baseFunc->getDeclContext()->getSelfClassDecl()) {
     ASTContext &ctx = baseFunc->getASTContext();
     return baseFunc->getBaseName() == ctx.Id_hash && classDecl->isNSObject();
   }
   return false;
 }

WDYT?

mininny

comment created time in 3 hours

Pull request review commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

 Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-  Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) to expose elaborate behavior through a succinct interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to local variables and type properties, shattering the illusion that they helped realize in the first place when working with parameters. -### Memberwise initialization+Property wrappers attached to parameters have a wide variety of use cases. We present a few examples here. -Currently, property-wrapper attributes on struct properties interact with function parameters through the struct's synthesized memberwise initializer. However, property-wrapper attributes are _not_ supported on function parameters. This leads to complicated and nuanced rules for which type, between the wrapped-value type and the backing property-wrapper type, the memberwise initializer accepts.+### Argument validation -The compiler will choose the wrapped-value type to offer a convenience to the call-site when the property wrapper has an initializer of the form `init(wrappedValue:)` accepting the wrapped-value type, as seen here:+Both library developers and language users often need to assert their assumptions, for which `precondition(_:_:)` is often used:  ```swift-import SwiftUI---struct TextEditor {--  @State var document: Optional<URL>-  +enum Product {+  case plainSandwich +  case grilledCheeseSandwich +  case avocadoToast } --func openEditor(with swiftFile: URL) -> TextEditor {-  TextEditor(document: swiftFile) -  // The wrapped type is accepted here.+func buy(quantity: Int, of product: Product) {+  precondition(quanity >= 1, "Invalid product quanity.")+  +  if quantity == 1 {+    ...+  } } ``` -However, this can take flexibility away from the call-site if the property wrapper has other `init` overloads, because the call-site _cannot_ choose a different initializer. Further, if the property wrapper is explicitly initialized via `init()`, then the memberwise initializer will choose the backing-wrapper type, even if the wrapper supports `init(wrappedValue:)`. This results in unnecessary boilerplate at call-sites that _do_ want to use `init(wrappedValue:)`:+The above code is quite clear; it has, though, the obvious drawback that changing the the condition to be asserted or its error message requires significant effort as a precondition statement is individually written for each function and manually documented.++Furthermore, supposing the above is library code, we may want to test for our precondition while offering an easy-to-debug way. So, using `Validation` from [`PropertyKit`](https://github.com/SvenTiigi/ValidatedPropertyKit) we can write:  ```swift-import SwiftUI+@propertyWrapper+struct Asserted<Value> {+  // The assertion will appear at the right file and line+  init(+    wrappedValue: Value, +    validation: Validation<Value>,+    file: StaticString = #file,+    line: UInt = #line+  ) {+    ...+  } +  var wrappedValue: Value { ... } -struct TextEditor {+  var projectedValue: Result<Value, ValidationResult> { ... }+} -  @State() var document: Optional<URL>++func buy(+  quantity: Int, +  of product: Product,+  file: StaticString = #file,+  line: UInt = #line+  // These are a lot of properties for every time+  // we want to check for the right quantity.+) {+  var validatedQuantity = Asserted(+    quantity,+    .greaterOrEqual(1),+    file: file, +    line: line+  )   +  if validatedQuantity.wrappedValue == 1 {+    // The lack of property-wrapper tranformation is+    // evident here.+    ...+  } }+```++This not only makes writing easy-to-maintain validations easy, but improves debugging for the the API's users as well. Unfortunately, it still lacks the elegant syntax property wrappers offer, making the creation of new functions a demanding task.++### Pass-by-value for reference types +The `@NSCopying` attribute is a tool to emulate value semantics for reference-type properties. The same functionality can now be implemented as a property wrapper, as shown in [SE-0258](https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md#nscopying): -func openEditor(with swiftFile: URL) -> TextEditor {-  TextEditor(document: State(wrappedValue: swiftFile))-  // The wrapped type isn't accepted here; instead we have -  // to use the backing property-wrapper type: 'State'.+```swift+@propertyWrapper+struct Copying<Value: NSCopying> {+  private var _value: Value++  init(wrappedValue value: Value) {+    // Copy the value on initialization.+    self._value = value.copy() as! Value+  }++  var wrappedValue: Value {+    get { return _value }+    set {+      // Copy the value on reassignment.+      _value = newValue.copy() as! Value+    }+  } } ``` -Note also that the argument label does not change when the memberwise initializer uses the backing wrapper type instead of the wrapped-value type.+However, this property wrapper cannot be used on parameters to achieve pass-by-value semantics for reference-type arguments. To achieve pass-by-value semantics, `copy()` must be called manually, which is easy to forget, or the `Copying` type must be used directly in an API, which causes each call-site to manually create an instance of `Copying`. -If the generated memberwise initializer always accepted the backing wrapper type while still allowing the call-site the convenience of automatically initializing the backing wrapper via a wrapped-value type, the mental model for property wrapper initialization would be greatly simplified. Moreover, this would provide more control over the backing-wrapper initialization at the call-site.--### Function parameters with property wrapper type+### Memberwise initialization -Using property-wrapper types for function parameters also results in boilerplate code, both in the function body and at the call-site:+Consider the following property wrapper, inspired by `@Traceable` from [David Piper's blog post](https://medium.com/better-programming/creating-a-history-with-property-wrappers-in-swift-5-1-4c0202060a7f), which tracks the history of a value:  ```swift+struct History<Value> { ... }+ @propertyWrapper-struct Lowercased {+struct Traceable<Value> { -  init(wrappedValue: String) { ... }+  init(wrappedValue value: Value) { ... } +  init(projectedValue: History<Value>) { ... } -  var wrappedValue: String {-    get { ... }-    set { ... }+  var wrappedValue: Value {+    get {+      return history.currentValue+    }+    set {+      history.append(newValue)+    }   }-  ++  var projectedValue: History<Value> { return history }++  private var history: History<Value>+ }+``` +This property wrapper can be initialized with a value to be traced, or with an existing history of a value being traced. Now consider the following model for a simple text editor that supports change tracking: -func postUrl(urlString: Lowercased) {-  guard let url = URL(string: urlString.wrappedValue) else { return }-    //                                 ^~~~~~~~~~~~~-    // We must access 'wrappedValue' manually.-  ...+```swift+struct TextEditor {+  @Traceable var dataSource: String }+```++Currently, property-wrapper attributes on struct properties interact with function parameters through the struct's synthesized memberwise initializer. Because the `@Traceable` property wrapper supports initialization from a wrapped value via `init(wrappedValue:)`, the memberwise initializer for `TextEditor` will take in a `String`. However, the programmer may want to initialize `TextEditor` with a string value that already has a history. Today, this can be achieved with overloads, which can greatly impact compile-time performance, or by exposing the `Traceable` type through the `TextEditor` initializer, which is meant to be implementation detail.++## Proposed solution +We propose to allow application of property wrappers on function and closure parameters, allowing the call-site to pass a wrapped value or a projected value which will be used to automatically initialize the backing property wrapper. -postUrl(urlString: Lowercased(wrappedValue: "mySite.xyz/myUnformattedUsErNAme"))-//                 ^~~~~~~~~~-// We must initialize `Lowercased` manually,-// instead of automatically initializing-// from its wrapped value type.+Using property-wrapper parameters, the above argument validation example can be simplified to:++```swift+func buy(+  @Asserted(.greaterOrEqual(1)) quantity: Int,+  of product: Product,+) {+  if quantity == 1 {+    ...+  }+} ``` -In the above example, the inability to apply property wrappers to function parameters prevents the programmer from removing unnecessary details from the code. The call-site of `postUrl` is forced to initialize an instance of `Lowercased` manually using `init(wrappedValue:)`, even though this initailization is automatic when using `@Lowercased` on a local variable or type property. Further, manually accessing `wrappedValue` in the function body can be distracting when trying to understand the implementation. These limitations are emphasized by the fact that property wrappers were originally sought out to eliminate such boilerplate.+## Detailed design++Property wrappers are essentially sugar wrapping a given declaration with compiler-synthesized code. Retaining this principle, a function can now be called with the wrapped and projected values. Namely, annotating a parameter declaration with a property-wrapper attribute changes the declaration’s type to the backing storage, and prompts the compiler to synthesize the wrapped and projected values. Furthermore, when the function is called the compiler will insert a call to the appropriate property-wrapper initializer. -### Closures accepting property-wrapper types+### Function-body semantics -Consider the following SwiftUI code, which uses [`ForEach`](https://developer.apple.com/documentation/swiftui/foreach) over a collection:+Attaching a property wrapper to a parameter makes that parameter a computed variable local to the function body, and changes the parameter type to the backing wrapper type. The type of the parameter is only observable in compiled code - [unapplied references to functions with property-wrapped parameters](#unapplied-function-references) will not use the backing-wrapper type.++The transformation of function with a property-wrapped parameter will be performed as such:++1. The argument label will remain unchanged. +2. The parameter name will be prefixed with an underscore.+3. The type of the parameter will be the backing property-wrapper type.+4. A local computed property representing the `wrappedValue` of the innermost property wrapper will be synthesized with the same name as the original, unprefixed parameter name. If the innermost `wrappedValue` defines a setter, a setter will be synthesized for the local property if the mutability of the composed setter is `nonmutating`. The mutability computation is specified in the [appendix](#appendix).+5. If the outermost property wrapper defines a `projectedValue` property with a `nonmutating` getter, a local computed property representing the outermost `projectedValue` will be synthesized and named per the original parameter name prefixed with a dollar sign (`$`). If the outermost `projectedValue` defines a setter, a setter for the local computed property will be synthesized if the `projectedValue` setter is `nonmutating`.++Consider the following function with a property-wrapped parameter using the `@Asserted` property wrapper:  ```swift-struct MyView : View {+func insert(@Asserted(.nonEmpty) text: String) { ... }+``` -  // A simple Shopping Item that includes-  // a 'quantity' and a 'name' property.-  @State-  private var shoppingItems: [Item]+The compiler will synthesize computed `text` and `$text` variables in the body of `insert`: -  var body: some View {-    ForEach(0 ..< shoppingItems.count) { index in-      TextField(shoppingItems[index].name, $shoppingItems[index].name)-    }+```swift+func insert(text _text: Asserted<String>) {+  var text: String {+    get { _text.wrappedValue }+  }++  var $text: Result<String, ValidationResult> {+    get { _text.projectedValue }   } +  ... } ``` -Working with `shoppingItems` in the closure body is painful, because the code must manually index into the original wrapped property, rather than working with collection elements directly in the closure. The manual indexing would be alleviated if the closure accepted `Binding`s to collection elements:+### Call-site semantics++When passing an argument to a function with a property-wrapped parameter, the compiler will wrap the argument in a call to the appropriate initializer depending on the argument label. When using the original argument label (or no argument label), the compiler will wrap the argument in a call to `init(wrappedValue:)`. When using the argument label prefixed with `$` (or `$_` in the case of no argument label), the compiler will wrap the argument in a call to `init(projectedValue:)`. ++Consider the `@Traceable` property wrapper that implements both `init(wrappedValue:)` and `init(projectedValue:)`:  ```swift-struct MyView : View {+struct History<Value> { ... } -  // A simple Shopping Item that includes-  // a 'quantity' and a 'name' property.-  @State-  private var shoppingItems: [Item]+@propertyWrapper+struct Traceable<Value> { -  var body: some View {-    ForEach($shoppingItems) { itemBinding in-      TextField(itemBinding.wrappedValue.name, itemBinding.name)-    }-  }+  init(wrappedValue value: Value)++  init(projectedValue: History<Value>)++  var wrappedValue: Value++  var projectedValue: History<Value>  } ``` -However, now we observe the same boilerplate code in the closure body because the property-wrapper syntax cannot be used with the closure parameter.+A function with an `@Traceable` parameter can be called with either a wrapped value or a projected value: -## Proposed solution+```swift+func log<Value>(@Traceable value: Value) { ... } -We propose to allow application of property wrappers on function and closure parameters.+let history: History<Int> = ...+log(value: 10)+log($value: history)+``` -Using property-wrapper parameters, the above `postUrl` example becomes:+The compiler will inject a call to the appropriate property-wrapper initializer into each call to `log` based on the argument label, so the above code is transformed to:  ```swift-func postUrl(@Lowercased urlString: String) {-  guard let url = URL(string: urlString) else { return }-  ...-}--postUrl(urlString: "mySite.xyz/myUnformattedUsErNAme")+log(value: Traceable(wrappedValue: 10))+log(value: Traceable(projectedValue: history)) ``` -In the above SwiftUI example, if collection elements could be accessed via `Binding`s in the `ForEach` closure, property-wrapper parameters could be used to enable property-wrapper syntax in the closure body:+Wrapped parameters with no argument label can still be passed a projection using the syntax `$_:`, as shown in the following example:  ```swift-struct MyView: View {+func log<Value>(@Traceable _ value: Value) { ... }++let history: History<Int> = ...+log(10)+log(_: 10)+log($_: history)+``` -  @State-  private var shoppingItems: [Item]+For composed property wrappers, initialization of the backing wrapper via wrapped value will contain a call to `init(wrappedValue:)` for each property-wrapper attribute in the composition chain. However, initialization via projected value will only contain one call to `init(projectedValue:)` for the outermost wrapper attribute, because property wrapper projections are not composed. For example:  -  var body: some View {-    ForEach($shoppingItems) { (@Binding item) in-      TextField(item.name, $item.name)-    }-  }+```swift+func log(@Traceable @Traceable text: String) { ... } -}+let history: History<Traceable<String>> = ...+log(text: "Hello!")+log($text: history) ``` -## Detailed design+The above calls to `log` are transformed to: -Property wrappers are essentially sugar wrapping a given property with compiler-synthesized code. This proposal retains this principle, employing the following transformation.+```swift+log(text: Traceable(wrappedValue: Traceable(wrappedValue: "Hello!"))+log(text: Traceable(projectedValue: history))+``` -### Function body transformation+This transformation at the call-site only applies when calling the function directly using the declaration name. The semantics of closures and unapplied function references are specified [in a later section](#semantics-of-function-expressions). -The transformation of function with a property-wrapper parameter will be performed as such:+#### Passing a projected value argument -1. For regular functions, the argument label will remain unchanged. -2. The parameter name will be prefixed with an underscore.-3. The type of the parameter will be the backing property-wrapper type.-4. A local computed property representing the `wrappedValue` of the innermost property wrapper will be synthesized with the same name as the original, unprefixed parameter name. If the innermost `wrappedValue` defines a setter, a setter will be synthesized for the local property if the mutability of the composed setter is `nonmutating`. The mutability computation is specified below.-5. If the outermost property wrapper defines a `projectedValue` property, a local computed property representing the outermost `projectedValue` will be synthesized and named per the original parameter name prefixed with a dollar sign (`$`). If the outermost `projectedValue` defines a setter, a setter for the local computed property will be synthesized if the `projectedValue` setter is `nonmutating`, or if the outermost wrapper is a reference type.+Property wrappers can opt into passing a projected-value argument to a property-wrapped parameter. -#### Mutability of composed `wrappedValue` accessors+Though property-wrapper projections can be utilized to expose arbitrary API through the synthesized `$` property, projections are typically used to either publicly expose the backing property wrapper directly, or to provide a public representation of the backing wrapper that's suitable for use outside of the declaration that owns the wrapper storage. In such cases, supporting property-wrapper initialization from a projected-value is very useful, especially if the wrapper does not support `init(wrappedValue:)`. To support passing a property-wrapper projection to a function with a wrapped parameter, property wrappers can implement `init(projectedValue:)`. -The computation for mutability of a wrapped parameter's composed `wrappedValue` accessors will be the same as it is today for wrapped properties. The computation starts with the mutability of the outermost wrapper's `wrappedValue` accessor, and then iterates over the chain of composed property wrappers, "composing" the mutability of each `wrappedValue` accessor along the way using the following rules, which are the same for getters and setters:+Presence of an `init(projectedValue:)` that meets the following requirements enables passing a projected value via the `$` calling syntax: -* If the next `wrappedValue` accessor is `nonmutating`, then the mutability of the composed accessor is the same as the previous composed getter. If the wrapper is a reference type, the accessor is considered `nonmutating`.-* If the next `wrappedValue` accessor is `mutating`, then the composed accessor is `mutating` if the previous composed getter _or_ setter is `mutating`, since both are needed to perform a writeback cycle.+- The first parameter of this initializer must be labeled `projectedValue` and have the same type as the `var projectedValue` property.

If I understand correctly, declaring a projectedValue property is not mandatory; should we perhaps state this explicitly?

We should probably add a rationale for this behavior, as well.

filip-sakel

comment created time in 4 hours

issue openedswift-server/swift-service-lifecycle

Swift Metrics is included in the Package but is never used

Is there a plan to use it at some point?

created time in 4 hours

pull request commentapple/swift

[AST] #SR-13906 (Improvement) Error Messages

Testing Time: 5781.66s
  Unsupported      :  224
  Passed           : 6249
  Expectedly Failed:   24

5 warning(s) in tests
aniketiq

comment created time in 4 hours

Pull request review commentapple/swift

[cxx-interop] Add support for custom C++ destructors.

+// With RTTI some of the objects with virtual bases / destructors in this test

Please rename the test to follow the pattern. Since it imports CustomDestructors, it should be named custom-destructors-irgen.swift.

zoecarver

comment created time in 4 hours

Pull request review commentapple/swift

[cxx-interop] Add support for custom C++ destructors.

+// With RTTI some of the objects with virtual bases / destructors in this test

Please rename the test to follow the pattern. Since it imports CustomDestructors, it should be named custom-destructors-virtual-irgen.swift.

zoecarver

comment created time in 4 hours

Pull request review commentapple/swift

[cxx-interop] Add support for custom C++ destructors.

+// RUN: %target-swift-frontend -enable-cxx-interop -I %S/Inputs %s -emit-ir | %FileCheck %s

Assuming you rename the other test to custom-destructors-virtual-irgen.swift, please rename this one to custom-destructors-non-virtual-irgen.swift.

zoecarver

comment created time in 4 hours

Pull request review commentapple/swift

[cxx-interop] Add support for custom C++ destructors.

+struct HasUserProvidedDestructor {

Please add an include guard.

zoecarver

comment created time in 4 hours

Pull request review commentapple/swift

[cxx-interop] Add support for custom C++ destructors.

+// RUN: %target-swift-frontend -enable-cxx-interop -I %S/Inputs %s -emit-ir | %FileCheck %s

Please rename the test to start with destructors- (because it uses the C++ module with that name).

zoecarver

comment created time in 4 hours

PR opened netty/netty-incubator-buffer-api

Avoid nesting composite buffers

Motivation: There is no reason that composite buffers should nest when composed. Instead, when composite buffers are used to compose or extend other composite buffers, we should unwrap them and copy the references to their constituent buffers.

Modification: Composite buffers now always unwrap and flatten themselves when they participate in composition or extension of other composite buffers.

Result: Composite buffers are now always guaranteed* to contain a single level of non-composed leaf buffers.

*assuming no other unknown buffer-wrapping buffer type is in the mix.

+125 -11

0 comment

2 changed files

pr created time in 4 hours

create barnchnetty/netty-incubator-buffer-api

branch : composite-flatten

created branch time in 4 hours

Pull request review commentapple/swift

[cxx-interop] Use user defined copy constructor to copy C++ objects.

 namespace {             !cxxRecordDecl->isTriviallyCopyable());          for (auto ctor : cxxRecordDecl->ctors()) {-          if (ctor->isCopyConstructor() &&-              (ctor->isDeleted() || ctor->getAccess() != clang::AS_public)) {+          if (ctor->isCopyConstructor()) {+            // If we have no way of copying the type we can't import the class at+            // all because we cannot (yet) express the correct semantics as a+            // swift object.+            if (ctor->isDeleted())+              return nullptr;+          }+          if (ctor->getAccess() != clang::AS_public) {

True. However, I think we have to still check for public access level, since it would be otherwise quite weird that Swift can use a private constructor -- even if it is trivial.

zoecarver

comment created time in 5 hours

Pull request review commentapple/swift

[cxx-interop] Use user defined copy constructor to copy C++ objects.

 func pass(s: StructWithSubobjectDefaultedCopyConstructor) {  // CHECK-LABEL: sil hidden [ossa] @$s4main4pass{{.*[ (]}}StructWithPrivateDefaultedCopyConstructor) func pass(s: StructWithPrivateDefaultedCopyConstructor) {-  // CHECK: bb0(%0 : $*StructWithPrivateDefaultedCopyConstructor):

Agreed. However, you added this code:

            if (ctor->isDeleted() || ctor->getAccess() != clang::AS_public)
              return nullptr;

shouldn't it take care of rejecting it based on the access control level?

zoecarver

comment created time in 5 hours

Pull request review commentapple/swift

[cxx-interop] Use user defined copy constructor to copy C++ objects.

+// Target-specific tests for C++ copy constructor code generation.

Please rename the file to follow the pattern. constructors-copy-irgen.swift

zoecarver

comment created time in 5 hours

Pull request review commentapple/swift

[cxx-interop] Use user defined copy constructor to copy C++ objects.

 // This definition is a placeholder for importing into Swift. // It provides size and alignment but cannot be manipulated safely there. typedef struct {-  __swift_uintptr_t refCounts SWIFT_ATTRIBUTE_UNAVAILABLE;

So, in C-mode this attribute is meaningless which is why we didn't see the error before now.

Which error?

zoecarver

comment created time in 5 hours

Pull request review commentapple/swift

[cxx-interop] Use user defined copy constructor to copy C++ objects.

+struct HasUserProvidedCopyConstructor {+  int numCopies;+  HasUserProvidedCopyConstructor(int numCopies = 0) : numCopies(numCopies) {}+  HasUserProvidedCopyConstructor(const HasUserProvidedCopyConstructor &other)+      : numCopies(other.numCopies + 1) {}+};

Consider renaming the file to reflect better its contents. copy-constructors.h

zoecarver

comment created time in 5 hours

Pull request review commentapple/swift

[cxx-interop] Use user defined copy constructor to copy C++ objects.

+// RUN: %target-swift-frontend -enable-cxx-interop -I %S/Inputs %s -emit-ir | %FileCheck %s

Please rename the test to follow the name of the C++ module.

zoecarver

comment created time in 5 hours

Pull request review commentapple/swift

[cxx-interop] Use user defined copy constructor to copy C++ objects.

+struct HasUserProvidedCopyConstructor {

Please add include guards.

zoecarver

comment created time in 5 hours

Pull request review commentapple/swift

[cxx-interop] Use user defined copy constructor to copy C++ objects.

+// RUN: %target-swift-ide-test -print-module -module-to-print=Constructors -I %S/Inputs -source-filename=x -enable-cxx-interop | %FileCheck %s

Please rename this swift file to start with 'constructors-' to match the existing naming pattern. constructors-copy-module-interface.swift.

zoecarver

comment created time in 5 hours

more