@swift-ci please test

🤞

Ok! I’ll give that a shot and see if there’s any unexpected fallout.

Build failed Swift Test OS X Platform Git Sha - df28939255e45326189ee956ce9c088665c91f24

@swift-ci please smoke test macOS

Frankly I'm not sure exactly why it wasn't made to fail, I'd suggest you try to return ErrorType wrapping fnTy for cases when diagnoseInvalidFunctionType would produce an error in resolveASTFunctionType (so that code completion would still have access to underlying type) and return nullptr in coerceToType.

@swift-ci Please smoke test

#available(insertOSHere 9999) is always true when using swift.org toolchains. So wrap things in if #available(insertOSHere 9999) { }.

I recommend adding a ChannelHandler to your pipeline that prints errors:

final class ErrorHandler: ChannelInboundHandler {
    typealias InboundIn = Any

    func errorCaught(context: ChannelHandlerContext, error: Any) {
        print("caught error: \(error)")
    }
}

This will likely show an error being fired into the ChannelPipeline.

@swift-ci smoke test

We previously were computing this eagerly meaning that if we did not actually need the DomTreeLevel map, we would calculate it and additionally incur a relatively large malloc for the DenseMap (which stores by default IIRC 64 key value pairs).

Now, we do it lazily ensuring that we only compute this if we actually need it (when promoting non-single block stack allocations).

@stmontgomery @millenomi @compnerd Could you please provide your inputs on this?

@stmontgomery @millenomi @compnerd Could you please provide your inputs on this?

DeclAttribute::print() accepts null decls and has a null default argument. A segfault was triggered in SourceKitService because printDifferentiableAttrArguments took a null decl and deferenced it. This patch makes printDifferentiableAttrArguments() handle null decls — if the decl is null, we do not print the differentiability parameters or the where clause.

I have not added a unit test however because I haven't been able to reproduce it independently. This will be done later as this change is low-risk.

Resolves rdar://76095289.

As suggested by @atrick in review feedback in #36913.

@lorentey first of all, sorry for long feedback.

What @kylemacomber said should be correct (at least according to this and this).

Which should mean that changes are only useful form code-style perspective.

But I did some additional performance testing for Deque (because _DequeBuffer was changed to final) to make sure that all works as expected. Did comparison of Deque with final _DequeBuffer vs non-final.

First, simply tested append operation with performance test (using measure).

func testAppend() {
  var deque = Deque<Int>()
    
  let options = XCTMeasureOptions()
  options.iterationCount = 100
    
  measure {
    (0...1000000).forEach { _ in deque.append(1) }
  }
}

Results:

• Without WMO.
  • final - 0.775
  • non-final - 0.778 sec
• With WMO (-O)
  • final - 0.024
  • non-final - 0.026 sec

Then, benchmark test append (max-size - 16M, cycles - 20).

Difference is quite small (and can be just accuracy error). Now for me it seems that changes are only useful to keep same style and do things explicit.

So @lorentey if you think that this PR is unnecessary, please feel free to close it 😀

@swift-ci Please smoke test

@swift-ci Please smoke test

Instead of an underscored attribute, we could instead formalize it by introducing a new rethrows(unsafe) spelling in the function signature.

This would make sense to me—that, or some scoped bridging mechanism to allow an engineer to say "I'm going to call an intermediate function that can't throw an error itself (e.g. because it's @convention(c)), but which may need to catch an error thrown by the passed closure. Trust me." Which is of course what the new attribute does, but having a with-like function might be better from a readability standpoint (and would allow us to limit the scope of such behaviour to a specific subsection of the rethrowing function's body rather than the whole body.)

If nothing else, we could reserve the @_rethrowsUnchecked attribute for this with-like function only and tell everyone else to call it and not use the attribute directly.

It would be valuable to land this attribute before the checker changes so that code that relies on the current behaviour (such as DispatchQueue) has an opportunity to migrate.

Got it, makes sense. Yeah, you're right that to do this we'll have to have diagnoseInvalidFunctionType indicate failure.

Looking back at the "old" implementation, it looks like during type resolution we diagnosed these invalid types but didn't fail resolution, so presumably those invalid function types are getting applied to the AST. Do you think it makes sense to fail the application in all cases? I.e., remove the diagnoseInvalidFunctionType check from TypeResolver::resolveASTFunctionType and perform it only in coerceToType for all function types (not just those that had a placeholder), and fail coercion if so?

@swift-ci Please smoke test

It make sense to remove the article, thanks @harlanhaskins :)

Hey,

I'm trying to connect using a .pem file and private key. I have the following code:

class TCPClient1 {
    
    let handler = TCPClientHandler1()
    
    private let group = MultiThreadedEventLoopGroup(numberOfThreads: 1)
    var channel: Channel!
    
    func connect(host: String, port: Int) {
        do {
            channel = try buildBootstrap().connect(host: host, port: port).wait()
            try channel.closeFuture.wait()
        } catch let error {
            print(error)
        }
    }
    
    
    func buildBootstrap() -> ClientBootstrap {
        
        // client certificate and private key
        let myCertPath = Connector.findFileInProject("public-cert-no-pass", ".pem")!.relativePath
        let myKeyFile = Connector.findFileInProject("private-key-no-pass", ".pem")!.relativePath
        
        do {
            
            // client configurations
            var configuration = TLSConfiguration.forClient(certificateChain: try NIOSSLCertificate.fromPEMFile(myCertPath).map { .certificate($0) },
                                                           privateKey: .file(myKeyFile))
            
            configuration.certificateVerification = .noHostnameVerification // or `.fullVerification`
            configuration.trustRoots = .file(myCertPath) // only necessary if the server uses a self-signed cert or a custom CA that isn't trusted by the system. If your server has a real cert, you can delete this line
            
            
            let sslContext = try NIOSSLContext(configuration: configuration)
            
            
            return ClientBootstrap(group: group)
                .channelOption(ChannelOptions.socket(SocketOptionLevel(SOL_SOCKET), SO_REUSEADDR), value: 1)
                .channelOption(ChannelOptions.socket(IPPROTO_TCP, TCP_NODELAY), value: 1)
                .channelInitializer { channel in
                    var sslHandler: NIOSSLClientHandler?
                    do {
                        sslHandler = try NIOSSLClientHandler(context: sslContext, serverHostname: nil)
                    } catch let error {
                        print(error)
                    }
                    return channel.pipeline.addHandlers([ChannelHandler](arrayLiteral: sslHandler!, self.handler))
                }
            
            
        } catch let error {
            print(error)
            fatalError("What!")
        }
    }
    
    func stop() {
        do {
            try group.syncShutdownGracefully()
        } catch let error {
            print("Error shutting down \(error.localizedDescription)")
            exit(0)
        }
        print("Client connection closed")
    }
}

When I run connect with an ip and port I get (from the handler callbacks): registered! inactive channel! unregister channel!

So, for some reason, the channel is immediately turned to inactive upon connection. Anyone know why?

Thanks!

Question is: how to actually use any of these now? I can't get -disable-availability-checking working with SPM :(

And maybe also for the init and all the children?