My bad, I forgot a cherry-pick. Should be fixed now.
On 24 March 2017 at 10:29, wrote:
> New issue found!
> [FAILURE] oss-swift-4.0-incremental-RA-osx [#27]
> Build URL: https://ci.swift.org/job/oss-swift-4.0-incremental-RA-osx/27/
> Project: oss-swift-4.0-incremental-RA-osx
> Date of build: Fri
Looks like there's some unrelated issue (not caused by my cherry-picks):
CMake Error at stdlib/public/SwiftShims/CMakeLists.txt:76 (message):
Clang headers were not found in any of the following locations:
/Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/buildbot_incremental/
It's now back to this error:
/Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/swift/lib/ClangImporter/ImportName.cpp:575:30:
error: no member named 'SwiftSuppressFactoryAsInitAttr' in namespace 'clang'
if (method->hasAttr()) {
~~~^
/Users/buildnode/je
This seems to be fixed in the next build. I’ve integrated the radar.
Xi
> On Mar 23, 2017, at 8:46 PM, Slava Pestov wrote:
>
> I thought this was my changes but then it cleared up on the next build.
>
> Xi, I filed rdar://31234811 with some information. Since
> you’re the build czar can you
I'm currently working on integrating SourceKit with a macOS application. AppKit
APIs (e.g. NSAttributedString, NSLayoutManager, etc) deal in terms of NSRange
(UTF-16 code units?). SourceKit, however, deals in terms of integer offsets and
lengths (UTF-8 code units?). Is there a more efficient or
> On Mar 24, 2017, at 10:59 AM, Tyler Stromberg via swift-dev
> wrote:
>
> I'm currently working on integrating SourceKit with a macOS application.
> AppKit APIs (e.g. NSAttributedString, NSLayoutManager, etc) deal in terms of
> NSRange (UTF-16 code units?). SourceKit, however, deals in terms
I ended up writing some convenience APIs to perform these conversions along
with many other useful SourceKit<->Cocoa conversions like line+column,
UTF-8, UTF-16 and String.Index in SourceKitten. It's MIT-licensed so feel
free to grab the String extensions from the project yourself:
https://github.c
