Add Grapheme Breaking and Normalization #146
Conversation
| .target( | ||
| name: "_StringProcessing", | ||
| dependencies: ["_MatchingEngine"], | ||
| dependencies: ["_MatchingEngine", "_CUnicode"], |
There was a problem hiding this comment.
Hmm I don't think we can add arbitrary dependencies for _MatchingEngine or _StringProcessing until we 1) set up cmake on the compiler side to produce the _CUnicode module and 2) coordinate with @edymtt for internal builds.
There was a problem hiding this comment.
Is there any way to avoid _CUnicode?
There was a problem hiding this comment.
Maybe you can build the C files as part of _StringProcessing via CMake? But I’m not sure how you can do that using SwiftPM.
There was a problem hiding this comment.
I don't see any reason why the two build systems have to work the same way. If we need to include these directly in the CMake build for now, let's do that.
| @@ -33,13 +33,13 @@ | |||
|
|
|||
| enum UnsafeAssumingValidUTF8 { | |||
| @inlinable @inline(__always) | |||
| public func decode(_ x: UInt8) -> Unicode.Scalar { | |||
| public static func decode(_ x: UInt8) -> Unicode.Scalar { | |||
There was a problem hiding this comment.
Part of moving these into the _StringProcessing module should be dropping all public keywords, since _StringProcessing will be supplying API as well.
Azoy
force-pushed
the
we-have-the-data
branch
2 times, most recently
from
6a0be4c to
3590876
Compare
Add Grapheme Breaking and Normalization make it compatible with how the compiler will build it
Azoy
force-pushed
the
we-have-the-data
branch
from
3590876 to
f5f6829
Compare
|
@swift-ci please test Linux |
This adds the Unicode data needed and the stdlib implementations of grapheme breaking and normalization for use in _StringProcessing.