[swift-dev] RecoverableError.attemptRecovery

Hi community, I’m working on SR-4405 (stdlib) which needs to: 1) add escaping closure to resultHandler parameter, and then. 2) write a test case to exercise asynchronous handling of the error for attemptRecovery in RecoverableError protocol. I’m still working on the first step. I’m not sure wher

Re: [swift-dev] [swift-evolution] [Question] Absolute paths in executable .swiftmodule files

Yep, Bazel has the same concerns with both debugging and caching cases. I don't think there's any option to change this today, there are places in code that assume or construct absolute paths. I have filed https://bugs.swift.org/browse/SR-5694 to track this. In my experience, if your output loca

Re: [swift-dev] [swift-evolution] [Question] Absolute paths in executable .swiftmodule files

Tony, Thanks for redirecting this conversation to the swift-dev mailing list. I wasn't 100% sure I was pointing in the right direction. I'm moving swift-evolution to the BCC (that way we won't keep bothering them.) Thanks, Pepper On Thu, Sep 14, 2017 at 6:13 PM Tony Allevato wrote: > Thanks fo

Re: [swift-dev] [swift-evolution] [Question] Absolute paths in executable .swiftmodule files

Thanks for bringing this up, Pepper! We have many of the same issues with our Swift support in Bazel ; since .swiftmodule files aren't hermetic, we can't reliably cache them. The proliferation of import paths in the modules is another major issue—as part of our

Re: [swift-dev] build-script has newfound interest in ninja source?

Are you passing the path to the existing ninja binary when building? ninja-bin "" "the path to Ninja tool" If not, it will likely try and build ninja for you. if ninja_required and toolchain.ninja is None: args.build_ninja = True Alex > On