Re: [swift-dev] Transition to the Swift Forums -- mailing lists going into suspend mode

[Nicole Jacque via swift-dev]

Whoops, that’s swift-infrastruct...@swift.org 
.

> On Jan 17, 2018, at 6:07 PM, Nicole Jacque  wrote:
> 
> Hi All-
> 
> We’re about to start the transition to our new Swift forums and I’ll be 
> setting the mailing lists to suspend mode shortly so we can export/import the 
> mailing list data.  When the forums are open for business (ETA: sometime on 
> Friday) I’ll update the swift.org website and send out one last email to the 
> mailing lists (before retiring them for good) to let you know.  If there are 
> any unexpected delays, I’ll communicate that via the lists as well.  In the 
> meantime, you can still communicate with me and the rest of the Swift 
> infrastructure team if necessary at infrastruct...@swift.org.
> 
> Cheers!
> nicole

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-lldb-dev] Transition to the Swift Forums -- mailing lists going into suspend mode

[Nicole Jacque via swift-lldb-dev]

Whoops, that’s swift-infrastruct...@swift.org 
.

> On Jan 17, 2018, at 6:07 PM, Nicole Jacque  wrote:
> 
> Hi All-
> 
> We’re about to start the transition to our new Swift forums and I’ll be 
> setting the mailing lists to suspend mode shortly so we can export/import the 
> mailing list data.  When the forums are open for business (ETA: sometime on 
> Friday) I’ll update the swift.org website and send out one last email to the 
> mailing lists (before retiring them for good) to let you know.  If there are 
> any unexpected delays, I’ll communicate that via the lists as well.  In the 
> meantime, you can still communicate with me and the rest of the Swift 
> infrastructure team if necessary at infrastruct...@swift.org.
> 
> Cheers!
> nicole

___
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev

Re: [swift-corelibs-dev] Transition to the Swift Forums -- mailing lists going into suspend mode

[Nicole Jacque via swift-corelibs-dev]

Whoops, that’s swift-infrastruct...@swift.org 
.

> On Jan 17, 2018, at 6:07 PM, Nicole Jacque  wrote:
> 
> Hi All-
> 
> We’re about to start the transition to our new Swift forums and I’ll be 
> setting the mailing lists to suspend mode shortly so we can export/import the 
> mailing list data.  When the forums are open for business (ETA: sometime on 
> Friday) I’ll update the swift.org website and send out one last email to the 
> mailing lists (before retiring them for good) to let you know.  If there are 
> any unexpected delays, I’ll communicate that via the lists as well.  In the 
> meantime, you can still communicate with me and the rest of the Swift 
> infrastructure team if necessary at infrastruct...@swift.org.
> 
> Cheers!
> nicole

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-dev] Transition to the Swift Forums -- mailing lists going into suspend mode

[Nicole Jacque via swift-dev]

Hi All-

We’re about to start the transition to our new Swift forums and I’ll be setting 
the mailing lists to suspend mode shortly so we can export/import the mailing 
list data.  When the forums are open for business (ETA: sometime on Friday) 
I’ll update the swift.org website and send out one last email to the mailing 
lists (before retiring them for good) to let you know.  If there are any 
unexpected delays, I’ll communicate that via the lists as well.  In the 
meantime, you can still communicate with me and the rest of the Swift 
infrastructure team if necessary at infrastruct...@swift.org.

Cheers!
nicole
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-corelibs-dev] Transition to the Swift Forums -- mailing lists going into suspend mode

[Nicole Jacque via swift-corelibs-dev]

Hi All-

We’re about to start the transition to our new Swift forums and I’ll be setting 
the mailing lists to suspend mode shortly so we can export/import the mailing 
list data.  When the forums are open for business (ETA: sometime on Friday) 
I’ll update the swift.org website and send out one last email to the mailing 
lists (before retiring them for good) to let you know.  If there are any 
unexpected delays, I’ll communicate that via the lists as well.  In the 
meantime, you can still communicate with me and the rest of the Swift 
infrastructure team if necessary at infrastruct...@swift.org.

Cheers!
nicole
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - LLDB Incremental - OS X (master-llvm-swift5-transition) #61

[Mishal Shah via swift-dev]

Thanks!
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - LLDB Incremental - OS X (master-llvm-swift5-transition) #61

[Vedant Kumar via swift-dev]

This didn't send to the list because the quoted section of the email was too 
long. Once again;

I cherry-picked Slava's fix for the failures listed here:

a5243443d (HEAD -> llvm-swift5-transition, origin/llvm-swift5-transition) Merge 
pull request #275 from slavapestov/fix-inout-reconstruction-4.1

vedant
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] [Call for testing] Catching debug info violations at -Onone

[Davide Italiano via swift-dev]

Hi,
I would like to discuss the path towards enabling a new debug info verifier 
pass by default.
This should improve the debug experience of users at `-Onone`.

## Problem Description
Mandatory passes which run at `-Onone` can attach a wrong scope when they 
create instructions.
This may result in wrong debug informations generated and degraded debugger 
experience.

Examples of bugs of this kind recently fixed:
https://github.com/apple/swift/pull/13919 

https://github.com/apple/swift/pull/13890 

https://github.com/apple/swift/pull/13856 

https://github.com/apple/swift/pull/13854 



## Proposed solution

There’s currently nothing preventing compiler writers to attach the wrong 
scope, so, I’m going to check in a verifier pass to find holes in SIL debug 
scopes at -Onone. 
Reference: https://github.com/apple/swift/pull/13491 
 , which contains the code and a 
description of the heuristic used.

## Plan to enable this by default

I fixed all the bugs that have been found on the testsuite, but this seems to 
find still issues on larger projects (most notably, swiftpm), so for now this 
is disabled (but can be enabled using a flag [-Xllvm -verify-di-holes]). I’m 
working to 

I would really appreciate if the community can test their swift projects with 
this flag enabled and report bugs.
I would also appreciate general feedback on the path forward.

Thanks,

—
Davide___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.04 (master) #2618

[Mishal Shah via swift-dev]

Test Case 'RepositoryManagerTests.testBasics' started at 2018-01-17 22:36:16.208
 
<>/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swiftpm/Tests/SourceControlTests/RepositoryManagerTests.swift:199:
 error: RepositoryManagerTests.testBasics : Asynchronous wait failed - Exceeded 
timeout of 1.0 seconds, with unfulfilled expectations: Repository lookup 
expectation
Test Case 'RepositoryManagerTests.testBasics' failed (8.365 seconds)

Thanks,
Mishal Shah

> On Jan 17, 2018, at 2:36 PM, swift...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#2618]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/2618/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Wed, 17 Jan 2018 16:05:33 -0600
> Build duration:   31 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 10190 test(s), Total: 10190 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 507 test(s), Total: 507 test(s)
> 
> Changes
> 
> Commit be6d83ce74856665b6997bd0368acfce0eaec1f8 by mark.lacey:
> Restore ImplicitlyUnwrappedOptional extension conforming to
> 
> edit: stdlib/public/core/ImplicitlyUnwrappedOptional.swift
> 
> Commit c773493961580dd6cd35f17bdb2d40e309fb992b by mark.lacey:
> Revert "IUO: Update protocol conformance checking to check IUO attr on
> 
> edit: lib/Sema/TypeCheckProtocol.cpp
> 
> Commit 41056ae3a434608556a706e1c8f201fc625e53d6 by mark.lacey:
> Add runtime tests for bridging optionals and IUOs.
> 
> add: test/Interpreter/dynamic_cast_optionals_to_nsobject.swift
> 
> Commit 663d6af063cfd6d7d44cc2f42c53dfcd57fa17c9 by dgregor:
> [ABI] Factor out the protocol conformance flags (again).
> 
> edit: lib/IRGen/GenDecl.cpp
> edit: include/swift/Runtime/Metadata.h
> edit: stdlib/public/runtime/ProtocolConformance.cpp
> edit: lib/AST/ProtocolConformance.cpp
> edit: include/swift/ABI/MetadataValues.h
> edit: include/swift/AST/ProtocolConformance.h
> edit: test/IRGen/protocol_conformance_records_objc.swift
> edit: test/IRGen/protocol_conformance_records.swift
> 
> Commit bc866086d903aebd089af9f2a21558e6558c2b7a by dgregor:
> [Mangling] Add a mangling for protocol conformance descriptors.
> 
> edit: docs/ABI/Mangling.rst
> edit: lib/Demangling/Remangler.cpp
> edit: lib/Demangling/Demangler.cpp
> edit: lib/Demangling/OldRemangler.cpp
> edit: lib/Demangling/NodePrinter.cpp
> edit: include/swift/IRGen/Linking.h
> edit: include/swift/Demangling/DemangleNodes.def
> edit: lib/IRGen/GenDecl.cpp
> edit: lib/IRGen/IRGenMangler.h
> edit: lib/IRGen/Linking.cpp
> edit: test/Demangle/Inputs/manglings.txt
> 
> Commit e766473ed93c01c62dc633b5a8ac2c040f1b6683 by dgregor:
> [ABI] Emit separate symbols for protocol conformance descriptors.
> 
> edit: lib/IRGen/GenProto.cpp
> edit: test/IRGen/protocol_conformance_records_objc.swift
> edit: include/swift/Runtime/RuntimeFunctions.def
> edit: lib/TBDGen/TBDGen.cpp
> edit: lib/IRGen/GenDecl.cpp
> edit: include/swift/Runtime/Metadata.h
> edit: test/IRGen/objc_bridged_generic_conformance.swift
> edit: lib/IRGen/IRGenModule.h
> edit: stdlib/public/runtime/ProtocolConformance.cpp
> edit: lib/IRGen/IRGenModule.cpp
> edit: test/IRGen/protocol_conformance_records.swift
> 
> Commit 1d99aac77447c644f54c06ff70df284ab7b18d2f by dgregor:
> Update IRGen test for ELF
> 
> edit: test/IRGen/protocol_conformance_records.swift

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] String comparison improvements

[Itai Ferber via swift-dev]

Hi Lance (and Michael — I’ll keep the conversation in one thread),

Sounds reasonable. My one concern is that behavior around implicitly 
bridged strings is going to change, in a potentially problematic and 
"magic" way:


```swift
let s1: String = …
let s2: String = …

let mySet = NSMutableSet()
mySet.add(s1)
mySet.add(s2)

// s1 != s2 by Swift ordering rules, but CFStringCompare(s1, s2, …) == 
kCFCompareEqualTo

print(mySet.count) // => 1 
```

or alternatively:

```swift
let s1: String = …
let s2: String = …

let mySet = NSMutableSet()
mySet.add(s1)

// s1 == s2 by Swift ordering rules, but CFStringCompare(s1, s2, …) != 
kCFCompareEqualTo

print(mySet.contains(s2)) // => false 
```

I don’t think there’s much we can do about this, but this is 
something we’re going to have to watch out for — this will be a 
relatively rare and very subtle behavior change.


— Itai

On 17 Jan 2018, at 13:56, Lance Parker wrote:


Comments inline below


On Jan 17, 2018, at 1:46 PM, Itai Ferber  wrote:

Hi Lance,

I read Michael’s emails but I don’t remember at the moment — 
what is the new string comparison implementation going to be based 
on?


The new approach uses the lexicographical ordering of NFC-normalized 
UTF-16 code units. For two known ASCII strings, we just use memcmp.
Also, how will this affect bridged strings? If I compare two 
NSStrings, I may get a different result than if I compare the same 
two strings as bridged through String, correct?


If I understand correctly, you’re asking what will happen if you 
have two strings explicitly typed as NSString in swift and you compare 
them. I believe they’ll still use whatever NSString does for 
comparison today, so CFStringCompare. For Swift strings backed by a 
bridged NSString, this new comparison method will be used.


It might make sense for explicit NSStrings in Swift to use the new 
method as well. What do you think?

— Itai

On 17 Jan 2018, at 13:19, Lance Parker via swift-dev wrote:

Hey Swift-Dev,

The swift standard library team  have been working on a new 
implementation for comparing Swift strings for Swift 5. Michael 
touched on the motivations in the State of String email but I’ll 
summarize here:


The Swift String comparison implementations on Apple platforms and 
Linux differ in results and performance. Apple platforms use 
CFStringCompare with no locale, while Linux uses ICU libraries. 
Unifying the algorithms that Swift strings use for comparison is 
reason alone for doing a new implementation.
We've come up with some great common fast paths that speed up 
comparisons for a lot of common cases. Our microbenchmarks show up to 
a 6.8x increase in performance and there is still some low hanging 
fruit in our implementation that would bring further speedups.


Bare in mind this is not intended to be a replacement for sorting 
strings that will be presented to users, for that developers should 
stick to NSLocalizedString APIs.

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev 




___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] String comparison improvements

[Michael Ilseman via swift-dev]

> On Jan 17, 2018, at 1:46 PM, Itai Ferber via swift-dev  
> wrote:
> 
> Hi Lance,
> 
> I read Michael’s emails but I don’t remember at the moment — what is the new 
> string comparison implementation going to be based on?
> 

It is the lexicographical ordering of NFC-normalized UTF-16 code units. We use 
ICU to normalize strings, and there are a number of fast paths for scenarios 
where portions of strings are already in this canonical form.

> Also, how will this affect bridged strings? If I compare two NSStrings, I may 
> get a different result than if I compare the same two strings as bridged 
> through String, correct?
> 

If they have type String (i.e. they were bridged), they will get the new 
ordering semantics. I’m not familiar with how the type NSString is ordered in 
corelibs-foundation, do you know? Either way, as a different type, NSString 
could independently choose different ordering semantics.

> — Itai
> 
> On 17 Jan 2018, at 13:19, Lance Parker via swift-dev wrote:
> 
> Hey Swift-Dev,
> 
> The swift standard library team  have been working on a new implementation 
> for comparing Swift strings for Swift 5. Michael touched on the motivations 
> in the State of String email but I’ll summarize here:
> 
> The Swift String comparison implementations on Apple platforms and Linux 
> differ in results and performance. Apple platforms use CFStringCompare with 
> no locale, while Linux uses ICU libraries. Unifying the algorithms that Swift 
> strings use for comparison is reason alone for doing a new implementation. 
> We've come up with some great common fast paths that speed up comparisons for 
> a lot of common cases. Our microbenchmarks show up to a 6.8x increase in 
> performance and there is still some low hanging fruit in our implementation 
> that would bring further speedups. 
> 
> Bare in mind this is not intended to be a replacement for sorting strings 
> that will be presented to users, for that developers should stick to 
> NSLocalizedString APIs. 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Testing, validation, and many-core machines

[David Zarzycki via swift-dev]

> On Jan 17, 2018, at 16:06, Michael Gottesman  wrote:
> 
> 
> 
>> On Jan 17, 2018, at 8:23 AM, David Zarzycki via swift-dev 
>>  wrote:
>> 
>> Hello,
>> 
>> In docs/Testing.md, “long test” is acknowledged but never defined. When 
>> should tests be marked “long_test”? I’m asking because there are arguably a 
>> number of latent long_test tests that are exposed on many-core machines.
> 
> I think about it this way. A long test is a test that we want to run, but 
> would bog down PR testing or are enough of a validation test that the 
> trade-off in between signal/PR testing delays is found to be lacking. That 
> being said I think of it as an approximation.

Hi Michael,

How should an open source developer that doesn’t know much about the PR 
machinery decide when to use “long_test”?

> 
>> 
>> Speaking of many-core machines, there really isn’t a practical difference 
>> between smoke/primary testing and secondary/validation testing. Both test 
>> suites rush through 95-99% of the tests in very short order, and then wait a 
>> relatively long time for the remaining tests to finish. Can we move some of 
>> the exhaustive/stress tests in the “primary” suite to the validation suite? 
>> Likewise, can we move some of the short/functional tests in the validation 
>> directory to the primary test directory? That would match people’s 
>> expectations better, would it not?
> 
> Do you have specific test? Again, it isn't just about test time. It is about 
> the trade-off in between signal and length of time.

Right. I’m proposing that we improve the signal ratio by:

1) Moving blatant stress tests to validation. I’d start with these “maybe catch 
a race, maybe not” stress tests:

test/Runtime/weak-reference-racetests.swift
test/SILOptimizer/string_switch.swift
test/Sanitizers/tsan-ignores-arc-locks.swift
test/Sanitizers/tsan-type-metadata.swift
test/Sanitizers/witness_table_lookup.swift
test/stdlib/Inputs/CommandLineStressTest/CommandLineStressTest.swift

2) Move fast tests that live in validation-test into test. These tend to be 
“compiler crash” regression tests, which arguably fill in holes in the 
functional test suite until proper errors can be emitted.

Ideally after this swap, “build-script -t” should take the same amount of time 
but test more stuff.

Dave
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] String comparison improvements

[Lance Parker via swift-dev]

Comments inline below

> On Jan 17, 2018, at 1:46 PM, Itai Ferber  wrote:
> 
> Hi Lance,
> 
> I read Michael’s emails but I don’t remember at the moment — what is the new 
> string comparison implementation going to be based on?
> 
The new approach uses the lexicographical ordering of NFC-normalized UTF-16 
code units. For two known ASCII strings, we just use memcmp.
> Also, how will this affect bridged strings? If I compare two NSStrings, I may 
> get a different result than if I compare the same two strings as bridged 
> through String, correct?
> 
If I understand correctly, you’re asking what will happen if you have two 
strings explicitly typed as NSString in swift and you compare them. I believe 
they’ll still use whatever NSString does for comparison today, so 
CFStringCompare. For Swift strings backed by a bridged NSString, this new 
comparison method will be used. 

It might make sense for explicit NSStrings in Swift to use the new method as 
well. What do you think?
> — Itai
> 
> On 17 Jan 2018, at 13:19, Lance Parker via swift-dev wrote:
> 
> Hey Swift-Dev,
> 
> The swift standard library team  have been working on a new implementation 
> for comparing Swift strings for Swift 5. Michael touched on the motivations 
> in the State of String email but I’ll summarize here:
> 
> The Swift String comparison implementations on Apple platforms and Linux 
> differ in results and performance. Apple platforms use CFStringCompare with 
> no locale, while Linux uses ICU libraries. Unifying the algorithms that Swift 
> strings use for comparison is reason alone for doing a new implementation. 
> We've come up with some great common fast paths that speed up comparisons for 
> a lot of common cases. Our microbenchmarks show up to a 6.8x increase in 
> performance and there is still some low hanging fruit in our implementation 
> that would bring further speedups. 
> 
> Bare in mind this is not intended to be a replacement for sorting strings 
> that will be presented to users, for that developers should stick to 
> NSLocalizedString APIs. 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] String comparison improvements

[Itai Ferber via swift-dev]

Hi Lance,

I read Michael’s emails but I don’t remember at the moment — what 
is the new string comparison implementation going to be based on?
Also, how will this affect bridged strings? If I compare two 
`NSString`s, I may get a different result than if I compare the same two 
strings as bridged through `String`, correct?


— Itai

On 17 Jan 2018, at 13:19, Lance Parker via swift-dev wrote:


Hey Swift-Dev,

The swift standard library team  have been working on a new 
implementation for comparing Swift strings for Swift 5. Michael 
touched on the motivations in the State of String email but I’ll 
summarize here:


The Swift String comparison implementations on Apple platforms and 
Linux differ in results and performance. Apple platforms use 
CFStringCompare with no locale, while Linux uses ICU libraries. 
Unifying the algorithms that Swift strings use for comparison is 
reason alone for doing a new implementation.
We've come up with some great common fast paths that speed up 
comparisons for a lot of common cases. Our microbenchmarks show up to 
a 6.8x increase in performance and there is still some low hanging 
fruit in our implementation that would bring further speedups.


Bare in mind this is not intended to be a replacement for sorting 
strings that will be presented to users, for that developers should 
stick to NSLocalizedString APIs.




___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] String comparison improvements

[Lance Parker via swift-dev]

Hey Swift-Dev,

The swift standard library team  have been working on a new implementation for 
comparing Swift strings for Swift 5. Michael touched on the motivations in the 
State of String email but I’ll summarize here:

The Swift String comparison implementations on Apple platforms and Linux differ 
in results and performance. Apple platforms use CFStringCompare with no locale, 
while Linux uses ICU libraries. Unifying the algorithms that Swift strings use 
for comparison is reason alone for doing a new implementation. 
We've come up with some great common fast paths that speed up comparisons for a 
lot of common cases. Our microbenchmarks show up to a 6.8x increase in 
performance and there is still some low hanging fruit in our implementation 
that would bring further speedups. 

Bare in mind this is not intended to be a replacement for sorting strings that 
will be presented to users, for that developers should stick to 
NSLocalizedString APIs. ___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Testing, validation, and many-core machines

[Michael Gottesman via swift-dev]

> On Jan 17, 2018, at 8:23 AM, David Zarzycki via swift-dev 
>  wrote:
> 
> Hello,
> 
> In docs/Testing.md, “long test” is acknowledged but never defined. When 
> should tests be marked “long_test”? I’m asking because there are arguably a 
> number of latent long_test tests that are exposed on many-core machines.

I think about it this way. A long test is a test that we want to run, but would 
bog down PR testing or are enough of a validation test that the trade-off in 
between signal/PR testing delays is found to be lacking. That being said I 
think of it as an approximation.

> 
> Speaking of many-core machines, there really isn’t a practical difference 
> between smoke/primary testing and secondary/validation testing. Both test 
> suites rush through 95-99% of the tests in very short order, and then wait a 
> relatively long time for the remaining tests to finish. Can we move some of 
> the exhaustive/stress tests in the “primary” suite to the validation suite? 
> Likewise, can we move some of the short/functional tests in the validation 
> directory to the primary test directory? That would match people’s 
> expectations better, would it not?

Do you have specific test? Again, it isn't just about test time. It is about 
the trade-off in between signal and length of time.

> 
> Dave
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] State of String: ABI & Performance

[Michael Ilseman via swift-dev]

(Replying out-of-order)

> Sadly, I don’t. I’m only an opinionated hobbyist in this domain, one who has 
> coded a lot of string processing over the years and understands at least some 
> of the tradeoffs.


Wouldn’t it be amazing to be able to write a high performance lexer with all 
the awesomeness of Swift and without String getting in your way? :-)

> ^ String should NOT be an Any!

> Bridging is either “always eager” or “possibly lazy”, there is nothing 
> usefully in between.  Lazy bridging means that every operations down to the 
> lowly ascii parsing operations need to check for the slow path.  I understand 
> that this may not be possible to eliminate on apple platforms, but it would 
> be great to not add the existential generalization since that would affect 
> other platforms that don’t have the legacy api concern.


> Yes, StringRef style algorithms are a big deal, as I mentioned in my previous 
> email, but it is also unclear if this will really be a win when shoehorned 
> into String.  The benefit of StringRef is that it is a completely trivial 
> type (both in the SIL sense but also in the implementation sense) and all the 
> primitive ops get inlined.  Given the “all things to all people” design of 
> String, I’m very much afraid that trying to shoehorn this into the String 
> currency type will fail to provide significant wins and thus lead to having a 
> separate StringRef style type anyway.  Providing a StringRef style projection 
> type that is trivial (in the Swift sense) that knows in its static type that 
> it never owns memory seems like the best path.
> 
> By point of comparison, C++ has std::string (yes, sure, with lots of issues) 
> but they still introduced StringRef nee std::string_view instead of wedging 
> it in.

I left the “UnmangedString” section open for debate on SE, but for the purposes 
of talking about ABI design (i.e. what is possible to expose in the future), 
let’s just say we’ll eventually have an `UnsafeString`, which is a 
pointer, length, and packed performance flags that provides both a random 
access view of its code units as well as full-Unicode operations.

Please bear with me as I try to reason through what String should be 
incorporating the current reality of source compatibility. If you have any 
design insight or historical context to fill in, please do so!

In one extreme corner of this multi-dimensional design space we have a 
proliferation of string types such as UTF8String, UTF16String, and even 
combinations of performance flags such as TrivialUTF8String, 
CanonicalSingleScalarGraphemeSmallString, etc. This proliferation encodes all 
these would-be-dynamic-branches in the type, which is great for performance. 
But, this hits APIs hard, where APIs either accept total chaos by taking 
concrete types, or try to generalize/erase over these myriad types.

On the other extreme end is AnyString, an existential that can be backed by 
anything that can vend code units in some fashion. The advantage of such a type 
is API unification: no matter what form someone has, they can always call your 
API without copying the underlying data. The downside is that everyone’s in the 
same slow boat.

Somewhere between these two extremes will be String. The question is, what 
details does String treat as dynamic properties? Source compatibility dictates 
that String abstracts away the underlying encoding, branching inside every API 
that performs a read of its code units. There will always be 
performance-critical use cases that wish to avoid these branches, i.e. branch 
at the top rather than throughout. A more appropriate type is needed for this, 
such as UTF16String, UTF8String, and UnsafeString. Treating encoding 
as a dynamic property is great for APIs, as it avoids an encoding schism.

If we do small string optimizations for the String type, then every String 
could either be small (a value) or large (a reference). Every use of large 
strings will be slightly penalized. To a very small extent, even performance 
flags slightly penalizes strings that doesn’t set them. These are worth doing 
nonetheless as the benefit is so large when they apply and the penalty is 
paltry relative to cost of the operations in this slow path.

(...continued after quote)

> Right.  It is actually a bit more complicated than that though.  Consider the 
> Swift 4 generation of strings and arrays: because of lazy bridging each 
> primitive operation includes the dynamic branching sequence.  Beyond the 
> dynamic performance impact of this, we end up having a really unfortunate set 
> of tradeoffs to choose between:
> 
> 1. We can leave the operations outlined in the standard library.  
> Particularly for Array which benefits from being specialized on its element 
> type, this is a huge perf loss.
> 
> 2. We can inline the operation, but we end up inlining both sides of the 
> operation, causing massive code bloat.
> 
> 3. We can partially inline just the presumed fastpath, and leave 

Re: [swift-dev] State of String: Ergonomics, and You!

[Chris Lattner via swift-dev]

> On Jan 13, 2018, at 10:30 AM, Michael Ilseman via swift-dev 
>  wrote:
>>  I wouldn’t overly rely on it for guidance on these issues give that it it 
>> stuck so squarely in the realm of UTF16.
>> 
> 
> Wading a little into the weeds here, CharacterSet’s builtins model older 
> Unicode semantics than what we probably want to provide. E.g. 
> CharacterSet.lowercaseLetters means general category “Ll”, while modern 
> Unicode defines property Lowercase which includes more scalars. The Lowercase 
> property vs CharacterSet.lowercaseLetters is equivalent to ICU’s 
> u_isULowercase [1] vs u_islower [2], where the former is the modern 
> recommended API. Contrarily, Perl 6’s  built-in rule[3] seems to also 
> just be “Ll” and I’m not familiar with the rationale there (compatibility?). 
> Certainly needs investigation.

Makes sense.  It would be great to standardize towards the grapheme cluster as 
the canonical concept of character (this is why Character is defined that way) 
and by pushing regex’s to use that definition of character, we can simplify and 
reduce aggregate complexity.  This is a definition that “just works” most 
often, and the introduction of regex’s will eliminate all of the awkardness of 
having to use them - by eliminating some of the most common reasons that people 
want to use integer indexes into strings.

> I supposed by “guidance” I meant “here are some of the things people commonly 
> ask about characters”. Built-in character classes in various regex flavors 
> also provide guidance.
> 
> [1] u_isULowercase: 
> http://icu-project.org/apiref/icu4c/uchar_8h.html#a8321c9ba617ed00787f20c4b23a254bc
>  
> 
> [2] u_islower: 
> http://icu-project.org/apiref/icu4c/uchar_8h.html#aa26a51b768147fbf34029f8141132815
>  
> 
> [3] 
> https://docs.perl6.org/language/regexes#Backslashed,_predefined_character_classes
>  
> 
One of the frustrating things about the regex state of the art is that most 
engines were built pre-modern-unicode-complexity.  As you say, it is surprising 
that Perl6 didn’t fix some of this, but it could either be because of 
compatibility or (more likely) that they made many of these decisions 15 years 
ago when Perl 6 was just getting going.  Perl 6 had a long gestation period.

>>> Note: In no way would these properties obviate the need for CharacterSet, 
>>> as CharacterSet API is independently useful and the right model for many 
>>> whole-string operations.
>> 
>> No it isn’t.  A Grapheme-cluster based analog of CharacterSet would be a 
>> reasonable model to consider though.  It could conceptually support 
>> predicates like isEmoji()
>> 
> 
> In the regex section I talk about character classes as being modeled by 
> `(Character) -> Bool` rather than something that conforms to SetAlgebra. One 
> big reason (beyond being awesomely convenient) is because I don’t think 
> graphemes are something to be enumerated.

+1

> Theoretically speaking, I’m not sure if the set of graphemes is even 
> recursively enumerable (e.g. zalgo-text or zalgo-emoji). Practically 
> speaking, it darn-well might as well be uncountable. Best case, if even 
> possible, any enumeration would be emergent behavior of encoding details and 
> change significantly with each Unicode version. If we cannot enumerate 
> graphemes, we cannot answer equality, isDisjoint, isSubset, etc.

+2

> I don’t know if those operations are important for a grapheme analogue. They 
> just demonstrate that a grapheme set follows a different model than a scalar 
> set, and different than what we have traditionally used the word “Set” for in 
> Swift, though you would know the history here better.

+3.  I completely agree that a “set” in the computer sciency usage is no longer 
a useful notion any longer for characters.  It is still technically correct 
with the mathematical definition, but any alignment of terminology towards this 
will just be confusing to users.

> As far as uses of such a grapheme set are concerned, they seem equivalent to 
> application of a regex consisting of a character class. For example, 
> rangeOfCharacter(from:options:) could be accomplished with the below.

Yes, that’s a great way to consider it.  

> In an ever-futile attempt to avoid focusing on specific syntax, I’ll form an 
> army of straw-people, using 「」 delimiters for a regex literal, « » to denote 
> character classes, subscript on String to model application of a Regex, 
> parenthesis to denote a capture that must always be a decl (even if the name 
> is dropped by using `_`), and Regex literals defaulting to whole-string 
> matching rather than the first partial-string match:
> 
> extension Character {
> var isEmoji: Bool { get }
> }
> extension Regex {
> var 

Re: [swift-dev] Protocol Devirtualizer Pass

[Raj Barik via swift-dev]

I created a pull request for the protocol devirtualizer and the peephole
optimizer at https://github.com/apple/swift/pull/13991.

Really appreciate all the help from Arnold and Slava.

Here is an example of what the transformation achieves (in conjunction with
other existing passes of swift) :

*Input SIL*:

import Builtin
import Swift

internal protocol SomeProtocol : AnyObject {
  func increment() -> Int
}

internal class SomeClass : SomeProtocol {
  init()
  func increment() -> Int
}

sil @something : $@convention(thin) () -> Int {
bb0:
  %0 = alloc_ref $SomeClass
  %1 = init_existential_ref %0 : $SomeClass : $SomeClass, $SomeProtocol
  %2 = function_ref @something_to_devirtualize : $@convention(thin)
(@guaranteed SomeProtocol) -> Int
  %3 = apply %2(%1) : $@convention(thin) (@guaranteed SomeProtocol) -> Int
  return %3 : $Int
}

sil private [transparent] [thunk] @increment : $@convention(witness_method:
SomeProtocol) (@guaranteed SomeClass) -> Int {
bb0(%0 : $SomeClass):
  %1 = integer_literal $Builtin.Int64, 10
  %2 = struct $Int (%1 : $Builtin.Int64)
  return %2 : $Int
}

sil shared [noinline] @something_to_devirtualize : $@convention(thin)
(@guaranteed SomeProtocol) -> Int {
bb0(%0 : $SomeProtocol):
  %2 = open_existential_ref %0 : $SomeProtocol to
$@opened("D346AB00-F998-11E7-93AE-DCA9048B1C6D") SomeProtocol
  %3 = witness_method $@opened("D346AB00-F998-11E7-93AE-DCA9048B1C6D")
SomeProtocol, #SomeProtocol.increment!1 : 
(Self) -> () -> Int, %2 : $@opened("D346AB00-F998-11E7-93AE-DCA9048B1C6D")
SomeProtocol : $@convention(witness_method: SomeProtocol) <τ_0_0 where
τ_0_0 : SomeProtocol> (@guaranteed τ_0_0) -> Int
  %4 = apply %3<@opened("D346AB00-F998-11E7-93AE-DCA9048B1C6D")
SomeProtocol>(%2) : $@convention(witness_method: SomeProtocol) <τ_0_0 where
τ_0_0 : SomeProtocol> (@guaranteed τ_0_0) -> Int
  return %4 : $Int
}

sil_witness_table hidden SomeClass: SomeProtocol module test {
  method #SomeProtocol.increment!1:  (Self)
-> () -> Int : @increment
}

*Output SIL after running "sil-opt -wmo
-assume-parsing-unqualified-ownership-sil -protocol-devirtualizer -inline
-sil-combine -generic-specializer -devirtualizer -late-inline
-dead-arg-signature-opt -dce -sil-deadfuncelim"*

import Builtin
import Swift
import SwiftShims

internal protocol SomeProtocol : AnyObject {
  func increment() -> Int
}

internal class SomeClass : SomeProtocol {
  init()
  func increment() -> Int
  deinit
}

// something
sil @something : $@convention(thin) () -> Int {
bb0:
  %0 = alloc_ref $SomeClass   // user: %2
  %1 = function_ref
@$S25something_to_devirtualizeTf5n_n4main9SomeClassC_Tg5 :
$@convention(thin) (@guaranteed SomeClass) -> Int // user: %2
  %2 = apply %1(%0) : $@convention(thin) (@guaranteed SomeClass) -> Int //
user: %3
  return %2 : $Int// id: %3
} // end sil function 'something'

// specialized something_to_devirtualize
sil shared [noinline]
@$S25something_to_devirtualizeTf5n_n4main9SomeClassC_Tg5 :
$@convention(thin) (@guaranteed SomeClass) -> Int {
bb0(%0 : $SomeClass):
  %1 = integer_literal $Builtin.Int64, 10 // user: %2
  %2 = struct $Int (%1 : $Builtin.Int64)  // user: %3
  return %2 : $Int// id: %3
} // end sil function
'$S25something_to_devirtualizeTf5n_n4main9SomeClassC_Tg5'

sil_witness_table hidden_external SomeClass: SomeProtocol module main {
  method #SomeProtocol.increment!1:  (Self)
-> () -> Int : nil
}




On Thu, Dec 21, 2017 at 2:50 PM, Raj Barik  wrote:

> Sure, I can :)
>
> On Thu, Dec 21, 2017 at 12:24 PM, Michael Gottesman 
> wrote:
>
>> Is it possible to merge them?
>>
>> > On Dec 21, 2017, at 11:07 AM, Raj Barik via swift-dev <
>> swift-dev@swift.org> wrote:
>> >
>> > Hi,
>> >
>> > Thanks.
>> >
>> >
>> > Are you implementing it as a separate pass, or is it part of function
>> signature specialization?
>> >
>> >
>> > I am currently implementing this as a separate pass. There is some code
>> overlap between the two (FunctionSignatureOpt and ProtocolDevirtualizerOpt)
>> in terms of checking which functions can be optimized. Barring that, the
>> code is quite different even though they follow the same pattern (thunk and
>> a separate function).
>> >
>> > --Raj
>> >
>> >
>> >
>> > Slava
>> >
>> >>
>> >> @inline(never) internal func wrap_inc_optional(a:SumProtocol?,
>> val:Int) -> Int?{
>> >>  return a?.increment(i:val)
>> >> }
>> >>
>> >> The generated SIL looks something like this:
>> >>
>> >> sil hidden [noinline] @_T04main21wrap_inc_optionalSi
>> SgAA11SumProtocol_pSg1a_Si3valtF : $@convention(thin) (@owned
>> Optional, Int) -> Optional {
>> 

Re: [swift-dev] Suggestions for open projects (GSoC 2018)

[Anna Zaks via swift-dev]

Hi Everyone,

If you have an idea or are interested in mentoring, send it in now!

Thanks,
Anna

> On Jan 8, 2018, at 5:17 PM, Anna Zaks  wrote:
> 
> Dear Swift Developers,
> 
> The Swift project is applying to participate in Google Summer of Code 2018. 
> During GSoC, students get a mentor from the open source community and spend 3 
> months working on a project.
> 
> In preparation for the application, I am looking for open project ideas as 
> well as mentors. Once I have the list, I’ll post it on the project website. 
> The prospective GSoC students as well as any other new contributors will be 
> able to use it as a source of inspiration. 
> 
> If you have a project idea and/or would like to volunteer as a mentor, please 
> send me the following information by January 15th:
> The project title/description
> A more detailed description of the project (2-5 sentences)
> Expected outcomes of the project or benefits it brings
> Possible mentors
> An easy, medium, or hard rating
> Thank you!
> Anna
> 
> P.S.
> This website has more information about how to construct the project ideas 
> list for GSoC:
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list 
> 
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] Testing, validation, and many-core machines

[David Zarzycki via swift-dev]

Hello,

In docs/Testing.md, “long test” is acknowledged but never defined. When should 
tests be marked “long_test”? I’m asking because there are arguably a number of 
latent long_test tests that are exposed on many-core machines.

Speaking of many-core machines, there really isn’t a practical difference 
between smoke/primary testing and secondary/validation testing. Both test 
suites rush through 95-99% of the tests in very short order, and then wait a 
relatively long time for the remaining tests to finish. Can we move some of the 
exhaustive/stress tests in the “primary” suite to the validation suite? 
Likewise, can we move some of the short/functional tests in the validation 
directory to the primary test directory? That would match people’s expectations 
better, would it not?

Dave
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev