Re: [swift-dev] Default implementations from protocols and ABI stability

[Jordan Rose via swift-dev]

You’re “safe" here: in a library with resilience enabled, protocol extension 
methods are not emitted into the client unless they’re marked @inlinable (or 
however that ends up being spelled when we’re done with SE-0193).

That said, you can’t be sure someone didn’t just implement their own 
‘contrive()' if you put it in the protocol; if you want to defend against that 
you’d have to not put it in the protocol (and just provide the extension method 
for convenience).

Since you mentioned Collection and the standard library, I’ll also point out 
that the stdlib team is planning to make a lot of these methods inlinable, 
since they can benefit a lot from specialization (and just normal inlining, 
especially the ones with callbacks). That doesn’t preclude changing the 
implementation later, but both implementations may end up being used at run 
time. Still, this seems totally fine for something like ‘reduce’ that’s a pure 
function.

Jordan


> On Jan 11, 2018, at 10:25, Philippe Hausler via swift-dev 
>  wrote:
> 
> Given the tentative ideas already being worked on for ABI stability what 
> would be the place that code associated with a default implementation of a 
> method on a protocol live?
> 
> e.g.
> 
> FooKit has some code that is similar to this:
> 
> public struct SomeOptions : RawRepresentable {
> public private(set) var rawValue: Int
> public init(rawValue: Int) { self.rawValue = rawValue }
> 
> public static let sensible = SomeOptions(rawValue: 1 << 0)
> public static let maybeWillBeBetterLater = SomeOptions(rawValue: 1 << 1)
> }
> 
> public protocol Somethingable {
> func contrive()
> func contrive(options: SomeOptions)
> }
> 
> extension Somethingable {
> func contrive() { contrive(options: .sensible) }
> }
> 
> Then later on in a newer version of FooKit maybeWillBeBetterLater is now MUCH 
> better and should be the default option so the code is updated to look like 
> this:
> 
> public struct SomeOptions : RawRepresentable {
> public private(set) var rawValue: Int
> public init(rawValue: Int) { self.rawValue = rawValue }
> 
> public static let sensible = SomeOptions(rawValue: 1 << 0)
> public static let maybeWillBeBetterLater = SomeOptions(rawValue: 1 << 1)
> }
> 
> public protocol Somethingable {
> func contrive()
> func contrive(options: SomeOptions)
> }
> 
> extension Somethingable {
> func contrive() { contrive(options: .maybeWillBeBetterLater) }
> }
> 
> For apps compiled with FooKit when they are run with the new version of 
> FooKit do they get the behavior of sensible or maybeWillBeBetterLater? 
> 
> Basically this is a question of where will the code for protocol extensions 
> that are adopted across module boundaries live?
> 
> This interestingly applies to things like Collection and other standard 
> library protocols and has some potential drawbacks and benefits from either 
> way of it possibly working.
> 
> Thanks in advance for indulging my curiosity.
> Philippe
> ___
> 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] [swift-build-dev] "Swift 4.1 or Swift 3.3"

[Jordan Rose via swift-dev]

> On Jan 5, 2018, at 23:43, David Hart  wrote:
> 
> I was really surprised when I saw that the release of 4.0 introduced this 3.2 
> version to mean “the 4.0 compiler running in 3.1 compatibility mode”. So of 
> course, I’m even more surprised to see a new 3.3 version. I find it very 
> counter-intuitive. It also means we will continue to have to increment all 
> previous Swift language versions from now on whenever a new compiler is 
> released:
> 
> Swift 3.4 = Swift 5 compiler in Swift 3 compatibility mode
> Swift 4.2 = Swift 5 compiler in Swift 4 compatibility mode
> Swift 3.5 = Swift 5.1 compiler in Swift 3 compatibility mode
> Swift 4.3 = Swift 5.1 compiler in Swift 4 compatibility mode

The most common use of `#if swift` is `#if swift(>=4.0)`, to check for things 
that actually changed in Swift 4 and not in the 3 compatibility modes. I agree 
that the "subtraction" going on here is very weird, though, and of course it 
leads to this problem when you're actually trying to test the compiler release 
rather than the language mode.

(Your predictions are right, though, if nothing else here changes: 
https://github.com/apple/swift/pull/13767)


> I have the impression that what we really need is a different directive to 
> test for the compiler version:
> 
> #if compiler(>=4.1)
> // Swift 3.3
> // Swift 4.1
> #endif

That certainly seems reasonable. If that's the direction we want to go, the 
next question is whether it's important enough to put through swift-evolution 
in time for Swift 4.1, or whether it could wait for Swift 5. (I'd also love if 
someone else shepherded that proposal and implementation through. I could put 
it up as a StarterBug/StarterProposal.)

Jordan


> 
> On 6 Jan 2018, at 01:19, Jordan Rose via swift-build-dev 
> > wrote:
> 
>> Hi, all. Swift 4.1 is off on its own branch and going well, but we never 
>> quite came up with an answer for a particular problem developers might have: 
>> "am I running a Swift 4.1 compiler?".
>> 
>> #if swift(>=3.2)
>> // Swift 3.2 (4.0 in compatibility mode)
>> // Swift 3.3 (4.1 in compatibility mode)
>> // Swift 4.0
>> // Swift 4.1
>> #endif
>> 
>> #if swift(>=3.3)
>> // Swift 3.3 (4.1 compatibily mode)
>> // Swift 4.0
>> // Swift 4.1
>> // this one is probably not very useful
>> #endif
>> 
>> #if swift(>=4.0)
>> // Swift 4.0
>> // Swift 4.1
>> #endif
>> 
>> #if ???
>> // Swift 3.3
>> // Swift 4.1
>> #endif
>> 
>> I don't think this is going to come up a lot, but given that we do have 
>> changes to the standard library and to the language, I can see people 
>> wanting it. Right now the only way to do it is the rather unwieldy:
>> 
>> #if swift(>=4.1) || (swift(>=3.3) && !swift(>=4.0))
>> print("new")
>> #else
>> print("old")
>> #endif
>> 
>> Do we need something better here, or do you think people will be okay with 
>> this? I'm realizing I don't really know how many people try to keep their 
>> libraries working across Swift versions and run into compatibility issues. 
>> 
>> (Strictly speaking this problem is already present with Swift 4.0.2 with 
>> 3.2.2 compatibility mode, but that's much less likely to come up.)
>> 
>> Jordan
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-build-dev 
>> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [swift-build-dev] "Swift 4.1 or Swift 3.3"

[Jordan Rose via swift-dev]

Thanks for the info, Alan!

On `swift(<4.0)`: I think originally we were even more restrictive about how 
people used `#if swift`, not even allowing !, &&, and ||. Without those 
restrictions, allowing a `swift( and <= are 
very deliberately not included, because people always forget point releases.)

Jordan


> On Jan 5, 2018, at 17:22, Alan Zeino  wrote:
> 
> Hey Jordan,
> 
> We tend to have to do major migrations of our Swift codebase, so I might be 
> able to help. For context at last count (February 2017 was the last time I 
> checked) we had 1.4m lines of Swift across our apps.
> 
> This means that when we migrate, we tend to have to chose the smallest 
> possible scope for necessity reasons. For example when Swift 3.0 was 
> available, we went to 2.3 first and it took a few months before we were on 
> 3.0.
> 
> When 4.0 was available we went to 3.2 first (with many, many #if statements) 
> and it took a few months before we went to 4.0; which we did by landing many 
> months worth of #if statements to switch between 3.2/4.0 right up until the 
> 4.0 switch.
> 
> To answer the last question first, the larger the codebase the more likely 
> you will be to want to do your swift migrations piecemeal with many small 
> changes until you can build a fully–compatible–with–the–new–version 
> executable. 
> 
> This is even more important for open source libraries, who struggle with 
> either having entire forked branches for swift versions (which means fixes 
> sometimes have to be committed to more than one branch), or many #if 
> statements littered in their codebase.
> 
> As for this issue, the main improvement here would be to be able to use > and 
> < in these statements. The first time I had to do one of these large 
> migrations I found it more difficult to reason and read the cases where you 
> had to do this:
> 
> #if !swift(>=3.2)
> /* code */
> #endif
> 
> …when it would be a little easier to grok what’s happening if it were 
> possible to do this:
> 
> #if swift(<3.2)
> /* code */
> #endif
> 
> In your example, it could be a little simpler if the unary requirement here 
> was relaxed (though I’m sure there’s a good reason why it’s the way it is!).
> 
> If I’m reading this correctly (sorry if my interval notation is wrong it’s 
> been a while) the bounds here would be:
> 
> // n >= 4.1
> // or
> // 3.3 >= n < 4.0
> #if swift(>=4.1) || (swift(>=3.3) && !swift(>=4.0))
> print("asdf")
> #endif
> 
> But if it were possible to use > and <, it would read:
> 
> #if (swift(>=3.3) && swift(<4.0)) || swift(>=4.1)
> print("asdf")
> #endif
> 
> (I don’t know why Mail.app is making the < above look like a less than or 
> equal to symbol ≤)
> 
> I find it a little easier to read it this way, because the negation with ! 
> changes my thinking from ‘interval’ to ‘interval plus… not something in this 
> interval’.
> 
> Overall, while I think that most people here know that these compatibility 
> versions are really ‘the old code built with the latest compiler’, most tend 
> to ignore this fact so we try not to worry about it much and trust the 
> compiler a lot here to do the right thing. We also try to only support one 
> Xcode version at Uber at a time (and so one swift compiler toolchain), which 
> tends to narrow the scope of the ‘what version of Swift will this code 
> compile for’ question.
> 
> Hope this helps!
> 
> Alan
> 
> 
>> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-build-dev 
>> > wrote:
>> 
>> Hi, all. Swift 4.1 is off on its own branch and going well, but we never 
>> quite came up with an answer for a particular problem developers might have: 
>> "am I running a Swift 4.1 compiler?".
>> 
>> #if swift(>=3.2)
>> // Swift 3.2 (4.0 in compatibility mode)
>> // Swift 3.3 (4.1 in compatibility mode)
>> // Swift 4.0
>> // Swift 4.1
>> #endif
>> 
>> #if swift(>=3.3)
>> // Swift 3.3 (4.1 compatibily mode)
>> // Swift 4.0
>> // Swift 4.1
>> // this one is probably not very useful
>> #endif
>> 
>> #if swift(>=4.0)
>> // Swift 4.0
>> // Swift 4.1
>> #endif
>> 
>> #if ???
>> // Swift 3.3
>> // Swift 4.1
>> #endif
>> 
>> I don't think this is going to come up a lot, but given that we do have 
>> changes to the standard library and to the language, I can see people 
>> wanting it. Right now the only way to do it is the rather unwieldy:
>> 
>> #if swift(>=4.1) || (swift(>=3.3) && !swift(>=4.0))
>> print("new")
>> #else
>> print("old")
>> #endif
>> 
>> Do we need something better here, or do you think people will be okay with 
>> this? I'm realizing I don't really know how many people try to keep their 
>> libraries working across Swift versions and run into compatibility issues. 
>> 
>> (Strictly speaking this problem is already present with Swift 

[swift-dev] "Swift 4.1 or Swift 3.3"

[Jordan Rose via swift-dev]

Hi, all. Swift 4.1 is off on its own branch and going well, but we never quite 
came up with an answer for a particular problem developers might have: "am I 
running a Swift 4.1 compiler?".

#if swift(>=3.2)
// Swift 3.2 (4.0 in compatibility mode)
// Swift 3.3 (4.1 in compatibility mode)
// Swift 4.0
// Swift 4.1
#endif

#if swift(>=3.3)
// Swift 3.3 (4.1 compatibily mode)
// Swift 4.0
// Swift 4.1
// this one is probably not very useful
#endif

#if swift(>=4.0)
// Swift 4.0
// Swift 4.1
#endif

#if ???
// Swift 3.3
// Swift 4.1
#endif

I don't think this is going to come up a lot, but given that we do have changes 
to the standard library and to the language, I can see people wanting it. Right 
now the only way to do it is the rather unwieldy:

#if swift(>=4.1) || (swift(>=3.3) && !swift(>=4.0))
print("new")
#else
print("old")
#endif

Do we need something better here, or do you think people will be okay with 
this? I'm realizing I don't really know how many people try to keep their 
libraries working across Swift versions and run into compatibility issues. 

(Strictly speaking this problem is already present with Swift 4.0.2 with 3.2.2 
compatibility mode, but that's much less likely to come up.)

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

Re: [swift-dev] Conditional conformance: Removing the opt-in flag

[Jordan Rose via swift-dev]

> On Jan 2, 2018, at 11:29, Douglas Gregor via swift-dev  
> wrote:
> 
>> Just to be clear, what is the current impact of leaving those Codable 
>> conformances conditional? Having casts like [1,2,3] as? Codable fail?
>> 
> Right. Those casts, which would have succeeded in Swift 4, will fail (with a 
> runtime warning) in Swift 4.1.

Codable in particular doesn't have this problem because it has initializer 
requirements. Encodable on its own technically does, but nothing really works 
with Encodable on its own anyway because the whole system is optimized for 
round-tripping. If Codable is the only thing we we're worried about, it 
shouldn't stop us.

Jordan

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

Re: [swift-dev] Swift CI "auto retry"?

[Jordan Rose via swift-dev]

> On Dec 20, 2017, at 08:04, Arnold Schwaighofer via swift-dev 
>  wrote:
> 
> This is caused by clang change 1ac71826854a809f67ae15ddacaaa9a6eb8189e8.
> 
> This change was reverted on swift-4.1-branch. Merging clang's 
> swift-4.1-branch into stable is blocked by another error that we can also see 
> here: 
> https://ci.swift.org/job/swift-PR-osx/2060/consoleFull#-12191974833122a513-f36a-4c87-8ed7-cbc36a1ec144
> 
> FAILED: lib/swift/iphoneos/armv7s/libswiftXCTest.dylib 
> : && 
> /Users/buildnode/jenkins/workspace/swift-PR-osx/branch-master/buildbot_incremental/llvm-macosx-x86_64/./bin/clang++
>   -Wno-unknown-warning-option -Werror=unguarded-availability-new 
> -fno-stack-protector -stdlib=libc++ -fPIC -fvisibility-inlines-hidden 
> -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor 
> -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
> -Werror=switch -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code 
> -Woverloaded-virtual -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -fno-sanitize=all 
> -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 -O3 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>  -dynamiclib -Wl,-headerpad_max_install_names -stdlib=libc++   -target 
> armv7s-apple-ios7.0 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.2.sdk
>  -arch armv7s -F 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.2.sdk/../../../Developer/Library/Frameworks
>  -mios-version-min=8.0 
> -Wl,-sectcreate,__TEXT,__info_plist,/Users/buildnode/jenkins/workspace/swift-PR-osx/branch-master/buildbot_incremental/swift-macosx-x86_64/stdlib/public/SDK/XCTest/Info.plist
>   
> "-L/Users/buildnode/jenkins/workspace/swift-PR-osx/branch-master/buildbot_incremental/swift-macosx-x86_64/./lib/swift/iphoneos/armv7s"
>  "-L/Users/buildnode/jenkins/workspace/swi
> ft-PR-osx/branch-master/buildbot_incremental/swift-macosx-x86_64/./bin/../lib/swift/iphoneos/armv7s"
>  
> "-L/Users/buildnode/jenkins/workspace/swift-PR-osx/branch-master/buildbot_incremental/swift-macosx-x86_64/./bin/../lib/swift/iphoneos"
>  -o lib/swift/iphoneos/armv7s/libswiftXCTest.dylib -install_name 
> @rpath/libswiftXCTest.dylib stdlib/public/SDK/XCTest/iphoneos/armv7s/XCTest.o 
> stdlib/public/SDK/XCTest/CMakeFiles/swiftXCTest-iphoneos-armv7s.dir/XCTestCaseAdditions.mm.o
>  
> -L/Users/buildnode/jenkins/workspace/swift-PR-osx/branch-master/buildbot_incremental/llvm-macosx-x86_64/./lib
>  -framework Foundation -framework XCTest 
> lib/swift/iphoneos/armv7s/libswiftCoreMedia.dylib 
> lib/swift/iphoneos/armv7s/libswiftUIKit.dylib -framework CoreMedia -framework 
> UIKit lib/swift/iphoneos/armv7s/libswiftFoundation.dylib 
> lib/swift/iphoneos/armv7s/libswiftObjectiveC.dylib 
> lib/swift/iphoneos/armv7s/libswiftCore.dylib -framework Foundation -framework 
> CoreFoundation && :
> clang-5.0: warning: argument unused during compilation: 
> '-miphoneos-version-min=8.0' [-Wunused-command-line-argument]
> ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
> ld: embedded dylibs/frameworks are only supported on iOS 8.0 and later 
> (@rpath/XCTest.framework/XCTest) file 
> '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Frameworks/XCTest.framework/XCTest'
>  for architecture armv7s
> 
> clang-5.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)

That is the very error that was caused by the Clang change.

Jordan

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

Re: [swift-dev] Make offset index available for String

[Jordan Rose via swift-dev]

We really don't want to make subscripting a non-O(1) operation. That just 
provides false convenience and encourages people to do the wrong thing with 
Strings anyway.

I'm always interested in why people want this kind of ability. Yes, it's nice 
for teaching programming to be able to split strings on character boundaries 
indexed by integers, but where does it come up in real life? The most common 
cases I see are trying to strip off the first or last character, or a known 
prefix or suffix, and I feel like we should have better answers for those than 
"use integer indexes" anyway.

Jordan


> On Dec 13, 2017, at 22:30, Cao, Jiannan via swift-dev  
> wrote:
> 
> Hi,
> 
> I would like to discuss the String.Index problem within Swift. I know the 
> current situation of String.Index is based on the nature of the underlaying 
> data structure of the string.
> 
> But could we just make String.Index contain offset information? Or make 
> offset index subscript available for accessing character in String?
> 
> for example:
> let a = "01234"
> print(a[0]) // 0
> print(a[0...4]) // 01234
> print(a[...]) // 01234
> print(a[..<2]) // 01
> print(a[...2]) // 012
> print(a[2...]) // 234
> print(a[2...3]) // 23
> print(a[2...2]) // 2
> if let number = a.index(of: "1") {
> print(number) // 1
> print(a[number...]) // 1234
> }
> 
> 
> 0 equals to Collection.Index of collection.index(startIndex, offsetBy: 0)
> 1 equals to Collection.Index of collection.index(startIndex, offsetBy: 1)
> ...
> we keep the String.Index, but allow another kind of index, which is called 
> "offsetIndex" to access the String.Index and the character in the string.
> Any Collection could use the offset index to access their element, regarding 
> the real index of it.
> 
> I have make the Collection OffsetIndexable protocol available here, and make 
> it more accessible for StringProtocol considering all API related to the 
> index.
> 
> https://github.com/frogcjn/OffsetIndexableCollection-String-Int-Indexable- 
> 
> 
> If someone want to make the offset index/range available for any collection, 
> you just need to extend the collection:
> extension String : OffsetIndexableCollection {
> }
> 
> extension Substring : OffsetIndexableCollection {
> }
> 
> 
> I hope the Swift core team could consider bring the offset index to string, 
> or make it available to other collection, thus let developer to decide 
> whether their collection could use offset indices as an assistant for the 
> real index of the collection.
> 
> 
> Thanks!
> Jiannan
> 
> 
> ___
> 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] Switching swift to C++14

[Jordan Rose via swift-dev]

> On Dec 13, 2017, at 14:19, Saleem Abdulrasool  wrote:
> 
>> On Dec 13, 2017, at 1:45 PM, Jordan Rose  wrote:
>> 
>> No one else has commented on this yet today, so I'll put in that I don't 
>> have any objections to this and don't foresee any major problems. The one 
>> place where we'd need to be careful is with LLDB, which imports Swift 
>> headers; if Swift is going to move to C++14, then Swift-LLDB probably has to 
>> as well. LLDB folks, what do you think?
>> 
>> The other thing to check is if our minimum Clang or libstdc++ requirements 
>> on Linux didn't support C++14. It looks like our README is vague on that, 
>> but LLDB already suggests a minimum requirement of Clang 3.5, which is new 
>> enough. I suspect we're okay here.
> 
> The current Ubuntu LTS (16.04) has clang 4 which supports C++14.  libstdc++ 
> claims C++14 compliance in the 4.9 release.  That is available in Xenial 
> (16.04) as well.  So, I believe that the dependency issue should not be a 
> problem.

We're talking minimal requirements, not current versions. Otherwise this 
becomes a "should we drop support for X" thread, which is a different 
proposition.

Jordan

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

Re: [swift-dev] Switching swift to C++14

[Jordan Rose via swift-dev]

No one else has commented on this yet today, so I'll put in that I don't have 
any objections to this and don't foresee any major problems. The one place 
where we'd need to be careful is with LLDB, which imports Swift headers; if 
Swift is going to move to C++14, then Swift-LLDB probably has to as well. LLDB 
folks, what do you think?

The other thing to check is if our minimum Clang or libstdc++ requirements on 
Linux didn't support C++14. It looks like our README is vague on that, but LLDB 
already suggests a minimum requirement of Clang 3.5, which is new enough. I 
suspect we're okay here.

Jordan


> On Dec 13, 2017, at 10:36, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> Hi,
> 
> The newer Windows SDK requires the use of C++14 (the SDK headers use `auto` 
> return types without trailing type information).  Joe mentioned that there 
> was some interest in switching the rest of swift to C++14 as well.  I figured 
> that I would just start a thread here to determine if this is okay to do 
> globally rather than just specifically for the Windows builds to ensure that 
> we can build the Windows components.
> 
> Thanks.
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> ___
> 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] [SE-0143] Dynamic casting for conditional conformances

[Jordan Rose via swift-dev]

> On Dec 12, 2017, at 14:15, Douglas Gregor via swift-dev  
> wrote:
> 
> 
> 
>> On Dec 10, 2017, at 4:47 PM, Brent Royal-Gordon > > wrote:
>> 
>>> On Dec 5, 2017, at 2:28 PM, Douglas Gregor via swift-dev 
>>> > wrote:
>>> 
>>> To perform that mapping from a mangled type in a conditional requirement to 
>>> type metadata, we effectively need an operation to take a mangled type name 
>>> and turn it into a type metadata pointer. This is something we could 
>>> surface in the Swift standard library/runtime as, e.g.,
>>> 
>>> func type(named: String) -> Any.Type?
>>> 
>>> to take a mangled type name and try to get the type metadata for it. From 
>>> there, one can query protocol conformances that (say) allow one to 
>>> construct instances of the arbitrarily-named type. Think of it as 
>>> NSClassFromString for any type in the Swift language, including 
>>> specializations of generic types.
>> 
>> 
>> It's worth noting here that the standard library already provides a limited 
>> `_typeByName(_:)` function for Corelibs Foundation to use. That function 
>> will presumably become part of the ABI unless we design a public version in 
>> Swift 5.
> 
> 
> Woah. That’s kinda awful… it parses “Foo.Bar” as a class name and looks for 
> class Bar in module Foo.

Needed to implement NSCoding on Linux. They did limit it to "Foo.Bar" at least, 
deliberately excluding anything more complicated.

Jordan

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

Re: [swift-dev] TwoWordPair::Return and Calling Conventions on x64 Windows

[Jordan Rose via swift-dev]

Since all of the functions that use TwoWordPair::Return are part of the Swift 
runtime and not intended to be overloaded, we could also just make them all 
`extern "C"`, or give them explicit mangled names, either everywhere or just on 
x64 Windows.

Jordan


> On Dec 5, 2017, at 17:30, Thomas Roughton via swift-dev  
> wrote:
> 
> I've been working on getting Swift running properly on 64-bit Windows and 
> wanted to get some feedback/ideas on a specific issue. 
> 
> In swift/Runtime/HeapObject.h, there is a TwoWordPair::Return type intended 
> to return two word-sized values in registers. On Windows, structs are 
> returned indirectly. For some platforms (ARM, i386, 32-bit Windows) this is 
> worked around by packing the results into a 64-bit int.
> 
> We can apply a similar solution on Win64 by packing the results into an 
> __m128 and adopting the __vectorcall calling convention to ensure that the 
> value is passed in a register. However, adopting a new calling convention for 
> methods that interact with TwoWordPair::Return has a fairly major fallout; 
> I've started work in a branch (see the most recent three commits on 
> https://github.com/troughton/swift/tree/x64-vectorcall 
> ), but it feels very 
> messy. The main issue is that __vectorcall using a different mangling scheme, 
> which means we need to special-case in quite a few different places.
> 
> Another alternative would be to adopt the Swift calling convention for 
> swift_allocBox. If this doesn't cause other issues, it seems cleaner and 
> would have a much smaller impact on the code-base. However, there's currently 
> an issue blocking using the Swift calling convention on Windows; it gets sent 
> to MicrosoftMangle in Clang, which doesn't know how to mangle the Swift 
> calling convention (https://reviews.llvm.org/D31372 
> ). I'd like to resolve this, and it seems 
> like there are two possible implementations:
> 
> Pick an arbitrary prefix to use for SwiftCC and then mangle the rest of the 
> string following the Microsoft convention, knowing that tools won't know how 
> to deal with it.
> Alternatively, for functions that use SwiftCC, use the Itanium mangling. This 
> would require a more major refactoring in Clang but might be easier to 
> demangle.
> What are people's thoughts on these two issues?
> 
> - Thomas
> ___
> 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] [Proposal] RangeReplaceableCollection should inherits from MutableCollection

[Jordan Rose via swift-dev]

> On Dec 4, 2017, at 18:48, Brent Royal-Gordon via swift-dev 
>  wrote:
> 
>> On Dec 2, 2017, at 12:31 PM, Cao, Jiannan via swift-dev 
>>  wrote:
>> 
>> I'd like to discuss the relation between RangeReplaceableCollection and 
>> MutableCollection
>> 
>> MutableCollection is a Collection type that can { set } any element with 
>> subscript(position: Index). (and also { set } for subscript(range: 
>> Range))
>> 
>> RangeReplaceableCollection requires a function replaceRange(_:with:)
>> 
>> If a type conforms to RangeReplaceableCollection, it means any of its range 
>> can be replaced, that includes the situation to replace only one element.
>> So if some type conforms to RangeReplaceableCollection, it is sufficient to 
>> be a MutableCollection.
>> So I think the RangeReplaceableCollection should conforms to 
>> MutableCollection should inherits from MutableCollection.
> 
> 
> I thought this too a couple years ago, but it's not really true. 
> `MutableCollection` requires not only that you be able to set elements, but 
> also that when you do so, it doesn't change any of the indices in the 
> collection. Some collections can't guarantee that. For example, `String` 
> can't conform to `MutableCollection` because if you set some character in the 
> middle of the string to a character that's a different size, it might move 
> characters later in the string to different indices. So Swift lets you say 
> `myString.replaceSubrange(myRange, with: newCharacters)`, but it doesn't let 
> you say `myString[myRange] = newCharacters`.
> 
> `MutableCollection` and `RangeReplaceableCollection` are very similar in that 
> they both involve changing a collection. But they are different *kinds* of 
> changes to a collection, so it makes sense for a collection to support either 
> one of them without supporting the other.

MutableCollection's subscript setter is also expected to take constant time 
(well, proportional to the size of a single element). That may not be the case 
for a range replacement implementation, even if it turns out the other elements 
in the collection don't have to move.

Jordan
___
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.10 (master) #1704

[Jordan Rose via swift-dev]

Doesn't look like any of us. Anything happen over in Dispatch-land?

:0: error: cannot open file 
'/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift-corelibs-libdispatch/private/module.modulemap':
 No such file or directory

Jordan


> On Nov 28, 2017, at 11:57, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1704]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1704/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Tue, 28 Nov 2017 13:49:00 -0600
> Build duration:   8 min 37 sec
> 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: 10081 test(s), Total: 10081 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 486 test(s), Total: 486 test(s)
> 
> Changes
> 
> Commit b562663c5c76f03888e05388b27779d4744fea50 by jordan_rose:
> [test] Add deserialization recovery test for 'override required init'
> 
> edit: test/Serialization/Recovery/typedefs.swift
> 
> Commit 34de03daf3fd20dd1ea2f96ea0c9218381eb1cc2 by jordan_rose:
> [test] Add deserialization recovery test for 'dynamic required'
> 
> edit: test/Serialization/Recovery/typedefs.swift
> 
> Commit 748e1e128ff03bfa7e0b0e1888c29fe1eef740ef by ankit_aggarwal:
> Revert "Fix recursive constraint warnings"
> 
> edit: Sources/Basic/OutputByteStream.swift
> 
> Commit 42b26ce83738c682caaec462531cb3c6161abbfd by ankit_aggarwal:
> Use `SWIFT_EXEC` for executing `swift-build-tool` and importing
> 
> edit: Sources/Commands/UserToolchain.swift

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

Re: [swift-dev] Default deployment target for swiftc

[Jordan Rose via swift-dev]

Thanks, all. Sounds like following Clang and the interpreter is the way to go. 
https://github.com/apple/swift/pull/13114

Jordan


> On Nov 27, 2017, at 16:44, Jordan Rose via swift-dev <swift-dev@swift.org> 
> wrote:
> 
> Hi, all. Consider the following command, as run on a Mac with an up-to-date 
> Xcode installed:
> 
> xcrun swiftc foo.swift
> 
> The question: should this build for the current running OS, or the oldest 
> macOS Swift supports (10.9)? You can always specify the deployment target OS 
> version explicitly with the -target option, but what should the default 
> behavior be?
> 
> Some points to consider:
> - The deployment OS affects availability checks, which means that the command 
> might succeed on one host but fail on another.
> - …but we already changed the default for the interpreter (`xcrun swift`) to 
> be the current running OS in Swift 3.1 (Xcode 8.3, last spring).
> - Clang defaults to the current running OS (as of a few Xcodes ago, IIRC).
> 
> Given these points, I'm inclined to change swiftc to default to building for 
> the current running OS when no target is specified, but what do other people 
> think?
> 
> Note that this doesn't apply to projects built with either Xcode or the Swift 
> Package Manager, both of which always explicitly provide a deployment target. 
> Invoking swiftc directly and not providing -target means (1) you are 
> definitely compiling for Mac (when run on a Mac), and (2) there's a good 
> chance you don't plan to distribute what you just built, because until Swift 
> lives in the OS, it has dependencies on your installed Swift toolchain 
> (currently messily resolved with absolute rpaths). If you avoid this with 
> -static-stdlib, you're giving up the ability to have dynamic libraries, 
> because we didn't implement that properly.
> 
> Thanks for your feedback!
> Jordan
> 
> P.S. For Apple folks, this is rdar://problem/29948658 
> .
> 
> ___
> 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] Default deployment target for swiftc

[Jordan Rose via swift-dev]

Hi, all. Consider the following command, as run on a Mac with an up-to-date 
Xcode installed:

xcrun swiftc foo.swift

The question: should this build for the current running OS, or the oldest macOS 
Swift supports (10.9)? You can always specify the deployment target OS version 
explicitly with the -target option, but what should the default behavior be?

Some points to consider:
- The deployment OS affects availability checks, which means that the command 
might succeed on one host but fail on another.
- …but we already changed the default for the interpreter (`xcrun swift`) to be 
the current running OS in Swift 3.1 (Xcode 8.3, last spring).
- Clang defaults to the current running OS (as of a few Xcodes ago, IIRC).

Given these points, I'm inclined to change swiftc to default to building for 
the current running OS when no target is specified, but what do other people 
think?

Note that this doesn't apply to projects built with either Xcode or the Swift 
Package Manager, both of which always explicitly provide a deployment target. 
Invoking swiftc directly and not providing -target means (1) you are definitely 
compiling for Mac (when run on a Mac), and (2) there's a good chance you don't 
plan to distribute what you just built, because until Swift lives in the OS, it 
has dependencies on your installed Swift toolchain (currently messily resolved 
with absolute rpaths). If you avoid this with -static-stdlib, you're giving up 
the ability to have dynamic libraries, because we didn't implement that 
properly.

Thanks for your feedback!
Jordan

P.S. For Apple folks, this is rdar://problem/29948658.

___
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 - Long Test (master) #485

[Jordan Rose via swift-dev]

> On Oct 24, 2017, at 16:30, Slava Pestov via swift-dev  
> wrote:
> 
> 
>> On Oct 24, 2017, at 4:26 PM, Xi Ge via swift-dev > > wrote:
>> 
>> This could be due to one of the following commit. Could someone shed some 
>> lights on what’s going on?
>> Git (git g...@github.com :apple/swift.git)
>> 
>> [ClangImporter] Don't add duplicate search paths (detail 
>> )
>> [ClangImporter] Only suppress specific diags in synthetic buffers (detail 
>> )
> I’m going to guess it’s one of these two.

It could be the latter, but the error wouldn't be wrong. The Dispatch folks 
need to look into this.

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

Re: [swift-dev] CVaListPointer

[Jordan Rose via swift-dev]

[+swift-dev] We're fine with the type not being 'void *' exactly, but we have 
been checking that it's pointer-sized (see ImportDecl.cpp's 
getSwiftStdlibType). I think you can probably get away with just dropping that 
specifically on non-Darwin AArch64 as long as you provide a custom 
implementation of CVaList"Pointer" that makes sense.

Now, the next level of complexity, which fortunately doesn't apply to your 
arch: why is it called "CVaListPointer" and not just CVaList? Because sometimes 
va_list is an array, which means it can mean different things in a parameter 
list vs. elsewhere. (This occurs on non-Darwin x86_64 
.) The specific case I can think 
of is someone embedding a va_list in a struct, for whatever reason. 
CVaListPointer won't do the right thing there, since we're defining it 
explicitly in Swift to be pointer-sized. That said, I don't care about this 
case directly; as long as we don't try to import such a field as a 
CVaListPointer, it's okay. (It'll probably be imported as 'va_list', which is 
unfortunately confusing, but it won't come up much.)


So, once you've lifted the pointer-size restriction, we could consider renaming 
CVaListPointer to CVaList or something else (deprecating the old name), in 
light of the fact that it's not pointer-sized everywhere. This would require 
going to swift-evolution, though.

Jordan


> On Oct 17, 2017, at 10:54, Saleem Abdulrasool  wrote:
> 
> Hey Jordan,
> 
> So, it seems that on AArch64, the va_list type is a structure, and larger 
> than a void *.  It seems that this prevents the importer from mapping the 
> type into the swift representation.  I was wondering if you had any 
> suggestions on how to best handle this.
> 
> Thanks!
> 
> Saleem
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org

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

Re: [swift-dev] What can you change in a non-exhaustive enum?

[Jordan Rose via swift-dev]

Our worry when discussing it was that someone might have an autogenerated 
1000-case enum, and passing an entire page worth of resolved symbols might not 
be worth it.

(It is of course questionable for someone to have an autogenerated 1000-case 
enum as part of their binary interface, and then for someone to try to switch 
over it. But matching against one or two of the cases shouldn't be as expensive 
as matching against all 1000 known cases.)

Jordan

> On Oct 12, 2017, at 15:20, Greg Titus  wrote:
> 
> I like Joe’s idea here, with the extension that the client should have just 
> one of these arrays that contains all the symbols that it knows about at the 
> time it was compiled:
> 
> I.e. in the client:
> 
> static myKnownOpaqueEnumCases = [MyOpaqueEnum.intCase, 
> MyOpaqueEnum.middleCase, MyOpaqueEnum.stringCase];
> 
> switch indexForMyOpaqueEnumTag(, myKnownOpaqueEnumCases) {
> case 0: //…
> case 2: //…
> default: //...
> }
> 
> This optimizes for space in the client, because you have one array instead of 
> one per potentially-different-sets-of-cases switch, but more importantly this 
> allows for an optimization inside indexForMyOpaqueEnumTag(). If the count of 
> the array passed in from the client is equal to the count of all known cases 
> in the callee, then you can immediately return the internal enum tag value 
> instead of performing a binary search.
> 
> (If the client expects cases that the callee doesn’t have, the link would 
> have failed for a missing symbol, if the callee has more cases the count 
> won’t match, so if the count is equal the cases in both object files have to 
> be identical.) This returns the common runtime case (when the client is up to 
> date with the callee) to being O(1).
> 
> The cost being, if you don’t take that fast path, maybe you have a few more 
> entries in the cases array to binary search over than that particular switch 
> statement needed.
> 
> - Greg
> 
>> On Oct 12, 2017, at 2:25 PM, Jordan Rose > > wrote:
>> 
>> So, an update! This came up while I was talking to members of the core team, 
>> and ChrisL felt very strongly that restricting reordering of enum elements 
>> was a no-go, since it would be the only part of the language that worked 
>> this way (even if it only mattered for binary frameworks). Ted also rightly 
>> pointed out that any such language-level restriction would have to be 
>> reviewed by the core team.
>> 
>> So where does that leave us?
>> 
>> - The naive implementation is to turn a switch into an if-else chain, 
>> unfortunately requiring one function call per case to match.
>> 
>> - A slightly more complex solution keeps a single 'getMyOpaqueEnumTag' entry 
>> point (see original email), but exposes symbols for every tag. The values of 
>> the symbols would be kept in alphabetical order, which allows the generated 
>> code to do a binary search over the cases they care about. This still means 
>> N symbols, but a switch that involves several of them doesn't necessarily 
>> have to take linear time.
>> 
>> - Joe Groff came up with this idea that also involves sorted symbols:
>> 
>> switch indexForMyOpaqueEnumTag(, [MyOpaqueEnum.intCase, 
>> MyOpaqueEnum.stringCase]) {
>> case 0:
>>   var payload: Int
>>   getMyOpaqueEnumPayload(, MyOpaqueEnum.intCase, )
>>   doSomething(payload)
>> case 1:
>>   var payload: String
>>   getMyOpaqueEnumPayload(, MyOpaqueEnum.stringCase, )
>>   doSomethingElse(payload)
>> default:
>>   print("unknown case")
>> }
>> 
>> In this example, the actual tag values for 'intCase' and 'stringCase' might 
>> not be 0 and 1, but 'indexForMyOpaqueEnumTag' can do the binary search to 
>> find out which enum we're asking for. Like the previous solution, you only 
>> have to check the cases you care about, but this time the binary search is 
>> in the callee, rather than the client.
>> 
>> - Use availability ordering, plus some kind of explicit annotation for when 
>> multiple cases are added within the same release. (In this thread people 
>> have suggested dates, ad-hoc sub-version numbers, and plain integer values.)
>> 
>> I appreciate everyone's creativity with solving the availability ordering 
>> problem, but I don't want to tie us to a checker that will tell you if you 
>> screw up or a history scraper that will implicitly add the right 
>> annotations. (I don't think those are bad ideas, but they're a whole extra 
>> pile of work on top of the main implementation!) That leaves explicit 
>> annotations of some kind, and that leaves us in a worse place than 
>> Objective-C. Which is permitted, but not desirable.
>> 
>>  At this point in time I think the second option is the best one we have: 
>> it's relatively simple to implement, it supports everything Objective-C 
>> does, and it doesn't make the availability model even more complicated. It 
>> is going to be less efficient than actually knowing the case numbers at 
>> compile 

Re: [swift-dev] What can you change in a non-exhaustive enum?

[Jordan Rose via swift-dev]

So, an update! This came up while I was talking to members of the core team, 
and ChrisL felt very strongly that restricting reordering of enum elements was 
a no-go, since it would be the only part of the language that worked this way 
(even if it only mattered for binary frameworks). Ted also rightly pointed out 
that any such language-level restriction would have to be reviewed by the core 
team.

So where does that leave us?

- The naive implementation is to turn a switch into an if-else chain, 
unfortunately requiring one function call per case to match.

- A slightly more complex solution keeps a single 'getMyOpaqueEnumTag' entry 
point (see original email), but exposes symbols for every tag. The values of 
the symbols would be kept in alphabetical order, which allows the generated 
code to do a binary search over the cases they care about. This still means N 
symbols, but a switch that involves several of them doesn't necessarily have to 
take linear time.

- Joe Groff came up with this idea that also involves sorted symbols:

switch indexForMyOpaqueEnumTag(, [MyOpaqueEnum.intCase, 
MyOpaqueEnum.stringCase]) {
case 0:
  var payload: Int
  getMyOpaqueEnumPayload(, MyOpaqueEnum.intCase, )
  doSomething(payload)
case 1:
  var payload: String
  getMyOpaqueEnumPayload(, MyOpaqueEnum.stringCase, )
  doSomethingElse(payload)
default:
  print("unknown case")
}

In this example, the actual tag values for 'intCase' and 'stringCase' might not 
be 0 and 1, but 'indexForMyOpaqueEnumTag' can do the binary search to find out 
which enum we're asking for. Like the previous solution, you only have to check 
the cases you care about, but this time the binary search is in the callee, 
rather than the client.

- Use availability ordering, plus some kind of explicit annotation for when 
multiple cases are added within the same release. (In this thread people have 
suggested dates, ad-hoc sub-version numbers, and plain integer values.)

I appreciate everyone's creativity with solving the availability ordering 
problem, but I don't want to tie us to a checker that will tell you if you 
screw up or a history scraper that will implicitly add the right annotations. 
(I don't think those are bad ideas, but they're a whole extra pile of work on 
top of the main implementation!) That leaves explicit annotations of some kind, 
and that leaves us in a worse place than Objective-C. Which is permitted, but 
not desirable.

 At this point in time I think the second option is the best one we have: it's 
relatively simple to implement, it supports everything Objective-C does, and it 
doesn't make the availability model even more complicated. It is going to be 
less efficient than actually knowing the case numbers at compile time, though. 
Still, as Slava's pointed out, we can still change this after we go ABI-stable; 
doing something more efficient will just be limited based on deployment target.

Jordan

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

Re: [swift-dev] Failure: Swift master branch build failing on x86 (Ubuntu 16.04).

[Jordan Rose via swift-dev]

I will note that the Makefile build is not something we test. What happens if 
you drop -m from your build command, to use Ninja instead?

Jordan


> On Oct 8, 2017, at 22:36, Slava Pestov via swift-dev  
> wrote:
> 
> Hi Atul,
> 
> The master branch is tested in CI, so any build failures are likely due to 
> configuration problems on your end. While testing the swift-4.0-branch would 
> provide an interesting data point, I would not expect it to work if building 
> master fails.
> 
> Slava
> 
>> On Oct 8, 2017, at 10:35 PM, Atul Sowani via swift-dev > > wrote:
>> 
>> I still have no luck building swift on x86 using the master branch. Is it 
>> recommended to use the master branch at all (considering a lot of fixes 
>> would be coming in) or is it desirable to use 4.0 branch instead as a 
>> general rule?
>> 
>> Thanks,
>> Atul.
>> 
>> On Fri, Oct 6, 2017 at 7:03 PM, Atul Sowani via swift-dev 
>> > wrote:
>> Thanks Alex! I used the clean/reset command and then tried rebuilding it, 
>> but got the very same error. I am using master branch, latest 
>> (top-of-the-tree) version:
>> 
>> git clone https://github.com/apple/swift.git 
>> 
>> ./swift/utils/update-checkout --clone
>> cd swift
>> utils/build-script -c -m -R --verbose-build
>> 
>> Hope this is correct.
>> 
>> Thanks,
>> Atul.
>> 
>> On Fri, Oct 6, 2017 at 5:51 PM, Alex Blewitt > > wrote:
>> 
>> 
>> > On 6 Oct 2017, at 12:42, Atul Sowani via swift-dev > > > wrote:
>> >
>> > Hi,
>> >
>> > Swift "master" branch is failing to build on x86 running Ubuntu 16,04 with 
>> > following error.
>> 
>> Most of the recent builds appear to be working:
>> 
>> https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-linux-ubuntu-16_04-master-next/
>>  
>> 
>> 
>> > I am using following build command from inside swift-source/swift 
>> > directory:
>> > utils/build-script -c -m -R --verbose-build
>> 
>> What version of the 'swift' project do you have checked out? Have you done a 
>> clean/reset to make sure those aren't issues at the moment?
>> 
>> You can run swift/utils/update-checkout --clean --reset-to-remote --scheme 
>> master (which will get rid of any cruft if you haven't got anything you need 
>> to keep) and then re-run the build to see if that resolves the errors.
>> 
>> Alex
>> 
>> 
>> ___
>> 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

___
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) #897

[Jordan Rose via swift-dev]

+Saleem, who's been looking at Dispatch's build system. 

> On Oct 5, 2017, at 22:12, Slava Pestov  wrote:
> 
> We keep seeing this failure in the bots:
> 
> src/libdispatch.so: error: undefined reference to 
> ‘_T0s17_assertionFailures5NeverOs12StaticStringV_SSAE4fileSu4lines6UInt32V5flagstFTfq4nxnnn_n'
> 
> A clean build fixes it. However, it comes back, because if the bot builds the 
> 4.0 branch and then goes and builds master, the problem returns.
> 
> Can somebody look at this?
> 
> Slava
> 
>> On Oct 5, 2017, at 10:11 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#897]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/897/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_04
>> Date of build:   Fri, 06 Oct 2017 00:05:17 -0500
>> Build duration:  7 min 26 sec
>> 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: 9964 test(s), Total: 9964 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 483 test(s), Total: 483 test(s)
>> 
>> Changes
>> 
>> Commit c272d41e2f392d2b97c9bd55d819be67912f01d0 by spestov:
>> Re-apply "SIL: Remove special meaning for
>> 
>> edit: stdlib/public/core/REPL.swift
>> edit: stdlib/public/core/AssertCommon.swift
>> edit: stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb
>> edit: test/SILOptimizer/Inputs/linker_pass_input.swift
>> edit: stdlib/public/core/Print.swift
>> edit: stdlib/public/core/StringBridge.swift
>> edit: stdlib/public/core/StringComparable.swift
>> edit: test/SILOptimizer/string_switch.swift
>> edit: stdlib/public/core/StringSwitch.swift
>> edit: stdlib/public/core/HashedCollections.swift.gyb
>> edit: lib/SILOptimizer/Utils/Local.cpp
>> edit: stdlib/public/core/DebuggerSupport.swift
>> edit: lib/SIL/Linker.cpp
>> edit: test/SILOptimizer/linker.swift
>> edit: docs/HighLevelSILOptimizations.rst
>> edit: stdlib/public/core/StringHashable.swift
>> delete: test/SILOptimizer/specialization_of_stdlib_binary_only.swift
>> edit: stdlib/public/core/OutputStream.swift
>> edit: lib/SILOptimizer/IPO/GlobalOpt.cpp
>> 
>> Commit 5e67f755e044f7a3c143f85c3f1b73d9c1043939 by rlevenstein:
>> Remove the -sil-serialize-all option
>> 
>> edit: lib/Frontend/CompilerInvocation.cpp
>> edit: lib/SILGen/SILGen.h
>> edit: lib/Serialization/SerializeSIL.cpp
>> edit: stdlib/private/StdlibCollectionUnittest/CMakeLists.txt
>> edit: include/swift/SIL/SILModule.h
>> edit: include/swift/AST/SILOptions.h
>> edit: stdlib/private/StdlibUnicodeUnittest/CMakeLists.txt
>> edit: include/swift/Option/FrontendOptions.td
>> edit: lib/SILGen/SILGenType.cpp
>> edit: lib/Frontend/Frontend.cpp
>> edit: stdlib/private/StdlibUnittest/CMakeLists.txt
>> edit: docs/Lexicon.rst
>> edit: lib/FrontendTool/FrontendTool.cpp
>> 
>> Commit dd85e69e7fa36c132a6af0a2abad80ca85127c33 by rlevenstein:
>> Update the tests after removing the -sil-serialize-all option
>> 
>> edit: test/SIL/Serialization/Inputs/nontransparent.swift
>> edit: test/Serialization/always_inline.swift
>> edit: test/Serialization/witnesstable-function-deserialization.swift
>> edit: test/Serialization/resilience.swift
>> edit: test/SIL/Serialization/deserialize_generic.sil
>> edit: test/SIL/Serialization/perf_inline_without_inline_all.swift
>> edit: test/SIL/Serialization/visibility.sil
>> edit: test/Serialization/noinline.swift
>> edit: test/SIL/Serialization/witness_tables.sil
>> edit: test/SIL/Serialization/Inputs/vtable_deserialization_input.swift
>> edit: utils/swift-project-settings.el
>> edit: 
>> test/SIL/Serialization/init_existential_inst_deserializes_witness_tables.swift
>> edit: test/SIL/Serialization/specializer_can_deserialize.swift
>> edit: test/sil-func-extractor/load-serialized-sil.swift
>> edit: test/SILGen/witness_tables_serialized.swift
>> edit: test/Serialization/duplicate_normalprotocolconformance.swift
>> edit: test/sil-opt/sil-opt.swift
>> edit: test/Serialization/basic_sil_objc.swift
>> edit: test/SILGen/Inputs/ModuleA.swift
>> edit: test/Serialization/default-witness-table-deserialization.swift
>> edit: test/SIL/Serialization/function_param_convention.sil
>> edit: test/SILGen/Inputs/ModuleB.swift
>> edit: test/Serialization/basic_sil.swift
>> edit: test/Serialization/global_init.swift
>> edit: test/SIL/Serialization/shared_function_serialization.sil
>> edit: test/Serialization/Inputs/def_noinline.swift
>> edit: test/SILOptimizer/dead_witness_module.swift
>> edit: test/Serialization/Inputs/def_basic.sil
>> edit: test/Serialization/serialize_attr.swift
>> edit: 

Re: [swift-dev] Exclusivity checker hacking?

[Jordan Rose via swift-dev]

> On Oct 5, 2017, at 15:44, David Zarzycki  wrote:
> 
> 
> 
>> On Oct 5, 2017, at 18:34, Jordan Rose > > wrote:
>> 
>> 
>> 
>>> On Oct 5, 2017, at 15:23, David Zarzycki > 
>>> wrote:
>>> 
>>> 
>>> 
 On Oct 5, 2017, at 18:08, Jordan Rose > wrote:
 
 
 
> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev 
> > wrote:
> 
> Hello,
> 
> As an experiment, I’d like to force the exclusivity checking logic to 
> always error at compile time, rather than a mix of compile time and run 
> time. Near as I can tell, there is no built in debugging logic to do this 
> (not even to warn when dynamic checks are added). Am I missing something? 
> Where would be the best place in the code to make the dynamic checker 
> error/warning at compile time? Would a warning be useful to others? Or 
> should I just keep this on a throwaway branch?
 
 It's worth noting that this is impossible in the general case:
 
 // Library.swift
 public class Foo {
   public var x: Int = 0
   public init() {}
 }
 public func testExclusivity(_ a: Foo, _ b: Foo, by callback: (inout Int, 
 inout Int) -> Void) {
   callback(, )
 }
 
 // Client.swift, compiled as a separate target
 let foo = Foo()
 testExclusivity(foo, foo) { $0 = 42; $1 = 8192 }
 
 That doesn't necessarily mean there aren't improvements to be made, but it 
 might change your goals.
>>> 
>>> 
>>> Hi Jordan,
>>> 
>>> Thanks for writing the above code. Just to be clear, are you pointing out 
>>> that exclusivity checking through opaque code (like a library) is 
>>> problematic? Or that classes introduce their own aliasing challenges? Or 
>>> both? Or something else entirely?
>> 
>> The former, really. Classes are just the most convenient way to get 
>> coincidental aliasing.
>> 
>> 
>>> If we set aside resiliency for a second, couldn't the exclusivity checker 
>>> dynamically crash in the above scenario if two or more InOutExprs end up 
>>> resolving to the same address? If not, then why not?
>> 
>> "If we set aside resiliency" isn't something that works today. Local builds 
>> don't actually have access to the SIL of any of their dependencies at the 
>> moment (for a handful of reasons). Opaque code really does have to be 
>> treated as opaque.
>> 
>> (If this isn't convincing, then consider 'a' and 'b' coming directly from 
>> Objective-C code, where there's no exclusivity checking logic at all.)
> 
> Right, that make sense.
> 
> Let’s step back for a second. How comprehensive is the exclusivity checker 
> within a single/pure Swift module? As long as external modules aren’t 
> involed, is the model exhaustive? Or can some scenarios slip through both the 
> static and dynamic checking? (Again, just within a single pure Swift module.)

John or Devin would be better at answering this, but I believe that the 
combined static/dynamic model will catch everything except accesses through 
UnsafePointer (sure), accesses from C (sure), and accesses across threads 
(ouch). The last can be caught by TSan, though.

One other caveat: I believe we turn off the dynamic checking completely under 
-O in the Swift 4 release. I'm not sure if there are plans to change that or if 
the cost of the check really is that bad.

Jordan

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

Re: [swift-dev] Exclusivity checker hacking?

[Jordan Rose via swift-dev]

> On Oct 5, 2017, at 15:23, David Zarzycki  wrote:
> 
> 
> 
>> On Oct 5, 2017, at 18:08, Jordan Rose > > wrote:
>> 
>> 
>> 
>>> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev >> > wrote:
>>> 
>>> Hello,
>>> 
>>> As an experiment, I’d like to force the exclusivity checking logic to 
>>> always error at compile time, rather than a mix of compile time and run 
>>> time. Near as I can tell, there is no built in debugging logic to do this 
>>> (not even to warn when dynamic checks are added). Am I missing something? 
>>> Where would be the best place in the code to make the dynamic checker 
>>> error/warning at compile time? Would a warning be useful to others? Or 
>>> should I just keep this on a throwaway branch?
>> 
>> It's worth noting that this is impossible in the general case:
>> 
>> // Library.swift
>> public class Foo {
>>   public var x: Int = 0
>>   public init() {}
>> }
>> public func testExclusivity(_ a: Foo, _ b: Foo, by callback: (inout Int, 
>> inout Int) -> Void) {
>>   callback(, )
>> }
>> 
>> // Client.swift, compiled as a separate target
>> let foo = Foo()
>> testExclusivity(foo, foo) { $0 = 42; $1 = 8192 }
>> 
>> That doesn't necessarily mean there aren't improvements to be made, but it 
>> might change your goals.
> 
> 
> Hi Jordan,
> 
> Thanks for writing the above code. Just to be clear, are you pointing out 
> that exclusivity checking through opaque code (like a library) is 
> problematic? Or that classes introduce their own aliasing challenges? Or 
> both? Or something else entirely?

The former, really. Classes are just the most convenient way to get 
coincidental aliasing.


> If we set aside resiliency for a second, couldn't the exclusivity checker 
> dynamically crash in the above scenario if two or more InOutExprs end up 
> resolving to the same address? If not, then why not?

"If we set aside resiliency" isn't something that works today. Local builds 
don't actually have access to the SIL of any of their dependencies at the 
moment (for a handful of reasons). Opaque code really does have to be treated 
as opaque.

(If this isn't convincing, then consider 'a' and 'b' coming directly from 
Objective-C code, where there's no exclusivity checking logic at all.)

Jordan

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

Re: [swift-dev] Exclusivity checker hacking?

[Jordan Rose via swift-dev]

> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev  
> wrote:
> 
> Hello,
> 
> As an experiment, I’d like to force the exclusivity checking logic to always 
> error at compile time, rather than a mix of compile time and run time. Near 
> as I can tell, there is no built in debugging logic to do this (not even to 
> warn when dynamic checks are added). Am I missing something? Where would be 
> the best place in the code to make the dynamic checker error/warning at 
> compile time? Would a warning be useful to others? Or should I just keep this 
> on a throwaway branch?

It's worth noting that this is impossible in the general case:

// Library.swift
public class Foo {
  public var x: Int = 0
  public init() {}
}
public func testExclusivity(_ a: Foo, _ b: Foo, by callback: (inout Int, inout 
Int) -> Void) {
  callback(, )
}

// Client.swift, compiled as a separate target
let foo = Foo()
testExclusivity(foo, foo) { $0 = 42; $1 = 8192 }

That doesn't necessarily mean there aren't improvements to be made, but it 
might change your goals.

Jordan

___
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 14.04 (master) #938

[Jordan Rose via swift-dev]

None of these changes are related to the test that failed. We'll see if the 
next build passes.


> On Oct 4, 2017, at 12:01, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#938]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/938/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Wed, 04 Oct 2017 13:43:54 -0500
> Build duration:   18 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit f95c979cbfeb71de04d78d28d6649da39ae05a7d by pyaskevich:
> [ConstraintSolver] Remove hack related to single parameter handling
> 
> edit: lib/Sema/CSSimplify.cpp
> 
> Commit ca910100761ba025d9b7156d1030184a42bdd486 by artem.dergachev:
> [analyzer] Fix an outdated comment in a test. NFC.
> 
> edit: test/Analysis/null-deref-path-notes.c
> 
> Commit 9354cd0baf8b2d57a10d5de14ab31454e2a11377 by artem.dergachev:
> [Analyzer] Synthesize function body for std::call_once
> 
> add: test/Analysis/call_once.cpp
> edit: lib/Analysis/BodyFarm.cpp
> 
> Commit 7e6679e12aaa005458c346b123d0916c6481fdbd by artem.dergachev:
> [Analyzer] Add nullability to the list of tested checkers in SATestBuild
> 
> edit: utils/analyzer/SATestBuild.py
> 
> Commit d6c737c4f239629757347edc2b21ea3443cc4690 by artem.dergachev:
> [Analyzer] Document a gotcha: for C++ -analyze-function requires
> 
> edit: www/analyzer/checker_dev_manual.html
> edit: include/clang/Driver/CC1Options.td
> 
> Commit 1b1b4ff904829d70fad3ec730b34cee6fb4e8dce by artem.dergachev:
> [Analyzer] Add dummy implementation to call_once to avoid linkage
> 
> edit: test/Analysis/call_once.cpp
> 
> Commit 963a884086f6061ca2a9c4c6a3413416648a736c by artem.dergachev:
> [Analyzer] Make testing scripts flake8 compliant
> 
> edit: utils/analyzer/ubiviz
> edit: utils/analyzer/SATestBuild.py
> edit: utils/analyzer/SATestAdd.py
> edit: utils/analyzer/CmpRuns.py
> edit: utils/analyzer/SATestUpdateDiffs.py
> edit: utils/analyzer/SumTimerInfo.py
> 
> Commit 48016cb2195a3b86ae3b992d6ec3ec3a0a690128 by artem.dergachev:
> [Analyzer] Avoid copy and modifying passed reference in
> 
> edit: lib/Analysis/BodyFarm.cpp
> 
> Commit f1189227507f8381f14bc4142e3a2256902b889d by artem.dergachev:
> [Analyzer] Re-apply r314820 with a fix for StringRef lifetime.
> 
> edit: test/Analysis/retain-release.mm
> edit: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp

___
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 14.04 (master) #938

[Jordan Rose via swift-dev]

(Oops, it already did.)


> On Oct 4, 2017, at 12:45, Jordan Rose  wrote:
> 
> None of these changes are related to the test that failed. We'll see if the 
> next build passes.
> 
> 
>> On Oct 4, 2017, at 12:01, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#938]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/938/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04
>> Date of build:   Wed, 04 Oct 2017 13:43:54 -0500
>> Build duration:  18 min
>> Identified problems:
>> 
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all errors:
>> Indication 1 
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Changes
>> 
>> Commit f95c979cbfeb71de04d78d28d6649da39ae05a7d by pyaskevich:
>> [ConstraintSolver] Remove hack related to single parameter handling
>> 
>> edit: lib/Sema/CSSimplify.cpp
>> 
>> Commit ca910100761ba025d9b7156d1030184a42bdd486 by artem.dergachev:
>> [analyzer] Fix an outdated comment in a test. NFC.
>> 
>> edit: test/Analysis/null-deref-path-notes.c
>> 
>> Commit 9354cd0baf8b2d57a10d5de14ab31454e2a11377 by artem.dergachev:
>> [Analyzer] Synthesize function body for std::call_once
>> 
>> add: test/Analysis/call_once.cpp
>> edit: lib/Analysis/BodyFarm.cpp
>> 
>> Commit 7e6679e12aaa005458c346b123d0916c6481fdbd by artem.dergachev:
>> [Analyzer] Add nullability to the list of tested checkers in SATestBuild
>> 
>> edit: utils/analyzer/SATestBuild.py
>> 
>> Commit d6c737c4f239629757347edc2b21ea3443cc4690 by artem.dergachev:
>> [Analyzer] Document a gotcha: for C++ -analyze-function requires
>> 
>> edit: www/analyzer/checker_dev_manual.html
>> edit: include/clang/Driver/CC1Options.td
>> 
>> Commit 1b1b4ff904829d70fad3ec730b34cee6fb4e8dce by artem.dergachev:
>> [Analyzer] Add dummy implementation to call_once to avoid linkage
>> 
>> edit: test/Analysis/call_once.cpp
>> 
>> Commit 963a884086f6061ca2a9c4c6a3413416648a736c by artem.dergachev:
>> [Analyzer] Make testing scripts flake8 compliant
>> 
>> edit: utils/analyzer/ubiviz
>> edit: utils/analyzer/SATestBuild.py
>> edit: utils/analyzer/SATestAdd.py
>> edit: utils/analyzer/CmpRuns.py
>> edit: utils/analyzer/SATestUpdateDiffs.py
>> edit: utils/analyzer/SumTimerInfo.py
>> 
>> Commit 48016cb2195a3b86ae3b992d6ec3ec3a0a690128 by artem.dergachev:
>> [Analyzer] Avoid copy and modifying passed reference in
>> 
>> edit: lib/Analysis/BodyFarm.cpp
>> 
>> Commit f1189227507f8381f14bc4142e3a2256902b889d by artem.dergachev:
>> [Analyzer] Re-apply r314820 with a fix for StringRef lifetime.
>> 
>> edit: test/Analysis/retain-release.mm
>> edit: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
> 

___
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 - Swift Incremental RA - Ubuntu 16.04 (master) #849

[Jordan Rose via swift-dev]

I wiped the workspace of the Linux bots as Roman suggested.


> On Oct 3, 2017, at 16:50, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#849]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/849/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Tue, 03 Oct 2017 18:51:20 -0500
> Build duration:   48 sec
> 
> Changes
> 
> Commit 969421f5ac164d98f4650ae0f1a4fd10409cabad by aprantl:
> [DebugInfo] Handle endianness when moving debug info for split integer
> 
> add: test/CodeGen/PowerPC/debuginfo-split-int.ll
> edit: lib/CodeGen/SelectionDAG/LegalizeTypes.cpp
> 
> Commit e77f221279851c2406e824e75ae8904ba7d89ab5 by aprantl:
> Add a manpage for llvm-dwarfdump.
> 
> edit: docs/CMakeLists.txt
> edit: docs/CommandGuide/llvm-dwarfdump.rst

___
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) #839

[Jordan Rose via swift-dev]

/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, Repository lookup expectation

Ankit, any ideas?


> On Oct 3, 2017, at 12:16, Pavel Yaskevich  wrote:
> 
> Looks like a flaky test to me, definitely not related to my changes...
> 
>> On Oct 3, 2017, at 12:09 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#839]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/839/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_04
>> Date of build:   Tue, 03 Oct 2017 13:33:50 -0500
>> Build duration:  36 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: 9953 test(s), Total: 9953 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 461 test(s), Total: 461 test(s)
>> 
>> Changes
>> 
>> Commit 9271368b46e49e5d4e0e4ee80c750eae32ec2d0c by blangmuir:
>> [test] Attempt to gather more information if cursor_no_cancel crashes
>> 
>> edit: test/SourceKit/CursorInfo/cursor_no_cancel.swift
>> 
>> Commit 4317074a9a8375e73ab136fef8ab72f09ea36e7d by pyaskevich:
>> [ConstraintSolver] Prioritize certain type variables while looking for
>> 
>> edit: lib/Sema/CSBindings.cpp
>> edit: lib/Sema/CSSimplify.cpp
>> edit: test/Constraints/generics.swift
>> edit: lib/Sema/ConstraintSystem.h
> 

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

Re: [swift-dev] [Swift CI] Build Failure: 2. Swift Source Compatibility Suite (master) #389

[Jordan Rose via swift-dev]

[others to bcc, sorry for pulling you along] I think Ben's latest changes to 
the use of AnySequence have a good chance of fixing this.

Jordan


> On Oct 2, 2017, at 22:28, Pavel Yaskevich <pavel.yaskev...@gmail.com> wrote:
> 
> It looks like the change was introduced by 
> https://github.com/AsyncNinja/AsyncNinja/commit/1cc002e705c3be7a24db93741ad8a2a6ff2d7c27
>  
> <https://github.com/AsyncNinja/AsyncNinja/commit/1cc002e705c3be7a24db93741ad8a2a6ff2d7c27>
>  which got into the suite along with the fix for 
> https://bugs.swift.org/browse/SR-5998 <https://bugs.swift.org/browse/SR-5998>
> 
> On Mon, Oct 2, 2017 at 10:11 PM, Pavel Yaskevich via swift-dev 
> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> Looks like it wasn't me after all, source compatibility suite still fails in 
> AsyncNinja even with my changes reverted - 
> https://ci.swift.org/view/Source%20Compatibility/job/swift-master-source-compat-suite/391/
>  
> <https://ci.swift.org/view/Source%20Compatibility/job/swift-master-source-compat-suite/391/>
> 
> On Mon, Oct 2, 2017 at 6:58 PM, Pavel Yaskevich via swift-dev 
> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> Jordan, let's see if this helps because when I merged my original PR there 
> were no failures and only one target of AsyncNinja has been disabled, but I 
> noticed (just now) that all of them fail now which might actually not be my 
> fault...
> 
> On Mon, Oct 2, 2017 at 6:44 PM, Pavel Yaskevich via swift-dev 
> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> Merged revert into master 
> https://github.com/apple/swift/commit/9642ff0ba6018f5c236186627a3038627ea05a29
>  
> <https://github.com/apple/swift/commit/9642ff0ba6018f5c236186627a3038627ea05a29>
> 
> On Mon, Oct 2, 2017 at 4:36 PM, Pavel Yaskevich via swift-dev 
> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> Sorry it might be my commit actually, I am AFK for a bit, will revert once I 
> am back.
> 
> Sent from my iPhone
> 
> On Oct 2, 2017, at 3:48 PM, Jordan Rose via swift-dev <swift-dev@swift.org 
> <mailto:swift-dev@swift.org>> wrote:
> 
>> Anton just reupdated AsyncNinja, but it looks we have a new problem there:
>> 
>> /Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/project_cache/AsyncNinja/Sources/Producer.swift:42:27:
>>  error: ambiguous use of 'suffix'
>> _bufferedUpdates.push(bufferedUpdates.suffix(bufferSize))
>>   ^
>> Swift.Sequence:301:17: note: found this candidate
>> public func suffix(_ maxLength: Int) -> Self.SubSequence
>> ^
>> Swift.Sequence:53:17: note: found this candidate
>> public func suffix(_ maxLength: Int) -> AnySequence
>> ^
>> 
>> Pavel, there's already a bug for this, right?
>> 
>> Jordan
>> 
>> 
>> 
>>> On Oct 2, 2017, at 15:44, no-re...@swift.org <mailto:no-re...@swift.org> 
>>> wrote:
>>> 
>>> [FAILURE] swift-master-source-compat-suite [#389]
>>> 
>>> Build URL:  https://ci.swift.org/job/swift-master-source-compat-suite/389/ 
>>> <https://ci.swift.org/job/swift-master-source-compat-suite/389/>
>>> Project:swift-master-source-compat-suite
>>> Date of build:  Mon, 02 Oct 2017 15:15:01 -0500
>>> Build duration: 2 hr 30 min
>>> 
>>> Changes
>>> 
>>> Commit 001b09747a153763b30ef8a02254c7a0419c6292 by pyaskevich:
>>> [ConstraintSolver] Prioritize certain type variables while looking for
>>> 
>>> edit: test/Constraints/generics.swift
>>> edit: lib/Sema/CSSimplify.cpp
>>> edit: lib/Sema/CSBindings.cpp
>>> edit: lib/Sema/ConstraintSystem.h
>>> 
>>> Commit 6fe4ff8be7ab142ba7427c665b955770fc6905ba by mnvrth:
>>> [CMake] Fix status message when not building stdlib/runtime
>>> 
>>> edit: CMakeLists.txt
>>> 
>>> Commit 5ba1522874a46b85df8de7cd6bd4f4d1d41ab4a7 by mnvrth:
>>> [CMake] Improve wording of stdlib/overlay/runtime build status
>>> 
>>> edit: CMakeLists.txt
>>> 
>>> Commit f2ef42baed96e16086481537cc7dc87bbd2368b0 by github:
>>> [migrator] When renaming a function decl, we should use underscore to
>>> 
>>> edit: lib/Migrator/APIDiffMigratorPass.cpp
>>> edit: test/Migrator/Inputs/Cities.swift
>>> edit: test/Migrator/rename-func-decl.swift
>>> edit: test/Migrator/rename-func-decl.swift.expected
>>> edit: test/Migrator/Inputs/API.json
>>> 
>>> C

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

[Jordan Rose via swift-dev]

Doug, did you win back all the regressions yet? If not, we should probably bump 
up the Linux timeout for now. It's waffling back and forth between success and 
failure so 40 minutes ought to be enough for testing.

(Yes, we want the incremental bot to be fast.)

Jordan


> On Oct 2, 2017, at 18:21, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#900]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/900/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Mon, 02 Oct 2017 19:19:36 -0500
> Build duration:   1 hr 3 min
> Identified problems:
> 
> Timeout: This build was marked as FAIL because it timed out.
> Indication 1 
> 
> Changes
> 
> Commit a51d9b950b8129e572543581b72526715450e332 by eeckstein:
> SILCombine: fix propagation of existential self into witness method call
> 
> edit: test/SILOptimizer/sil_combine_apply.sil
> edit: lib/SILOptimizer/SILCombiner/SILCombinerApplyVisitors.cpp
> 
> Commit 680d151963ff5e55f0aa80c8dcb51cd19e4871c8 by github:
> Return back the '-report-errors-to-debugger' frontend flag to support
> 
> edit: include/swift/Option/FrontendOptions.td

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

Re: [swift-dev] [Swift CI] Build Failure: 2. Swift Source Compatibility Suite (master) #389

[Jordan Rose via swift-dev]

Anton just reupdated AsyncNinja, but it looks we have a new problem there:

/Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/project_cache/AsyncNinja/Sources/Producer.swift:42:27:
 error: ambiguous use of 'suffix'
_bufferedUpdates.push(bufferedUpdates.suffix(bufferSize))
  ^
Swift.Sequence:301:17: note: found this candidate
public func suffix(_ maxLength: Int) -> Self.SubSequence
^
Swift.Sequence:53:17: note: found this candidate
public func suffix(_ maxLength: Int) -> AnySequence
^

Pavel, there's already a bug for this, right?

Jordan



> On Oct 2, 2017, at 15:44, no-re...@swift.org wrote:
> 
> [FAILURE] swift-master-source-compat-suite [#389]
> 
> Build URL:https://ci.swift.org/job/swift-master-source-compat-suite/389/ 
> 
> Project:  swift-master-source-compat-suite
> Date of build:Mon, 02 Oct 2017 15:15:01 -0500
> Build duration:   2 hr 30 min
> 
> Changes
> 
> Commit 001b09747a153763b30ef8a02254c7a0419c6292 by pyaskevich:
> [ConstraintSolver] Prioritize certain type variables while looking for
> 
> edit: test/Constraints/generics.swift
> edit: lib/Sema/CSSimplify.cpp
> edit: lib/Sema/CSBindings.cpp
> edit: lib/Sema/ConstraintSystem.h
> 
> Commit 6fe4ff8be7ab142ba7427c665b955770fc6905ba by mnvrth:
> [CMake] Fix status message when not building stdlib/runtime
> 
> edit: CMakeLists.txt
> 
> Commit 5ba1522874a46b85df8de7cd6bd4f4d1d41ab4a7 by mnvrth:
> [CMake] Improve wording of stdlib/overlay/runtime build status
> 
> edit: CMakeLists.txt
> 
> Commit f2ef42baed96e16086481537cc7dc87bbd2368b0 by github:
> [migrator] When renaming a function decl, we should use underscore to
> 
> edit: lib/Migrator/APIDiffMigratorPass.cpp
> edit: test/Migrator/Inputs/Cities.swift
> edit: test/Migrator/rename-func-decl.swift
> edit: test/Migrator/rename-func-decl.swift.expected
> edit: test/Migrator/Inputs/API.json
> 
> Commit c47287199bce9b4d2c9ae0dc308dc328461ce9f6 by arthur:
> Updated Guitar support for Swift 4.0
> 
> edit: projects.json
> 
> Commit 1a82e4d490d4607da81f58327eb0f900f3056c08 by antonvmironov:
> AsyncNinja updated. https://bugs.swift.org/browse/SR-5998 
>  fixed
> 
> edit: projects.json
> 
> Commit ce4cf094fabf5b5e306b6b7b5cf65461ab681d7b by arthur:
> Re-added 3.1 compatibility
> 
> edit: projects.json
> 
> Commit 632bf4e2201eb4d2d3cfb9a594f02e4bfc5f6a3a by arthur:
> Removed comma
> 
> edit: projects.json
> 
> Commit 87ebe010aedc3bd89d351f8b0ecc7ffdd0ea8494 by antonvmironov:
> UnXFAIL AsyncNinja
> 
> edit: projects.json

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

[swift-dev] What can you change in a non-exhaustive enum?

[Jordan Rose via swift-dev]

Hello again, swift-dev! This is a sort of follow-up to "What can you change in 
a fixed-contents struct" from a few weeks ago, but this time concerning enums. 
Worryingly, this seems to be an important consideration even for non-exhaustive 
enums, which are normally the ones where we'd want to allow a developer to do 
anything and everything that doesn't break source compatibility.

[This only affects libraries with binary compatibility concerns. Libraries 
distributed with an app can always allow the app to access the enum's 
representation directly. That makes this an Apple-centric problem in the near 
term.]

So, what's the issue? We want to make it efficient to switch over a 
non-exhaustive enum, even from a client library that doesn't have access to the 
enum's guts. We do this by asking for the enum's tag separately from its 
payload (pseudocode):

switch getMyOpaqueEnumTag() {
case 0:
  var payload: Int
  getMyOpaqueEnumPayload(, 0, )
  doSomething(payload)
case 1:
  var payload: String
  getMyOpaqueEnumPayload(, 1, )
  doSomethingElse(payload)
default:
  print("unknown case")
}

The tricky part is those constant values "0" and "1". We'd really like them to 
be constants so that the calling code can actually emit a jump table rather 
than a series of chained conditionals, but that means case tags are part of the 
ABI, even for non-exhaustive enums.

Like with struct layout, this means we need a stable ordering for cases. Since 
non-exhaustive enums can have new cases added at any time, we can't do a simple 
alphabetical sort, nor can we do some kind of ordering on the payload types. 
The naive answer, then, is that enum cases cannot be reordered, even in 
non-exhaustive enums. This isn't great, because people like being able to move 
deprecated enum cases to the end of the list, where they're out of the way, but 
it's at least explainable, and consistent with the idea of enums some day 
having a 'cases' property that includes all cases.

Slava and I aren't happy with this, but we haven't thought of another solution 
yet. The rest of this email will describe our previous idea, which has a fatal 
flaw.


Availability Ordering

In a library with binary compatibility concerns, any new API that gets added 
should always be explicitly annotated with an availability attribute. Today 
that looks like this:

@available(macOS 10.13, iOS 11, tvOS 11, watchOS 4, *)

It's a model we only support for Apple platforms, but in theory it's extendable 
to arbitrary "deployments". You ought to be able to say `@available(MagicKit 
5)` and have the compiler actually check that.

Let's say we had this model, and we were using it like this:

public enum SpellKind {
  case hex
  case charm
  case curse
  @available(MagicKit 5)
  case blight
  @available(MagicKit 5.1)
  case jinx
}

"Availability ordering" says that we can derive a canonical ordering from the 
names of cases (which are API) combined with their versions. Since we "know" 
that newly-added cases will always have a newer version than existing cases, we 
can just put the older cases first. In this case, that would give us a 
canonical ordering of [charm, curse, hex, blight, jinx].


The Fatal Flaw

It's time for MagicKit 6 to come out, and we're going to add a new SpellKind:

@available(MagicKit 6)
case summoning
// [charm, curse, hex, blight, jinx, summoning]

We ship out a beta to our biggest clients, but realize we forgot a vital 
feature. Beta 2 comes with another new SpellKind:

@available(MagicKit 6)
case banishing
// [charm, curse, hex, blight, jinx, banishing, summoning]

And now we're in trouble: anything built against the first beta expects 
'summoning' to have tag 5, not 6. Our clients have to recompile everything 
before they can even try out the new version of the library.

Can this be fixed? Sure. We could add support for beta versions to 
`@available`, or fake it somehow with the existing version syntax. But in both 
of these cases, it means you have to know what constitutes a "release", so that 
you can be sure to use a higher number than the previous "release". This could 
be made to work for a single library, but falls down for an entire Apple OS. If 
the Foundation team wants to add a second new enum case while macOS is still in 
beta, they're not going to stop and recompile all of /System/Library/Frameworks 
just to try out their change.

So, availability ordering is great when you have easily divisible "releases", 
but falls down when you want to make a change "during a release".


Salvaging Availability Ordering?

- We could still sort by availability, so that you can reorder the sections but 
not the individual cases in them. That doesn't seem very useful, though.

- We could say "this is probably rare", and state that anything added "in the 
same release" needs to get an explicit annotation for ordering purposes. (This 
is equivalent to the `@abi(2)` Dave Zarzycki mentioned in the previous 
thread—it's not the default but it's there if 

Re: [swift-dev] libdispatch switched to CMake

[Jordan Rose via swift-dev]

> On Sep 25, 2017, at 11:28, Jordan Rose  wrote:
> 
> 
> 
>> On Sep 24, 2017, at 19:32, Saleem Abdulrasool > > wrote:
>> 
>> On Sat, Sep 23, 2017 at 5:02 AM, David P Grove > > wrote:
>> With autotools, the first time libdispatch was built (for SourceKit), it 
>> just did the C build of libdispatch. That had to be blown away and rebuilt a 
>> second time later (once swiftc, etc was available) so that we could build 
>> libdispatch.so with the Swift overlay built into it.
>> 
>> Did you manage to change this so that the first time libdispatch is built it 
>> has a swiftc and Swift standard library it can use for its build?
>> 
>> 
>> Yeah, that double configuration should not be needed.  I'll make that 
>> dependency more explicit and clean up some of the usage in the SourceKit 
>> case.  But, there is no reason to do two different builds here.  The only 
>> bits needed to build dispatch AFAICT, is the swift core library and the 
>> swift compiler.  Even if the swift overlay is required, we can add that 
>> build ordering.  The dispatch overlay is constructed in libdispatch itself.  
>> So, we can just order the compiler build to occur prior to the libdispatch 
>> build, which needs to be built before SourceKit.
>> 
>> Thanks for making me take a second look and notice that the explicit 
>> dependency is missing.
>>  
> 
> Thanks for looking into this, but I feel like the problem has to be something 
> simpler. A completely clean build does this:
> 
> libdispatch: using gold linker
> + /usr/bin/cmake --build 
> /home/jrose/public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64 
> -- -j24 all
> [1/1] cd 
> /home/jrose/public/build/Ninj...s-libdispatch/private/module.modulemap
> foundation: using gold linker
> + pushd /home/jrose/public/swift-corelibs-foundation
> ~/public/swift-corelibs-foundation ~/public/swift
> + env 
> SWIFTC=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swiftc
>  
> CLANG=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/llvm-linux-x86_64/bin/clang
>  
> SWIFT=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swift
>  
> SDKROOT=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64
>  
> BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/foundation-linux-x86_64
>  DSTROOT=/ PREFIX=/usr/ ./configure RelWithDebInfo 
> -DXCTEST_BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/xctest-linux-x86_64
>  -DLIBDISPATCH_SOURCE_DIR=/home/jrose/public/swift-corelibs-libdispatch 
> -DLIBDISPATCH_BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64
> 
> i.e. Dispatch isn't being built at all. This is on an Ubuntu 16.04 system 
> with CMake 3.5.1. My build-script invocation isn't particularly complicated 
> either, and doesn't seem different in any interesting way from what the 
> buildbot is doing:
> 
> utils/build-script -r -t --build-swift-static-stdlib 
> --build-swift-dynamic-stdlib --libdispatch --foundation --xctest 
> --skip-test-swift
> 
> Any ideas?

Aha, passing --reconfigure seems to have made a difference. That implies to me 
that something is incorrectly detecting when CMake generation needs to happen.

Jordan

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

Re: [swift-dev] libdispatch switched to CMake

[Jordan Rose via swift-dev]

> On Sep 24, 2017, at 19:32, Saleem Abdulrasool  wrote:
> 
> On Sat, Sep 23, 2017 at 5:02 AM, David P Grove  > wrote:
> With autotools, the first time libdispatch was built (for SourceKit), it just 
> did the C build of libdispatch. That had to be blown away and rebuilt a 
> second time later (once swiftc, etc was available) so that we could build 
> libdispatch.so with the Swift overlay built into it.
> 
> Did you manage to change this so that the first time libdispatch is built it 
> has a swiftc and Swift standard library it can use for its build?
> 
> 
> Yeah, that double configuration should not be needed.  I'll make that 
> dependency more explicit and clean up some of the usage in the SourceKit 
> case.  But, there is no reason to do two different builds here.  The only 
> bits needed to build dispatch AFAICT, is the swift core library and the swift 
> compiler.  Even if the swift overlay is required, we can add that build 
> ordering.  The dispatch overlay is constructed in libdispatch itself.  So, we 
> can just order the compiler build to occur prior to the libdispatch build, 
> which needs to be built before SourceKit.
> 
> Thanks for making me take a second look and notice that the explicit 
> dependency is missing.
>  

Thanks for looking into this, but I feel like the problem has to be something 
simpler. A completely clean build does this:

libdispatch: using gold linker
+ /usr/bin/cmake --build 
/home/jrose/public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64 -- 
-j24 all
[1/1] cd /home/jrose/public/build/Ninj...s-libdispatch/private/module.modulemap
foundation: using gold linker
+ pushd /home/jrose/public/swift-corelibs-foundation
~/public/swift-corelibs-foundation ~/public/swift
+ env 
SWIFTC=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swiftc
 
CLANG=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/llvm-linux-x86_64/bin/clang
 
SWIFT=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swift
 SDKROOT=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64 
BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/foundation-linux-x86_64
 DSTROOT=/ PREFIX=/usr/ ./configure RelWithDebInfo 
-DXCTEST_BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/xctest-linux-x86_64
 -DLIBDISPATCH_SOURCE_DIR=/home/jrose/public/swift-corelibs-libdispatch 
-DLIBDISPATCH_BUILD_DIR=/home/jrose/public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64

i.e. Dispatch isn't being built at all. This is on an Ubuntu 16.04 system with 
CMake 3.5.1. My build-script invocation isn't particularly complicated either, 
and doesn't seem different in any interesting way from what the buildbot is 
doing:

utils/build-script -r -t --build-swift-static-stdlib 
--build-swift-dynamic-stdlib --libdispatch --foundation --xctest 
--skip-test-swift

Any ideas?

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

Re: [swift-dev] Metadata Representation

[Jordan Rose via swift-dev]

> On Sep 25, 2017, at 09:24, Joe Groff via swift-dev  
> wrote:
> 
> 
> 
>> On Sep 24, 2017, at 10:30 PM, John McCall  wrote:
>> 
>> 
>>> On Sep 22, 2017, at 8:39 PM, Saleem Abdulrasool  
>>> wrote:
>>> 
>>> On Thu, Sep 21, 2017 at 10:28 PM, John McCall  wrote:
>>> 
 On Sep 21, 2017, at 10:10 PM, Saleem Abdulrasool  
 wrote:
 
 On Thu, Sep 21, 2017 at 5:18 PM, John McCall  wrote:
> On Sep 21, 2017, at 1:26 PM, Saleem Abdulrasool via swift-dev 
>  wrote:
> On Thu, Sep 21, 2017 at 12:04 PM, Joe Groff  wrote:
> 
> 
>> On Sep 21, 2017, at 11:49 AM, Saleem Abdulrasool  
>> wrote:
>> 
>> On Thu, Sep 21, 2017 at 10:53 AM, Joe Groff  wrote:
>> 
>> 
>>> On Sep 21, 2017, at 9:32 AM, Saleem Abdulrasool via swift-dev 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> The current layout for the swift metadata for structure types, as 
>>> emitted, seems to be unrepresentable in PE/COFF (at least for x86_64). 
>>> There is a partial listing of the generated code following the message 
>>> for reference.
>>> 
>>> When building the standard library, LLVM encounters a relocation which 
>>> cannot be represented.  Tracking down the relocation led to the type 
>>> metadata for SwiftNSOperatingSystemVersion.  The metadata here is 
>>> _T0SC30_SwiftNSOperatingSystemVersionVN.  At +32-bytes we find the Kind 
>>> (1).  So, this is a struct metadata type.  Thus at Offset 1 (+40 bytes) 
>>> we have the nominal type descriptor reference.  This is the relocation 
>>> which we fail to represent correctly.  If I'm not mistaken, it seems 
>>> that the field is supposed to be a relative offset to the nominal type 
>>> descriptor.  However, currently, the nominal type descriptor is emitted 
>>> in a different section (.rodata) as opposed to the type descriptor 
>>> (.data).  This cross-section relocation cannot be represented in the 
>>> file format.
>>> 
>>> My understanding is that the type metadata will be adjusted during the 
>>> load for the field offsets.  Furthermore, my guess is that the relative 
>>> offset is used to encode the location to avoid a relocation for the 
>>> load address base.  In the case of windows, the based relocations are a 
>>> given, and I'm not sure if there is a better approach to be taken.  
>>> There are a couple of solutions which immediately spring to mind: 
>>> moving the nominal type descriptor into the (RW) data segment and the 
>>> other is to adjust the ABI to use an absolute relocation which would be 
>>> rebased.  Given that the type metadata may be adjusted means that we 
>>> cannot emit it into the RO data segment.  Is there another solution 
>>> that I am overlooking which may be simpler or better?
>> 
>> IIRC, this came up when someone was trying to port Swift to Windows on 
>> ARM as well, and they were able to conditionalize the code so that we 
>> used absolute pointers on Windows/ARM, and we may have to do the same on 
>> Windows in general. It may be somewhat more complicated on Win64 since 
>> we generally assume that relative references can be 32-bit, whereas an 
>> absolute reference will be 64-bit, so some formats may have to change 
>> layout to make this work too. I believe Windows' executable loader still 
>> ultimately maps the final PE image contiguously, so alternatively, you 
>> could conceivably build a Swift toolchain that used ELF or Mach-O or 
>> some other format with better support for PIC as the intermediate object 
>> format and still linked a final PE executable. Using relative references 
>> should still be a win on Windows both because of the size benefit of 
>> being 32-bit and the fact that they don't need to be slid when running 
>> under ASLR or when a DLL needs to be rebased.
>> 
>> 
>> Yeah, I tracked down the relativePointer thing.  There is a nice subtle 
>> little warning that it is not fully portable :-).  Would you happen to 
>> have a pointer to where the adjustment for the absolute pointers on WoA 
>> is?
>> 
>> You are correct that the image should be contiugously mapped on Windows. 
>>  The idea of MachO as an intermediatary is rather intriguing. Thinking 
>> longer term, maybe we want to use that as a global solution?  It would 
>> also provide a nicer autolinking mechanism for ELF which is the one 
>> target which currently is missing this functionality.  However, if Im 
>> not mistaken, this would require a MachO linker (and the only current 
>> viable MachO linker would be ld64).  The MachO binary would then need to 
>> be 

Re: [swift-dev] libdispatch switched to CMake

[Jordan Rose via swift-dev]

Hey, Saleem. I don't build libdispatch that often, but it seems to be broken 
for me. If I delete the libdispatch-specific build directory and then use 
build-script with --reconfigure, it doesn't actually attempt to reconfigure.

[4/50] Performing build step for 'libdispatch'
FAILED: cd 
/home/jrose/public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64 && 
/usr/bin/cmake --build . && /usr/bin/cmake -E touch 
/home/jrose/public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/tools/SourceKit/libdispatch-prefix/src/libdispatch-stamp/libdispatch-build

When I deleted my entire build directory and built from scratch, libdispatch 
built, but Foundation couldn't see it.

Foundation/URLSession/http/HTTPURLProtocol.swift:325:19: error: use of 
undeclared type 'DispatchData'
case data(DispatchData)
  ^~~~

Any ideas what's going wrong?

Thanks,
Jordan


> On Sep 18, 2017, at 15:28, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> Hello swift-dev,
> 
> This change should be transparent to everyone, but, it still is a pretty big 
> milestone.
> 
> As of this afternoon, the non-Darwin builds use CMake to build libdispatch.  
> This work has been underway for quite some time, and we have finally switched 
> to that as the default on most targets.  This should be more or less 
> transparent to everyone developing with build-script or even invoking CMake 
> for swift directly.
> 
> This simplifies some of the logic for integrating the projects and avoid 
> unnecessary commands from being run.
> 
> Thanks particularly to Michael Gottesman, Chris Bieneman, Daniel Steffen, 
> David Grove, and Pierre Habouzit.  Sorry if I accidentally left someone off 
> the list!
> 
> Saleem
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> ___
> 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] History of build-script, build-script-impl, and CMake?

[Jordan Rose via swift-dev]

Heh. Let's see:

> On Sep 8, 2017, at 08:14, Brian Gesiak via swift-dev  
> wrote:
> 
> Hello all,
> 
> I'm hoping a long-time Swift contributor can help shed some light on
> how the apple/swift repository ended up with a utils/build-script, a
> utils/build-script-impl, and CMake files.
> 
> Based on the Git history, I've pieced together the following:
> 
> - July 17, 2010: Chris Lattner first adds a Makefile to apple/swift in
> his initial checkin. Until its eventual removal in 2014, the Makefile
> only ever built apple/swift, and it required users to have built LLVM
> in advance. [1].

1. Makefiles are easy, but…

> - July 14, 2011: Doug Gregor adds CMake files to build apple/swift [2].

2. …LLVM standardized on CMake. (And this gave us both Ninja and Xcode support.)

> - February 6, 2013: Joe Groff adds utils/buildbot-script.sh. This
> appears very similar to the modern-day uitls/build-script-impl. It
> configures and builds LLVM, Clang, and Swift [3].

3. This one really was for buildbots to have a standard configuration, but it's 
possible people were using it locally as well. There were also a lot of 
homegrown scripts at this time, and then people like me just used CMake 
directly.

> - February 25, 2014: Ted Kremenek removes the original Makefile Chris
> added in 2010. I believe only CMake-based builds became possible as of
> this point [4].

4. Yeah, nobody cared by this point.

> - December 23, 2014: Dmitri Gribenko (now no longer working on the
> project at Apple) rewrites a large portion of the CMake files, and
> deletes utils/buildbot-script.sh [5].
> - October 30, 2015: Ashley Gardland "adds back" a bunch of build
> files, including utils/build-script and utils/build-script-impl [6].


5/6. This is actually a misdirection! [5] is when build-script appeared, as 
part of a big push to get everyone building using the same tool. All the 
buildbots had their presets recorded in the build-presets file, which was the 
biggest win: if your own configuration didn't reproduce something, you didn't 
have to crawl int Jenkins to figure out what was different. And the Python was, 
in theory, much more maintainable than the increasingly-esoteric shell code 
used in build-script-impl (formerly buildbot-script.sh). That's why we had the 
task to migrate everything into Python, even though we never quite managed it.

The trouble was that we also had a bunch of Apple-internal configuration mixed 
in here. Rather than try to separate out the Apple and non-Apple parts in the 
commit log, we just removed it from the SVN history, took out the Apple parts, 
and then stuck in back in wholesale. That's [6].

(also, "Garland" ;-) )


So your guesses are all pretty much on the nose. The other thing that's 
cemented build-script and build-script-impl, though, is that they handle 
building multiple projects, even those with non-LLVMish build systems. (There's 
long been an advantage for Xcode users to build LLVM/Clang and Swift 
separately, but for things like swiftpm and swift-corelibs-foundation we'd 
never have a chance. And even LLDB is only just recently building like the 
other LLVM projects, if I remember correctly.)

Jordan

> 
> Could someone familiar with the apple/swift project during the years
> 2010 until 2015 shed some light on how the project was built during
> this time? Specifically:
> 
> - Did most developers use the Makefile? What replaced the Makefile?
> Did developers configure and build LLVM and Clang themselves,
> manually, without using a script?
> - Was the utils/buildbot-script.sh the precursor for
> utils/build-script and utils/build-script-impl?
> - What were the files that were "added back" in [6]? Did they exist in
> some form internally to Apple? Were they used by project developers at
> the time, or were they written solely for the benefit of external,
> open-source contributors?
> - Why do both utils/build-script and utils/build-script-impl exist?
> The fact that they were "added back" makes me think that they grew
> over time, and so were not written for the first time as part of the
> commit in [6].
> 
> Thanks in advance to anyone who can indulge my curiosity here! :)
> 
> - Brian Gesiak
> 
> [1] 
> https://github.com/apple/swift/commit/afc81c1855bf711315b8e5de02db138d3d487eeb
> [2] 
> https://github.com/apple/swift/commit/86ab76d62468241e03029e3e0790e4a0c8fbe3c1
> [3] 
> https://github.com/apple/swift/commit/482826925812c8aa6d7ef861adbe36b26a4dedda
> [4] 
> https://github.com/apple/swift/commit/f383eb90abc0afd6f78c7589005b61916e314870
> [5] 
> https://github.com/apple/swift/commit/6670bb76ecc71a35ac5fa8f54cb81de6f555072f
> [6] 
> https://github.com/apple/swift/commit/4ac9c80809450e4566946f40bbdb639b2ba745d8
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

In 
>>>>> particular, I think that trying to make ABI attributes too convenient 
>>>>> only does programmers a disservice in the long run because most 
>>>>> programmers aren't experts, and the cost of ignorance is huge when trying 
>>>>> to do ABI design.
>>>>> 
>>>>> With these thoughts in mind, I think that is reasonable for the language 
>>>>> to say: “If you want explicit control over a dimension of ABI decisions, 
>>>>> then you must deal with all of the associated complexity. Here is a 
>>>>> pointer to the documentation on dimension X that you were/are trying to 
>>>>> explicitly manage. If that is ’too hard’ for you, then you probably 
>>>>> shouldn’t be locking down this dimension of complexity yet.”
>>>>> 
>>>>> Dave
>>>>> 
>>>>>> On Sep 5, 2017, at 20:11, Jordan Rose <jordan_r...@apple.com 
>>>>>> <mailto:jordan_r...@apple.com>> wrote:
>>>>>> 
>>>>>> Hm. This is definitely an option, but I don't think it's really an 
>>>>>> acceptable user experience. This feels like it'll drive people all the 
>>>>>> way to declaring their types in C because Swift makes it too hard.
>>>>>> 
>>>>>> We do expect to have a tool to diff old and new modules at some point, 
>>>>>> but we could do something even simpler here: make a public symbol with 
>>>>>> the struct's layout in its name. That way, even 'nm' can tell if the 
>>>>>> symbol disappears. (Of course, public symbols do have a small cost, 
>>>>>> since this might not actually be the best idea.)
>>>>>> 
>>>>>> Another idea would be to restrict @fixedContents to require that all 
>>>>>> stored properties appear contiguously in the struct, possibly even 
>>>>>> pinned to the top or bottom, to indicate that order's not completely 
>>>>>> arbitrary. Again, that's just an improvement, not full protection.
>>>>>> 
>>>>>> Jordan
>>>>>> 
>>>>>> 
>>>>>>> On Sep 5, 2017, at 13:00, David Zarzycki <zarzy...@icloud.com 
>>>>>>> <mailto:zarzy...@icloud.com>> wrote:
>>>>>>> 
>>>>>>> Hi Jordan,
>>>>>>> 
>>>>>>> Thanks for thinking about this. For whatever it may be worth, I’m 
>>>>>>> concerned about 1) the ability to reorder declarations and 2) the 
>>>>>>> “either/or” nature of this proposal.
>>>>>>> 
>>>>>>> First, reordering: The ability to reorder declarations is deeply 
>>>>>>> ingrained into the subconsciousness of Swift programmers and for good 
>>>>>>> reasons. I think adding localized declaration order sensitivity is 
>>>>>>> likely to be very brittle and regrettable in the long run. I also think 
>>>>>>> this problem is made worse by having a type declaration context 
>>>>>>> attribute because it can easily get lost in the noise of nontrivial 
>>>>>>> declarations. The net result is that people will frequently forget 
>>>>>>> about local order sensitivity. Yes, the compiler can engage in heroics 
>>>>>>> and compare the previous module ABI and the new module ABI for 
>>>>>>> conflicts, but that seems risky, complex, slow, and differently error 
>>>>>>> prone.
>>>>>>> 
>>>>>>> Second, the “either/or” nature of this proposal: What do you think 
>>>>>>> about a lightweight “belt and suspenders” solution whereby 
>>>>>>> @fixedContents requires that stored properties be lightly annotated 
>>>>>>> with their layout order? For example:
>>>>>>> 
>>>>>>> @fixedContents(3) struct Foo {
>>>>>>>   @abi(0) var x: Int
>>>>>>>   func a() {
>>>>>>> // a thousand lines of ABI layout distraction
>>>>>>>   }
>>>>>>>   @abi(1) var y: Double
>>>>>>>   func b() {
>>>>>>> // another thousand lines of ABI layout distraction
>>>>>>>   }
>>>>>>>   @abi(2) var z: String
>>>>>>> }
>>>>>>> 
>>>&

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

gt;> 
>>>>> On Sep 5, 2017, at 13:00, David Zarzycki <zarzy...@icloud.com 
>>>>> <mailto:zarzy...@icloud.com>> wrote:
>>>>> 
>>>>> Hi Jordan,
>>>>> 
>>>>> Thanks for thinking about this. For whatever it may be worth, I’m 
>>>>> concerned about 1) the ability to reorder declarations and 2) the 
>>>>> “either/or” nature of this proposal.
>>>>> 
>>>>> First, reordering: The ability to reorder declarations is deeply 
>>>>> ingrained into the subconsciousness of Swift programmers and for good 
>>>>> reasons. I think adding localized declaration order sensitivity is likely 
>>>>> to be very brittle and regrettable in the long run. I also think this 
>>>>> problem is made worse by having a type declaration context attribute 
>>>>> because it can easily get lost in the noise of nontrivial declarations. 
>>>>> The net result is that people will frequently forget about local order 
>>>>> sensitivity. Yes, the compiler can engage in heroics and compare the 
>>>>> previous module ABI and the new module ABI for conflicts, but that seems 
>>>>> risky, complex, slow, and differently error prone.
>>>>> 
>>>>> Second, the “either/or” nature of this proposal: What do you think about 
>>>>> a lightweight “belt and suspenders” solution whereby @fixedContents 
>>>>> requires that stored properties be lightly annotated with their layout 
>>>>> order? For example:
>>>>> 
>>>>> @fixedContents(3) struct Foo {
>>>>>   @abi(0) var x: Int
>>>>>   func a() {
>>>>> // a thousand lines of ABI layout distraction
>>>>>   }
>>>>>   @abi(1) var y: Double
>>>>>   func b() {
>>>>> // another thousand lines of ABI layout distraction
>>>>>   }
>>>>>   @abi(2) var z: String
>>>>> }
>>>>> 
>>>>> That would enable both renaming and reordering, would it not? This 
>>>>> approach would also aid the compiler in quickly detecting hastily 
>>>>> added/deleted declarations too because the count of @abi([0-9]+) 
>>>>> declarations wouldn’t match the number passed to @fixedContents.
>>>>> 
>>>>> Dave
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sep 5, 2017, at 14:59, Jordan Rose via swift-dev <swift-dev@swift.org 
>>>>>> <mailto:swift-dev@swift.org>> wrote:
>>>>>> 
>>>>>> Hey, all. In preparation for the several proposals we have to come this 
>>>>>> year, I cleaned up docs/LibraryEvolution.rst 
>>>>>> <https://github.com/apple/swift/pull/11742> a little bit based on what's 
>>>>>> changed in Swift 4. This is mostly just mentioning things about generic 
>>>>>> subscripts, but there is one issue that I remember John bringing up some 
>>>>>> time in this past year: once you've made a struct fixed-contents, what 
>>>>>> can you change about its stored properties?
>>>>>> 
>>>>>>> To opt out of this flexibility, a struct may be marked 
>>>>>>> '@fixedContents'. This promises that no stored properties will be added 
>>>>>>> to or removed from the struct, even non-public ones.
>>>>>> 
>>>>>> Interestingly, this means that you can have non-public members of a 
>>>>>> fixed-contents struct. This is actually pretty sensible: it's the 
>>>>>> equivalent of a C++ class with non-public fields but a defaulted, 
>>>>>> inlinable copy constructor. Any inlinable members can access these 
>>>>>> properties directly as well; it's just outsiders that can't see them. 
>>>>>> But if inlinable code can reference these things, and if we really want 
>>>>>> them to be fast, that means they have to have a known offset at 
>>>>>> compile-time.
>>>>>> 
>>>>>> Now, we don't plan to stick to C's layout for structs, even 
>>>>>> fixed-contents structs. We'd really like users to not worry about 
>>>>>> manually packing things into trailing alignment space. But we still need 
>>>>>> a way to lay out fields consistently; if you have two stored properties 
>>>>>&g

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

I'd be okay with allowing the ABI attributes to control ordering, but I would 
definitely not require them on every fixed-contents struct. We hope making a 
struct fixed-contents isn't something people have to do too often, but we don't 
want to drop them all the way into "hard" land when they do it. That is, 
"CGPoint" can't already be "hard mode".

Jordan


> On Sep 6, 2017, at 05:13, David Zarzycki <zarzy...@icloud.com> wrote:
> 
> Hi Jordan,
> 
> I really doubt that “belt and suspenders” ABI attributes would drive people 
> to C, but reasonable people can certainly disagree on that.
> 
> Bertrand, when he was at Apple, used to say that “easy things should be easy, 
> and hard things should be possible”.
> 
> I think ABI related attributes fall into the latter category. In particular, 
> I think that trying to make ABI attributes too convenient only does 
> programmers a disservice in the long run because most programmers aren't 
> experts, and the cost of ignorance is huge when trying to do ABI design.
> 
> With these thoughts in mind, I think that is reasonable for the language to 
> say: “If you want explicit control over a dimension of ABI decisions, then 
> you must deal with all of the associated complexity. Here is a pointer to the 
> documentation on dimension X that you were/are trying to explicitly manage. 
> If that is ’too hard’ for you, then you probably shouldn’t be locking down 
> this dimension of complexity yet.”
> 
> Dave
> 
>> On Sep 5, 2017, at 20:11, Jordan Rose <jordan_r...@apple.com 
>> <mailto:jordan_r...@apple.com>> wrote:
>> 
>> Hm. This is definitely an option, but I don't think it's really an 
>> acceptable user experience. This feels like it'll drive people all the way 
>> to declaring their types in C because Swift makes it too hard.
>> 
>> We do expect to have a tool to diff old and new modules at some point, but 
>> we could do something even simpler here: make a public symbol with the 
>> struct's layout in its name. That way, even 'nm' can tell if the symbol 
>> disappears. (Of course, public symbols do have a small cost, since this 
>> might not actually be the best idea.)
>> 
>> Another idea would be to restrict @fixedContents to require that all stored 
>> properties appear contiguously in the struct, possibly even pinned to the 
>> top or bottom, to indicate that order's not completely arbitrary. Again, 
>> that's just an improvement, not full protection.
>> 
>> Jordan
>> 
>> 
>>> On Sep 5, 2017, at 13:00, David Zarzycki <zarzy...@icloud.com 
>>> <mailto:zarzy...@icloud.com>> wrote:
>>> 
>>> Hi Jordan,
>>> 
>>> Thanks for thinking about this. For whatever it may be worth, I’m concerned 
>>> about 1) the ability to reorder declarations and 2) the “either/or” nature 
>>> of this proposal.
>>> 
>>> First, reordering: The ability to reorder declarations is deeply ingrained 
>>> into the subconsciousness of Swift programmers and for good reasons. I 
>>> think adding localized declaration order sensitivity is likely to be very 
>>> brittle and regrettable in the long run. I also think this problem is made 
>>> worse by having a type declaration context attribute because it can easily 
>>> get lost in the noise of nontrivial declarations. The net result is that 
>>> people will frequently forget about local order sensitivity. Yes, the 
>>> compiler can engage in heroics and compare the previous module ABI and the 
>>> new module ABI for conflicts, but that seems risky, complex, slow, and 
>>> differently error prone.
>>> 
>>> Second, the “either/or” nature of this proposal: What do you think about a 
>>> lightweight “belt and suspenders” solution whereby @fixedContents requires 
>>> that stored properties be lightly annotated with their layout order? For 
>>> example:
>>> 
>>> @fixedContents(3) struct Foo {
>>>   @abi(0) var x: Int
>>>   func a() {
>>> // a thousand lines of ABI layout distraction
>>>   }
>>>   @abi(1) var y: Double
>>>   func b() {
>>> // another thousand lines of ABI layout distraction
>>>   }
>>>   @abi(2) var z: String
>>> }
>>> 
>>> That would enable both renaming and reordering, would it not? This approach 
>>> would also aid the compiler in quickly detecting hastily added/deleted 
>>> declarations too because the count of @abi([0-9]+) declarations wouldn’t 
>>> match the number passed to @fixedContents.
>>> 
>

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

> On Sep 5, 2017, at 18:37, Nevin Brackett-Rozinsky via swift-dev 
>  wrote:
> 
> On Tue, Sep 5, 2017 at 6:08 PM, Slava Pestov via swift-dev 
> > wrote:
> We expect that “define your struct in C” is still the way to go for layout 
> compatibility with other languages and systems.
> 
> Are there plans (however tentative) to eventually make it possible to specify 
> the exact memory layout of a struct in Swift?
> 
> It seems like something we will have to tackle in order for Swift to become a 
> serious systems-level programming language.

There's nothing inherently wrong with having a 'packedLayout' attribute or 
similar (as long as the compiler can enforce alignment requirements for 
non-trivial types), but neither is it urgent since you can do the same thing in 
C. It's a feature that can be added at any time, just not to existing 
fixed-contents structs.

Jordan

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

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

> On Sep 5, 2017, at 15:52, Greg Parker <gpar...@apple.com> wrote:
> 
> 
>> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev <swift-dev@swift.org 
>> <mailto:swift-dev@swift.org>> wrote:
>> 
>> Hey, all. In preparation for the several proposals we have to come this 
>> year, I cleaned up docs/LibraryEvolution.rst 
>> <https://github.com/apple/swift/pull/11742> a little bit based on what's 
>> changed in Swift 4. This is mostly just mentioning things about generic 
>> subscripts, but there is one issue that I remember John bringing up some 
>> time in this past year: once you've made a struct fixed-contents, what can 
>> you change about its stored properties?
>> 
>>> To opt out of this flexibility, a struct may be marked '@fixedContents'. 
>>> This promises that no stored properties will be added to or removed from 
>>> the struct, even non-public ones.
>> 
>> Interestingly, this means that you can have non-public members of a 
>> fixed-contents struct. This is actually pretty sensible: it's the equivalent 
>> of a C++ class with non-public fields but a defaulted, inlinable copy 
>> constructor. Any inlinable members can access these properties directly as 
>> well; it's just outsiders that can't see them. But if inlinable code can 
>> reference these things, and if we really want them to be fast, that means 
>> they have to have a known offset at compile-time.
>> 
>> Now, we don't plan to stick to C's layout for structs, even fixed-contents 
>> structs. We'd really like users to not worry about manually packing things 
>> into trailing alignment space. But we still need a way to lay out fields 
>> consistently; if you have two stored properties with the same type, one of 
>> them has to go first. There are two ways to do this: sort by name, and sort 
>> by declaration order. That means we can either allow reordering or allow 
>> renaming, but not both. Which do people think is more important?
>> 
>> At the moment I'm inclined to go with "allow renaming" just because that's 
>> what C does. It's not great because you're allowed to reorder nearly 
>> everything else in the language, but there's a "least surprise" principle 
>> here that I think is still useful. It'd be surprising for the name of a 
>> non-public property to affect your library's ABI.
> 
> In a somewhat similar semantic situation, Objective-C non-fragile ivars chose 
> to allow reordering and disallow renaming. One reason is that we wanted to 
> prevent accidental ABI breaks as best we could. The assumption was that a 
> name change is probably deliberate, but an order change is likely to be an 
> accidental effect of source code rearrangement. In addition, erroneous name 
> changes are more likely to be caught downstream (for example when clients 
> fail to build because they didn't change their use of the name), but 
> erroneous order changes are less likely to be caught later.
> 
> The goal of preventing accidental ABI breaks becomes less important if Swift 
> gets good ABI-diffing tools that can help catch errors after they are 
> introduced. ObjC had no effective way to verify that your current ABI matched 
> your previously-published ABI.

Good point. One slight difference here is that if you do break the ABI with 
non-fragile ivars, it only matters if there are direct references to them from 
outside the library. For @fixedContents structs, the client may have direct 
references to any fields, even the non-public ones, in order to properly 
implement the value copy operation.

Jordan

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

Re: [swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

> On Sep 5, 2017, at 15:08, Slava Pestov via swift-dev  
> wrote:
> 
>> 
>> On Sep 5, 2017, at 2:48 PM, Thomas Roughton via swift-dev 
>> > wrote:
>> 
>> Having an explicit @abi annotation could also go some way to addressing the 
>> issue of manual layout with structs. I’m primarily thinking of graphics 
>> contexts, wherein you need to declare e.g. a struct with vertex layout, and 
>> then that needs to be specified when passed to the GPU. The current solution 
>> is to declare in C code and import into Swift, which is cumbersome; having 
>> @fixedContents structs be the method of choice when a deterministic layout 
>> is needed seems to make sense. If combined with a hypothetical 
>> MemoryLayout.offsetOf(property) Swift would, I think, meet that need.
> 
> @fixedContents is not meant for this purpose. We don’t want to guarantee that 
> the layout matches what you would write in C. Of course once the ABI is 
> stable, the layout of a fixed contents struct will be fixed — it just might 
> not be what your GPU expects.
> 
> So perhaps @fixedContents is not the best name. We expect that “define your 
> struct in C” is still the way to go for layout compatibility with other 
> languages and systems.

Right. The hypothetical 'abi' attribute that Dave mentions is "just" a stable 
identifier that can be used instead of "name" or "declaration order", rather 
than something that can control layout.

We did say that the layout of a tuple that contains C-compatible types will 
always match the layout of an equivalent C struct, so if you need a guaranteed 
layout in Swift you can do it that way too. But Slava's right that it's 
probably easiest to just define your struct in C.

Jordan

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

[swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose via swift-dev]

Hey, all. In preparation for the several proposals we have to come this year, I 
cleaned up docs/LibraryEvolution.rst 
 a little bit based on what's 
changed in Swift 4. This is mostly just mentioning things about generic 
subscripts, but there is one issue that I remember John bringing up some time 
in this past year: once you've made a struct fixed-contents, what can you 
change about its stored properties?

> To opt out of this flexibility, a struct may be marked '@fixedContents'. This 
> promises that no stored properties will be added to or removed from the 
> struct, even non-public ones.

Interestingly, this means that you can have non-public members of a 
fixed-contents struct. This is actually pretty sensible: it's the equivalent of 
a C++ class with non-public fields but a defaulted, inlinable copy constructor. 
Any inlinable members can access these properties directly as well; it's just 
outsiders that can't see them. But if inlinable code can reference these 
things, and if we really want them to be fast, that means they have to have a 
known offset at compile-time.

Now, we don't plan to stick to C's layout for structs, even fixed-contents 
structs. We'd really like users to not worry about manually packing things into 
trailing alignment space. But we still need a way to lay out fields 
consistently; if you have two stored properties with the same type, one of them 
has to go first. There are two ways to do this: sort by name, and sort by 
declaration order. That means we can either allow reordering or allow renaming, 
but not both. Which do people think is more important?

At the moment I'm inclined to go with "allow renaming" just because that's what 
C does. It's not great because you're allowed to reorder nearly everything else 
in the language, but there's a "least surprise" principle here that I think is 
still useful. It'd be surprising for the name of a non-public property to 
affect your library's ABI.

(In theory we could also make different decisions for public and non-public 
fields, because it's much less likely to want to change the name of a public 
property. But you could do it without breaking source compatibility by 
introducing a computed property at the same time as you do the renaming. It's 
up to us whether that should break binary compatibility or not.)


Note that because the layout algorithm isn't public, Swift isn't going to allow 
the thing from C where you have an existing field and you split it into two 
smaller fields. You can use computed properties for that instead. (Strictly 
speaking this probably isn't even good C because the fields in your struct can 
affect by-value calling conventions.)


By the way, I'm putting this on swift-dev because we're nowhere near a proposal 
and I want to keep the discussion narrow for now, but of course this point will 
be called out when the fixed-contents attribute—whatever its final form—goes to 
swift-evolution for a proper review.

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

Re: [swift-dev] Type inference failing to solve Collection's associated types in protocol extensions

[Jordan Rose via swift-dev]

Hi, Dimitri. The Swift compiler always tries to choose the most specific 
function when it tries to satisfy protocol requirements. In your case, that 
means it's going to prefer members defined in concrete types over members 
defined in protocol extensions. Unfortunately I think that means you're not 
getting the Collection you expect—the "additional" subscript becomes the "more 
specific" one, and the compiler decides that the collection Element should be 
'String?'. As you noted, you can use typealiases to explicitly control that and 
keep the compiler from having to guess.

Hope that clears things up,
Jordan


> On Sep 4, 2017, at 03:41, Dimitri Racordon via swift-dev 
>  wrote:
> 
> Hello fellow Swift enthusiasts.
> 
> I’m struggling to understand why type inference fails to solve Collection s 
> associated types while trying to provide it with a default implementation, 
> via protocol extensions, when an additional subscript is provided. Here is a 
> minimal example:
> 
> protocol SearchTree: Collection {
> subscript(key: Int) -> String? { get }
> }
> 
> extension SearchTree {
> // MARK: Conformance to Sequence
> func makeIterator() -> AnyIterator<(key: Int, value: String)> {
> return AnyIterator { nil }
> }
> 
> // MARK: Conformance to Collection
> var startIndex: Int { return 0 }
> var endIndex: Int { return 0 }
> func index(after i: Int) -> Int { return 0 }
> subscript(key: Int) -> (key: Int, value: String) { return (0, "") }
> 
> // MARK: Conformance to SearchTree
> subscript(key: Int) -> String? { return nil }
> }
> 
> struct ConformingTree: SearchTree {
> }
> 
> Swift’s compiler complains that ConformingTree doesn’t conform to Collection. 
> But it doesn’t say a word if I either remove the additional subscript `(key: 
> Int) -> String?`, or if I push the declaration of the subscript in 
> ConformingTree.
> 
> I asked this question on StackOverflow 
> (https://stackoverflow.com/questions/46028205 
> ), and was kindly taught that I 
> should specify associated types in the protocol (or in the extension via type 
> aliases) because the type inference was getting confused determining the type 
> of Collection.Element, having to deal with two subscripts. What I still don’t 
> understand is why the type inference doesn’t need such explicit additional 
> information when the implementation of SearchTree’s requirement is placed in 
> the concrete type.
> 
> Could anyone enlighten me on this?
> 
> Thanks a lot for your time.
> Best regards.
> 
> Dimitri Racordon
> CUI, Université de Genève
> 7, route de Drize, CH-1227 Carouge - Switzerland
> Phone: +41 22 379 01 24
> 
> 
> 
> 
> ___
> 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] Building and Generating Xcode project for Swift source code

[Jordan Rose via swift-dev]

Hm, any chance there are spaces or slashes in "(base path)"? Maybe we forgot to 
quote something again.

Jordan


> On Sep 5, 2017, at 09:23, Alwyn Concessao via swift-dev  
> wrote:
> 
> Hey Swift enthusiasts,
> 
> I'm  stuck with building the swift source code and generating the Xcode 
> project from Apple's Swift GitHub repository.I'm using Xcode beta-6 as 
> mentioned in the Github page but getting the below mentioned error - 
> 
> -- Build files have been written to: (base 
> path)/swift-source/build/Xcode-DebugAssert/llvm-macosx-x86_64
> + popd
> ~/desktop/swift-source
> usage: dirname path
> ./swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 1, aborting
> 
> Xcode projects for only mark and llvm are generated in 
> build/Xcode-DebugAssert after the build.
> 
> Any ideas as to what could be happening and how to fix the above error?
> 
> Thank you!
> 
> Regards,
> Alwyn
> 
> ___
> 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] ToT failing to build?

[Jordan Rose via swift-dev]

Hm. The benchmark targets don't seem to be passing a -module-cache-path option, 
so it's going to be buried in your /var/folders directory. Here you go:

rm -rf $(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang*

Jordan


> On Aug 30, 2017, at 13:54, David Zarzycki  wrote:
> 
> Hi Jordan,
> 
> Thanks for the quick response. Here you go:
> 
>   https://bugs.swift.org/browse/SR-5805 
> 
> 
> How do I clear the cache again?
> 
> Thanks!
> Dave
> 
> 
>> On Aug 30, 2017, at 16:35, Jordan Rose > > wrote:
>> 
>> Crashes in clang::ASTReader usually mean "clear your module cache". That 
>> does mean there's a bug, though, that we're not putting the revision numbers 
>> into the module hash. Mind filing an SR to track that, since I thought we 
>> were?
>> 
>> Jordan
>> 
>> 
>>> On Aug 30, 2017, at 13:30, David Zarzycki via swift-dev 
>>> > wrote:
>>> 
>>> Anybody else seeing top-of-tree (af34e394e7) fail to build? I’m on macOS 
>>> 17A358a with Xcode 9M214v (beta 6) and building like so:
>>> 
>>> ./utils/build-script --build-subdir="$(dirname $PWD)/t" 
>>> --llvm-targets-to-build X86 --skip-ios --skip-tvos --skip-watchos -r
>>> 
>>> The build crash is below. Any ideas?
>>> 
>>> 
>>> swiftc -c -sdk 
>>> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>>>  -target x86_64-apple-macosx10.9 -F 
>>> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/../../../Developer/Library/Frameworks
>>>  -O -no-link-objc-runtime -force-single-frontend-invocation 
>>> -parse-as-library -module-name DriverUtils -emit-module -emit-module-path 
>>> /Volumes/data/wt/master/t/swift-macosx-x86_64/benchmark/O-x86_64-apple-macosx10.9/DriverUtils.swiftmodule
>>>  -o 
>>> /Volumes/data/wt/master/t/swift-macosx-x86_64/benchmark/O-x86_64-apple-macosx10.9/DriverUtils.o
>>>  /Volumes/data/wt/master/swift/benchmark/utils/DriverUtils.swift 
>>> /Volumes/data/wt/master/swift/benchmark/utils/ArgParse.swift
>>> Assertion failed: (idx < size()), function operator[], file 
>>> /Volumes/data/wt/master/llvm/include/llvm/ADT/SmallVector.h, line 153.
>>> 0  swift0x0001102a0a38 
>>> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
>>> 1  swift0x00011029f986 
>>> llvm::sys::RunSignalHandlers() + 86
>>> 2  swift0x0001102a0ffe SignalHandler(int) + 366
>>> 3  libsystem_platform.dylib 0x7fff59b53f5a _sigtramp + 26
>>> 4  libsystem_platform.dylib 0x0001140f9588 _sigtramp + 3126482504
>>> 5  libsystem_c.dylib0x7fff5997f32a abort + 127
>>> 6  libsystem_c.dylib0x7fff59947380 basename_r + 0
>>> 7  swift0x00010f7adb4a 
>>> clang::ASTReader::ReadString(llvm::SmallVector 
>>> const&, unsigned int&) + 682
>>> 8  swift0x00010f79fc0e 
>>> clang::ASTReader::ParseLanguageOptions(llvm::SmallVector>> long, 64u> const&, bool, clang::ASTReaderListener&, bool) + 12110
>>> 9  swift0x00010f79cbda 
>>> clang::ASTReader::ReadOptionsBlock(llvm::BitstreamCursor&, unsigned int, 
>>> bool, clang::ASTReaderListener&, std::__1::basic_string>> std::__1::char_traits, std::__1::allocator >&) + 250
>>> 10 swift0x00010f7a1628 
>>> clang::ASTReader::ReadControlBlock(clang::serialization::ModuleFile&, 
>>> llvm::SmallVectorImpl&, 
>>> clang::serialization::ModuleFile const*, unsigned int) + 1048
>>> 11 swift0x00010f7a371d 
>>> clang::ASTReader::ReadASTCore(llvm::StringRef, 
>>> clang::serialization::ModuleKind, clang::SourceLocation, 
>>> clang::serialization::ModuleFile*, 
>>> llvm::SmallVectorImpl&, long long, long, 
>>> clang::ASTFileSignature, unsigned int) + 2253
>>> 12 swift0x00010f7af1a8 
>>> clang::ASTReader::ReadAST(llvm::StringRef, 
>>> clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, 
>>> llvm::SmallVectorImpl*) + 296
>>> 13 swift0x00010f51633e 
>>> clang::CompilerInstance::loadModule(clang::SourceLocation, 
>>> llvm::ArrayRef>> clang::SourceLocation> >, clang::Module::NameVisibilityKind, bool) + 1886
>>> 14 swift0x00010e30d9a0 
>>> swift::ClangImporter::loadModule(swift::SourceLoc, 
>>> llvm::ArrayRef 
>>> >)::$_4::operator()(llvm::ArrayRef>> clang::SourceLocation> >, bool) const + 640
>>> 15 swift0x00010e30d58e 
>>> swift::ClangImporter::loadModule(swift::SourceLoc, 
>>> llvm::ArrayRef >) + 462
>>> 16 swift0x00010e3df8a3 
>>> 

Re: [swift-dev] ToT failing to build?

[Jordan Rose via swift-dev]

Crashes in clang::ASTReader usually mean "clear your module cache". That does 
mean there's a bug, though, that we're not putting the revision numbers into 
the module hash. Mind filing an SR to track that, since I thought we were?

Jordan


> On Aug 30, 2017, at 13:30, David Zarzycki via swift-dev  
> wrote:
> 
> Anybody else seeing top-of-tree (af34e394e7) fail to build? I’m on macOS 
> 17A358a with Xcode 9M214v (beta 6) and building like so:
> 
> ./utils/build-script --build-subdir="$(dirname $PWD)/t" 
> --llvm-targets-to-build X86 --skip-ios --skip-tvos --skip-watchos -r
> 
> The build crash is below. Any ideas?
> 
> 
> swiftc -c -sdk 
> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>  -target x86_64-apple-macosx10.9 -F 
> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/../../../Developer/Library/Frameworks
>  -O -no-link-objc-runtime -force-single-frontend-invocation -parse-as-library 
> -module-name DriverUtils -emit-module -emit-module-path 
> /Volumes/data/wt/master/t/swift-macosx-x86_64/benchmark/O-x86_64-apple-macosx10.9/DriverUtils.swiftmodule
>  -o 
> /Volumes/data/wt/master/t/swift-macosx-x86_64/benchmark/O-x86_64-apple-macosx10.9/DriverUtils.o
>  /Volumes/data/wt/master/swift/benchmark/utils/DriverUtils.swift 
> /Volumes/data/wt/master/swift/benchmark/utils/ArgParse.swift
> Assertion failed: (idx < size()), function operator[], file 
> /Volumes/data/wt/master/llvm/include/llvm/ADT/SmallVector.h, line 153.
> 0  swift0x0001102a0a38 
> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
> 1  swift0x00011029f986 llvm::sys::RunSignalHandlers() 
> + 86
> 2  swift0x0001102a0ffe SignalHandler(int) + 366
> 3  libsystem_platform.dylib 0x7fff59b53f5a _sigtramp + 26
> 4  libsystem_platform.dylib 0x0001140f9588 _sigtramp + 3126482504
> 5  libsystem_c.dylib0x7fff5997f32a abort + 127
> 6  libsystem_c.dylib0x7fff59947380 basename_r + 0
> 7  swift0x00010f7adb4a 
> clang::ASTReader::ReadString(llvm::SmallVector 
> const&, unsigned int&) + 682
> 8  swift0x00010f79fc0e 
> clang::ASTReader::ParseLanguageOptions(llvm::SmallVector 64u> const&, bool, clang::ASTReaderListener&, bool) + 12110
> 9  swift0x00010f79cbda 
> clang::ASTReader::ReadOptionsBlock(llvm::BitstreamCursor&, unsigned int, 
> bool, clang::ASTReaderListener&, std::__1::basic_string std::__1::char_traits, std::__1::allocator >&) + 250
> 10 swift0x00010f7a1628 
> clang::ASTReader::ReadControlBlock(clang::serialization::ModuleFile&, 
> llvm::SmallVectorImpl&, 
> clang::serialization::ModuleFile const*, unsigned int) + 1048
> 11 swift0x00010f7a371d 
> clang::ASTReader::ReadASTCore(llvm::StringRef, 
> clang::serialization::ModuleKind, clang::SourceLocation, 
> clang::serialization::ModuleFile*, 
> llvm::SmallVectorImpl&, long long, long, 
> clang::ASTFileSignature, unsigned int) + 2253
> 12 swift0x00010f7af1a8 
> clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, 
> clang::SourceLocation, unsigned int, 
> llvm::SmallVectorImpl*) + 296
> 13 swift0x00010f51633e 
> clang::CompilerInstance::loadModule(clang::SourceLocation, 
> llvm::ArrayRef 
> >, clang::Module::NameVisibilityKind, bool) + 1886
> 14 swift0x00010e30d9a0 
> swift::ClangImporter::loadModule(swift::SourceLoc, 
> llvm::ArrayRef 
> >)::$_4::operator()(llvm::ArrayRef clang::SourceLocation> >, bool) const + 640
> 15 swift0x00010e30d58e 
> swift::ClangImporter::loadModule(swift::SourceLoc, 
> llvm::ArrayRef >) + 462
> 16 swift0x00010e3df8a3 
> swift::ASTContext::getModule(llvm::ArrayRef swift::SourceLoc> >) + 115
> 17 swift0x00010e25b13a 
> swift::ModuleFile::getModule(llvm::ArrayRef) + 330
> 18 swift0x00010e28900b 
> swift::ModuleFile::associateWithFileContext(swift::FileUnit*, 
> swift::SourceLoc) + 1579
> 19 swift0x00010e2e0785 
> swift::SerializedModuleLoader::loadAST(swift::ModuleDecl&, 
> llvm::Optional, std::__1::unique_ptr std::__1::default_delete >, 
> std::__1::unique_ptr std::__1::default_delete >, bool) + 629
> 20 swift0x00010e2e2e32 
> swift::SerializedModuleLoader::loadModule(swift::SourceLoc, 
> llvm::ArrayRef >) + 466
> 21 swift

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (master) #11359

[Jordan Rose via swift-dev]

Whoops. I think this is evidence in favor of having the -Werror, but also in 
re-running PR tests. I’ll get it.

Jordan

> On Aug 1, 2017, at 09:47, Andrew Trick  wrote:
> 
> Jordan, Dave,
> 
> Are you reverting/fixing now?
> -Andy
> 
>> On Aug 1, 2017, at 9:41 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#11359]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-RA-osx/11359/ 
>> 
>> Project: oss-swift-incremental-RA-osx
>> Date of build:   Tue, 01 Aug 2017 09:25:42 -0700
>> Build duration:  17 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 
>> 
>> Changes
>> 
>> Commit dc1d0943b285ca11dfb0427a67a6ad7e68346796 by David Zarzycki:
>> [CMake] Infer -Werror=switch via asserts being enabled (#11098)
>> 
>> edit: cmake/modules/SwiftSharedCMakeConfig.cmake
> 

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

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

[Jordan Rose via swift-dev]

> On Jul 29, 2017, at 13:20, Chris Lattner <clatt...@nondot.org> wrote:
> 
> 
>> On Jul 28, 2017, at 3:59 PM, Jordan Rose via swift-dev <swift-dev@swift.org 
>> <mailto:swift-dev@swift.org>> wrote:
>> 
>>>> So generic code to instantiate type metadata would have to construct these 
>>>> mangled strings eagerly?
>>> 
>>> We already do exactly that for the ObjC runtime name of generic class 
>>> instantiations, for what it's worth, but it could conceivably be lazy as 
>>> well, at the cost of making the comparison yet more expensive. There aren't 
>>> that many runtime operations that need to do type comparison, though—the 
>>> ones I can think of are casting and the equality/hashing operations on 
>>> Any.Type—so how important is efficient type comparison?
>> 
>> I'm still strongly against any feature that relies on type names being 
>> present at runtime. I think we should be able to omit those for both code 
>> size and secrecy reasons when the type isn't an @objc class or protocol.
> 
> Out of curiosity, is there something that strongly motivates this?  Aren’t 
> code obfuscation tools good enough for the few people who care?
> 
> Actually achieving “secrecy” would require revising the mangling scheme and 
> making lots of other changes to the runtime metadata.  This would be very 
> complicated and expensive, and almost no one cares AFAIK.

I've got a pile of secrecy-related Radars that says it's at least worth 
thinking about. I don't think it matters for public symbols but for non-public 
ones C people are used to being able to use names freely, even if Objective-C 
people know they can show up in the runtime metadata.

(We've also gotten complains that there aren't good code obfuscation tools for 
Swift, since we don't have a preprocessor. That's a separable issue, though.)

Jordan

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

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

[Jordan Rose via swift-dev]

> On Jul 28, 2017, at 16:03, Joe Groff  wrote:
> 
> 
>> On Jul 28, 2017, at 3:59 PM, Jordan Rose > > wrote:
>> 
>> 
>> 
>>> On Jul 28, 2017, at 15:35, Joe Groff via swift-dev >> > wrote:
>>> 
 
 On Jul 28, 2017, at 3:30 PM, John McCall > wrote:
 
> On Jul 28, 2017, at 6:24 PM, Joe Groff  > wrote:
>> On Jul 28, 2017, at 3:15 PM, John McCall > > wrote:
>> 
>> 
>>> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev 
>>> > wrote:
>>> 
>>> 
 On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev 
 > wrote:
 
 The Swift runtime currently maintains globally unique pointer 
 identities for type metadata and protocol conformances. This makes 
 checking type equivalence a trivial pointer equality comparison, but 
 most operations on generic values do not really care about exact type 
 identity and only need to invoke value or protocol witness methods or 
 consult other data in the type metadata structure. I think it's worth 
 reevaluating whether having globally unique type metadata objects is 
 the correct design choice. Maintaining global uniqueness of metadata 
 instances carries a number of costs. Any code that wants type metadata 
 for an instance of a generic type, even a fully concrete one, must 
 make a potentially expensive runtime call to get the canonical 
 metadata instance. This also greatly complicates our ability to emit 
 specializations of type metadata, value witness tables, or protocol 
 witness tables for concrete instances of generic types, since 
 specializations would need to be registered with the runtime as 
 canonical metadata objects, and it would be difficult to do this 
 lazily and still reliably favor specializations over more generic 
 witnesses. The lack of witness table specializations leaves an 
 obnoxious performance cliff for instances of generic types that end up 
 inside existential containers or cross into unspecialized code. The 
 runtime also obligates binaries to provide the canonical metadata for 
 all of their public types, along with all the dependent value 
 witnesses, class methods, and protocol witness tables, meaning a type 
 abstraction can never be completely "zero-cost" across modules.
 
 On the other hand, if type metadata did not need to be unique, then 
 the compiler would be free to emit specialized type metadata and 
 protocol witness tables for fully concrete non-concrete value types 
 without consulting the runtime. This would let us avoid runtime calls 
 to fetch metadata in specialized code, and would make it much easier 
 for us to implement witness specialization. It would also give us the 
 ability to potentially extend the "inlinable" concept to public 
 fragile types, making it a client's responsibility to emit metadata 
 for the type when needed and keeping the type from affecting its home 
 module's ABI. This could significantly reduce the size and ABI surface 
 area of the standard library, since the standard library contains a 
 lot of generic lightweight adapter types for collections and other 
 abstractions that are intended to be optimized away in most use cases.
 
 There are of course benefits to globally unique metadata objects that 
 we would lose if we gave up uniqueness. Operations that do check type 
 identity, such as comparison, hashing, and dynamic casting, would have 
 to perform more expensive checks, and nonunique metadata objects would 
 need to carry additional information to enable those checks. It is 
 likely that class objects would have to remain globally unique, if for 
 no other reason than that the Objective-C runtime requires it on Apple 
 platforms. Having multiple equivalent copies of type metadata has the 
 potential to increase the working set of an app in some situations, 
 although it's likely that redundant compiler-emitted copies of value 
 type metadata would at least be able to live in constant pages mapped 
 from disk instead of getting dynamically instantiated by the runtime 
 like everything is today. There could also be subtle source-breaking 
 behavior for code that bitcasts metatype values to integers or 
 pointers and expects bit-level 

Re: [swift-dev] autocompletions for local variables

[Jordan Rose via swift-dev]

Hi, Mansimar. I don't work on code completion myself, but my recollection was 
that the results are always computed for the start location of the identifier, 
ignoring any text that may have already been typed. This is because SourceKit 
is meant to have an IDE as a client, and so to minimize traffic between 
SourceKit and the IDE it's better to have a simple filter on the client side 
than to send multiple requests every time the user types a key (especially 
backspace!).

SourceKitten may or may not want to follow that philosophy, but that should at 
least explain what's going on.

Best,
Jordan


> On Jul 24, 2017, at 08:46, Mansimar Kaur via swift-dev  
> wrote:
> 
> Hi
> 
> Sourckitten ( https://github.com/jpsim/SourceKitten 
>  ) uses Sourcekitd to provide 
> autocompletions.
> 
> When trying to generate autocompletions for local variables: wi
> let hello = 5;hell with offset 14
> 
> The autocompletions generated are 344 in number and only one of the returned 
> results even starts with 'h'.
> 
> Why are wrong autocompletions being generated alongwith only one correct one?
> 
> For more context, please take a look at this issue: 
> https://github.com/jpsim/SourceKitten/issues/406 
> 
> 
> Thanks
> Mansimar Kaur
> 
> ___
> 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] Feature Proposal to improve Mixed Frameworks support

[Jordan Rose via swift-dev]

> On Jun 29, 2017, at 16:35, Daniel Dunbar <daniel_dun...@apple.com> wrote:
> 
> 
>> On Jun 29, 2017, at 10:43 AM, Jordan Rose via swift-dev <swift-dev@swift.org 
>> <mailto:swift-dev@swift.org>> wrote:
>> 
>> Thanks for following through on this, Gonzalo! (The two of us talked about 
>> this briefly at WWDC.) My idea was a little less clever than yours: just 
>> always include the internal members in the main header unless you provide 
>> the name of a second header to put them in. (I called this flag 
>> -emit-objc-internal-header-path.) That's not quite as flexible, but does 
>> remove all the guesswork, at least for generated headers.
> 
> Doesn't that mean downstream Obj-C clients get bogus code completion results?

I’m not sure what you mean by this. Frameworks will always generate both 
headers, apps and unit tests will always generate one header. The only problem 
is if someone custom-builds a library target and is relying on that not 
including internal decls…which, admittedly, can happen. But the current logic 
is a patchwork of guesswork.


> 
>> I filed a bug to track this work: SR-5221 
>> <https://bugs.swift.org/browse/SR-5221>.
> 
> Cool, this sounds like a nice feature to me, I have heard several complaints 
> about needing to mark things public unnecessarily.
> 
>  - Daniel
> 
>> 
>> Jordan
>> 
>> 
>>> On Jun 29, 2017, at 06:35, Gonzalo Larralde via swift-dev 
>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>> 
>>> I wanted to bring a few points into attention to discuss potential 
>>> improvements on Mixed Frameworks support. The current status for Mixed 
>>> Frameworks present some challenges, one specifically being how the Swift 
>>> compiler generates the ObjC Interface Header. 
>>> 
>>> At this moment, there's a detection procedure based on the presence of an 
>>> entry point definition (either using the main file argument, or 
>>> @UIApplicationMain). The ObjC Interface Header writer 
>>> (swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to 
>>> determine if the minimum accessibility level to be exported is either 
>>> `internal` (for app targets) or `public` (for framework targets). This can 
>>> be observed here: 
>>> https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657
>>>  
>>> <https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657>
>>> 
>>> The result of this is a difference on how default visibility is exposed to 
>>> ObjC code in the same compilation scope.
>>> 
>>> Having this initial piece of code:
>>> 
>>> ```
>>> public class Test: NSObject {
>>> public foo() {}
>>> func bar() {}
>>> }
>>> ```
>>> 
>>> results on the following Interface Header for Main App targets
>>> 
>>> -swift.h
>>> ```
>>> @interface Test : NSObject
>>> - (void)foo;
>>> - (void)bar;
>>> @end
>>> ```
>>> 
>>> and the following for Frameworks
>>> 
>>> -swift.h
>>> ```
>>> @interface Test : NSObject
>>> - (void)foo;
>>> @end
>>> ```
>>> 
>>> This is clearly correct for the publicly visible interface of the 
>>> framework, but not quite the expected result for the ObjC code compiled in 
>>> the same target. In that scenario it would make more sense to me that all 
>>> the `internal` methods are visible.
>>> 
>>> A potential solution for this problem is to generate two Interface Headers, 
>>> one that exports all the `public` and `open` entities and members, and an 
>>> additional header exposing internal entities and declaring categories to 
>>> public entities and exposing internal members.
>>> 
>>> Something like:
>>> 
>>> -swift-internal.h
>>> ```
>>> @interface Test (InternalMembers)
>>> - (void)bar;
>>> @end
>>> ```
>>> 
>>> After that it'll be Xcode's responsability to create both files, and mark 
>>> them as Public and Project in the Headers Build Phase.
>>> 
>>> An initial implementation that I think would make sense in case this 
>>> solution is accepted could be modifying the signature of 
>>> `swift::printAsObjC` to require the list of access levels to export as a 
>>> bitmask instead of just getting the minimum. That will enable the exporter 
>>&

Re: [swift-dev] Feature Proposal to improve Mixed Frameworks support

[Jordan Rose via swift-dev]

Thanks for following through on this, Gonzalo! (The two of us talked about this 
briefly at WWDC.) My idea was a little less clever than yours: just always 
include the internal members in the main header unless you provide the name of 
a second header to put them in. (I called this flag 
-emit-objc-internal-header-path.) That's not quite as flexible, but does remove 
all the guesswork, at least for generated headers.

I filed a bug to track this work: SR-5221 
.

Jordan


> On Jun 29, 2017, at 06:35, Gonzalo Larralde via swift-dev 
>  wrote:
> 
> I wanted to bring a few points into attention to discuss potential 
> improvements on Mixed Frameworks support. The current status for Mixed 
> Frameworks present some challenges, one specifically being how the Swift 
> compiler generates the ObjC Interface Header. 
> 
> At this moment, there's a detection procedure based on the presence of an 
> entry point definition (either using the main file argument, or 
> @UIApplicationMain). The ObjC Interface Header writer 
> (swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to determine 
> if the minimum accessibility level to be exported is either `internal` (for 
> app targets) or `public` (for framework targets). This can be observed here: 
> https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657
>  
> 
> 
> The result of this is a difference on how default visibility is exposed to 
> ObjC code in the same compilation scope.
> 
> Having this initial piece of code:
> 
> ```
> public class Test: NSObject {
>   public foo() {}
>   func bar() {}
> }
> ```
> 
> results on the following Interface Header for Main App targets
> 
> -swift.h
> ```
> @interface Test : NSObject
> - (void)foo;
> - (void)bar;
> @end
> ```
> 
> and the following for Frameworks
> 
> -swift.h
> ```
> @interface Test : NSObject
> - (void)foo;
> @end
> ```
> 
> This is clearly correct for the publicly visible interface of the framework, 
> but not quite the expected result for the ObjC code compiled in the same 
> target. In that scenario it would make more sense to me that all the 
> `internal` methods are visible.
> 
> A potential solution for this problem is to generate two Interface Headers, 
> one that exports all the `public` and `open` entities and members, and an 
> additional header exposing internal entities and declaring categories to 
> public entities and exposing internal members.
> 
> Something like:
> 
> -swift-internal.h
> ```
> @interface Test (InternalMembers)
> - (void)bar;
> @end
> ```
> 
> After that it'll be Xcode's responsability to create both files, and mark 
> them as Public and Project in the Headers Build Phase.
> 
> An initial implementation that I think would make sense in case this solution 
> is accepted could be modifying the signature of `swift::printAsObjC` to 
> require the list of access levels to export as a bitmask instead of just 
> getting the minimum. That will enable the exporter to create the following 
> set of files:
> 
> * Internal, Public, Open > -swift.h for app targets
> * Public, Open > -swift.h for framework targets
> * Internal > -swift-internal.h for the internal entities and 
> members on framework targets.
> 
> To make this happen a new argument needs to be passed to the compiler call. 
> When it's not passed the default behaviour would remain the same, but when it 
> is the behaviour needs to be explicitly defined. One option is to just get 
> the explicit list of access levels to export (something like 
> `-export=internal,public,open`) or export levels to be defined (0 for app 
> targets, 1 for public framework targets and 2 for the internal header 
> framework targets for example)
> 
> I hope this feature proposal is complete enough to properly define the scope 
> and discuss the viability of a possible solution. Otherwise please let me 
> know.
> 
> Thanks.
> 
> --
> Slds,
> 
> Gonzalo.
> ___
> 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] CI failures in deserialization

[Jordan Rose via swift-dev]

…are a result of using Swift 3.2 modules in a Swift 4 context, specifically 
with inlinable code. I'll fix this particular issue, but I'll also use this as 
a reminder that @inline(__always), @_inlineable, and @_transparent are not 
supported for user code. We're getting away with them in the standard library 
purely by avoiding the known and unknown pitfalls. :-)

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

Re: [swift-dev] Swift question

[Jordan Rose via swift-dev]

[+swift-dev list] We use -verify mode to test warnings—you can see this a lot 
in tests with "expected-warning". The way to test for fix-its is to add 
"{{M-N=newtext}}" after the diagnostic text, where M and N are the start and 
end column numbers of the replacement (a half-open range). For an insertion, 
the column numbers will be the same; for a removal, the new text will be empty.

Thanks for picking this up!
Jordan


> On Jun 13, 2017, at 07:37, Dmitry Venikov  wrote:
> 
> Hello, I have a question about https://bugs.swift.org/browse/SR-4949 
>  and would be happy if you could 
> answer. How do I test warnings and fix-its (fixItRemove)? Thank you.
> 

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

Re: [swift-dev] statically initialized arrays

[Jordan Rose via swift-dev]

> On Jun 14, 2017, at 11:24, Erik Eckstein via swift-dev  
> wrote:
> 
> Hi,
> 
> I’m about implementing statically initialized arrays. It’s about allocating 
> storage for arrays in the data section rather than on the heap.
> 
> Info: the array storage is a heap object. So in the following I’m using the 
> general term “object” but the optimization will (probably) only handle array 
> buffers.
> 
> This optimization can be done for array literals containing only other 
> literals as elements.
> Example:
> 
> func createArray() -> [Int] {
>   return [1, 2, 3]
> }
> 
> The compiler can allocate the whole array buffer as a statically initialized 
> global llvm-variable with a reference count of 2 to make it immortal.
> It avoids heap allocations for array literals in cases stack-promotion can’t 
> kick in. It also saves code size.
> 
> What’s needed for this optimization?
> 
> 1) An optimization pass (GlobalOpt) which detects such array literal 
> initialization patterns and “outlines” those into a statically initialized 
> global variable
> 2) A representation of statically initialized global variables in SIL
> 3) IRGen to create statically initialized objects as global llvm-variables
> 
> ad 2) Changes in SIL:
> 
> Currently a static initialized sil_global is represented by having a 
> reference to a globalinit function which has to match a very specific pattern 
> (e.g. must contain a single store to the global).
> This is somehow quirky and would get even more complicated for statically 
> initialized objects.
> 
> I’d like to change that so that the sil_global itself contains the 
> initialization value.
> This part is not yet related to statically initialized objects. It just 
> improves the representation of statically initialized global in general.
> 
> @@ -1210,7 +1210,9 @@ Global Variables
>  ::
>  
>decl ::= sil-global-variable
> +  static-initializer ::= '{' sil-instruction-def* '}'
>sil-global-variable ::= 'sil_global' sil-linkage identifier ':' sil-type
> + (static-initializer)?
>  
>  SIL representation of a global variable.
>  
> @@ -1221,6 +1223,19 @@ SIL instructions. Prior to performing any access on 
> the global, the
>  Once a global's storage has been initialized, ``global_addr`` is used to
>  project the value.
>  
> +A global can also have a static initializer if it's initial value can be
> +composed of literals. The static initializer is represented as a list of
> +literal and aggregate instructions where the last instruction is the 
> top-level
> +value of the static initializer::
> +
> +  sil_global hidden @_T04test3varSiv : $Int {
> +%0 = integer_literal $Builtin.Int64, 27
> +%1 = struct $Int (%0 : $Builtin.Int64)
> +  }
> +
> +In case a global has a static initializer, no ``alloc_global`` is needed 
> before
> +it can be accessed.
> +
> 
> Now to represent a statically initialized object, we need a new instruction. 
> Note that this “instruction" can only appear in the initializer of a 
> sil_global.
> 
> +object
> +``
> +::
> +
> +  sil-instruction ::= 'object' sil-type '(' (sil-operand (',' 
> sil-operand)*)? ')'
> +
> +  object $T (%a : $A, %b : $B, ...)
> +  // $T must be a non-generic or bound generic reference type
> +  // The first operands must match the stored properties of T
> +  // Optionally there may be more elements, which are tail-allocated to T
> +
> +Constructs a statically initialized object. This instruction can only appear
> +as final instruction in a global variable static initializer list.
> 
> Finally we need an instruction to use such a statically initialized global 
> object.
> 
> +global_object
> +`
> +::
> +
> +  sil-instruction ::= 'global_object' sil-global-name ':' sil-type
> +
> +  %1 = global_object @v : $T
> +  // @v must be a global variable with a static initialized object
> +  // $T must be a reference type
> +
> +Creates a reference to the address of a global variable which has a static
> +initializer which is an object, i.e. the last instruction of the global's
> +static initializer list is an ``object`` instruction.
> 
> 
> ad 3) IRGen support
> 
> Generating statically initialized globals is already done today for structs 
> and tuples.
> What’s needed is the handling of objects.
> In addition to creating the global itself, we also need a runtime call to 
> initialize the object header. In other words: the object is statically 
> initialized, except the header.
> 
> HeapObject *swift::swift_initImmortalObject(HeapMetadata const *metadata, 
> HeapObject *object)
> 
> There are 2 reasons for that: first, the object header format is not part of 
> the ABI. And second, in case of a bound generic type (e.g. array buffers) the 
> metadata is not statically available.
> 
> One way to call this runtime function is dynamically at the global_object 
> instruction whenever the metadata pointer is still null (via swift_once).
> Another possibility would be to call it in 

Re: [swift-dev] RFC: bridging peephole for "as" casts

[Jordan Rose via swift-dev]

> On Jun 13, 2017, at 16:11, John McCall via swift-dev  
> wrote:
> 
> So, there's a longstanding issue that we're planning to fix in Swift 4, and I 
> want to both make sure that the plan is documented publicly and give people a 
> chance to disagree with it.
> 
> A bridging conversion is a conversion between a Swift type and a foreign type 
> (C / ObjC / whatever) which can represent the same set of values.  For 
> example, there are bridging conversions from Swift.String to ObjC's NSString 
> and vice-versa.  When there two-way conversions like this, we say that the 
> Swift type is bridged to the foreign type.
> 
> Bridging conversions are performed for three reasons in Swift:
> 
> 1. You can always request a bridging conversion with an unconditional "as" 
> cast.  For example, if myString is a String, you can convert it to NSString 
> by writing "myString as NSString".
> 
> 2. Certain bridging conversions can be introduced as implicit conversions.  
> (This is perhaps a mistake.)   For example, CFString and NSString are 
> considered different types, but they will implicitly convert to each other.
> 
> 3. Bridging conversions are done "behind the scenes" when using an imported 
> declaration that has been given a type that does not match its original type. 
>  For example, an Objective-C method that returns an NSString will be imported 
> as returning a String; Swift will implicitly apply a bridging conversion to 
> the true return value in order to produce the String that the type system has 
> promised.
> 
> Bridging conversions are not always desirable.  First, they do impose some 
> performance overhead which the user may not want.  But they can also change 
> semantics in unwanted ways.  For example, in certain rare situations, the 
> reference identity of an NSString return value is important — maybe it's 
> actually a persistent NSMutableString which should be modified in-place, or 
> maybe it's a subclass which carries additional information.  A pair of 
> bridging conversions from NSString to String and then back to NSString is 
> likely to lose this reference identity.  In the current representation, 
> String can store an NSString reference, and if the String is bridged to 
> NSString that reference will be used as the result; however, the bridging 
> conversion from NSString does not directly store the original NSString in the 
> String, but instead stores the result of invoking +copy on it, in an effort 
> to protect against the original NSString being somehow mutable.
> 
> Bridging conversions arising from reasons #1 and #2 are avoidable, but 
> bridging conversions arising from reason #3 currently cannot be eliminated 
> without major inconvenience, such as writing a stub in Objective-C.  This is 
> unsatisfactory.  At the same time, it is not valid for Swift to simply 
> eliminate pairs of bridging conversions as a matter of course, precisely 
> because those bridging conversions can be semantically important.  We do not 
> want optimization settings to be able to affect things as important as 
> whether a particular NSString is mutable or not.
> 
> The proposal is to apply a guaranteed syntactic "peephole" to eliminate 
> bridging conversions that arise from reason #3.  Specifically:
> 
>   No bridging conversions will be performed if:
> - a call, property reference, or subscript reference is the immediate 
> syntactic
>   operand of an "as" cast to a type compatible with the foreign return, 
> property,
>   or subscript element type or
> - a call argument, right operand of an assignment to a property 
> reference, or
>   right operand of an assignment to a subscript reference is an "as" cast 
> from a
>   type compatible with the foreign parameter, property, or subscript 
> element type.
>   Two types are "compatible" if there is a simple subclass or class-protocol 
> relationship
>   between the underlying non-optional types.
> 
> We believe that this rule is easy and intuitive enough to understand that it 
> will not cause substantial problems.

Thanks for writing this all down, John. Should returns also be included in 
this? That is:

override func someObjCFunction() -> String {
  return NSMutableString() as String
}

(and, having written that, it seems useful to show code examples for each of 
your cases.)

Jordan

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

Re: [swift-dev] Call for help: Linux (and others) build configurations, including static libraries, with ICU.

[Jordan Rose via swift-dev]

michael-yuji on GitHub just sent us a patch in 
https://github.com/apple/swift/pull/9940 
, so at least that part's not a 
concern.

> On May 25, 2017, at 17:47, Michael Ilseman via swift-dev 
>  wrote:
> 
> If that’s the case, we’ll want to add in FreeBSD alongside Android for that.
> 
> 
>> On May 25, 2017, at 5:45 PM, Davide Italiano  wrote:
>> 
>> On Thu, May 25, 2017 at 5:41 PM, Michael Ilseman  wrote:
>>> That would be awesome! Do you use the static stdlib configuration?
>>> 
>>> I had to make assumptions about the type of pthread_key_t. If the type is 
>>> wrong, there’s a nice static_assert with a message telling how to fix it. 
>>> This came up yesterday for Android builds, and fixes are pretty straight 
>>> forward: https://github.com/apple/swift/pull/9930/files
>>> 
>> 
>> From a very quick (non-exhaustive) look I see pthread_key_t defined in
>> freebsd sys/ as:
>> 
>> `typedef int pthread_key_t;`
>> 
>> Is this compliant with your definition?
>> 
>> Thanks,
>> 
>> --
>> Davide
> 
> ___
> 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.04 (swift 4.0) #448

[Jordan Rose via swift-dev]

I don't think this is any of mine.

/home/buildnode/disk2/workspace/oss-swift-4.0-incremental-RA-linux-ubuntu-16_04/swift/test/SourceKit/CursorInfo/cursor_no_cancel.swift:19:11:
 error: expected string not found in input

// CHECK: source.lang.swift.decl.function.free
  ^
:1:1: note: scanning from here
#0 0x7fa8bc5ecd88 llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(BUILD_DIR/lib/libsourcekitdInProc.so+0x992d88)
^
:6:23: note: possible intended match here
#5 0x7fa8bc631eea SourceKit::SwiftLangSupport::~SwiftLangSupport() 
(BUILD_DIR/lib/libsourcekitdInProc.so+0x9d7eea)
  ^

SourceKit folks?


> On May 16, 2017, at 17:28, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_04 [#448]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-ubuntu-16_04/448/ 
> 
> Project:  oss-swift-4.0-incremental-RA-linux-ubuntu-16_04
> Date of build:Tue, 16 May 2017 16:32:17 -0700
> Build duration:   55 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 1 test(s), Passed: 9369 test(s), Total: 9370 test(s)
> Failed: Swift(linux-x86_64).SourceKit/CursorInfo.cursor_no_cancel.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 420 test(s), Total: 420 test(s)
> 
> Changes
> 
> Commit d84e881b07c4d878cf0d1bac7f605f02392bfa02 by Jordan Rose:
> [ClangImporter] Import Swift 3 and 4 names for enumerators. (#9523)
> 
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/APINotesFrameworkTest.apinotes
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/APINotesFrameworkTest.h
> edit: lib/ClangImporter/ImportName.cpp
> edit: test/APINotes/versioned.swift
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: lib/ClangImporter/ImportName.h
> edit: lib/ClangImporter/SwiftLookupTable.h
> add: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/Enums.h
> 
> Commit 87a7b6b5828f543cf99c3d021886e437b40dd30c by Jordan Rose:
> Merge pull request #9579 from jrose-apple/members-through-the-ages
> 
> edit: lib/ClangImporter/SwiftLookupTable.h
> edit: test/ClangImporter/Inputs/SwiftPrivateAttr.txt
> edit: test/IDE/print_clang_swift_name.swift
> edit: test/IDE/print_clang_decls_AppKit.swift
> edit: test/IDE/print_omit_needless_words.swift
> add: test/APINotes/versioned-objc-dynamic-lookup.swift
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/Protocols.h
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/APINotesFrameworkTest.apinotes
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/Classes.h
> edit: lib/ClangImporter/ClangImporter.cpp
> edit: lib/ClangImporter/ImporterImpl.h
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: test/APINotes/versioned-objc.swift
> 
> Commit 0643c619d6f001666bf3b0f7d9f3f0a6d8c7bfd1 by Jordan Rose:
> [test] Don't depend on "Version: 4" sections working in API notes yet.
> 
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/APINotesFrameworkTest.apinotes
> edit: test/APINotes/versioned-objc.swift

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

Re: [swift-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (master) #718

[Jordan Rose via swift-dev]

Just looking into it now, was in the migration fest.

> On May 16, 2017, at 14:09, Michael Ilseman  wrote:
> 
> Jordan, are you currently tracking this?
> 
> Script:
> --
> rm -rf 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64/test-macosx-x86_64/APINotes/Output/versioned-objc.swift.tmp
>  && mkdir -p 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64/test-macosx-x86_64/APINotes/Output/versioned-objc.swift.tmp
> not 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64/bin/swiftc
>  -frontend -target x86_64-apple-macosx10.9  -module-cache-path 
> '/var/folders/_8/79jmzf2142z2xydc_01btlx0gn/T/swift-testsuite-clang-module-cacheyxFbSP'
>  -sdk 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>  -swift-version 3 -typecheck -F 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/APINotes/Inputs/custom-frameworks
>  -swift-version 4 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/APINotes/versioned-objc.swift
>  2>&1 | 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/utils/PathSanitizingFileCheck
>  --sanitize 
> 'BUILD_DIR=/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64'
>  --sanitize 
> 'SOURCE_DIR=/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift'
>  --use-filecheck 
> '/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/llvm-macosx-x86_64/./bin/FileCheck'
>  -check-prefix=CHECK-DIAGS -check-prefix=CHECK-DIAGS-4 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/APINotes/versioned-objc.swift
> not 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64/bin/swiftc
>  -frontend -target x86_64-apple-macosx10.9  -module-cache-path 
> '/var/folders/_8/79jmzf2142z2xydc_01btlx0gn/T/swift-testsuite-clang-module-cacheyxFbSP'
>  -sdk 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>  -swift-version 3 -typecheck -F 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/APINotes/Inputs/custom-frameworks
>  -swift-version 3 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/APINotes/versioned-objc.swift
>  2>&1 | 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/utils/PathSanitizingFileCheck
>  --sanitize 
> 'BUILD_DIR=/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64'
>  --sanitize 
> 'SOURCE_DIR=/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift'
>  --use-filecheck 
> '/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/llvm-macosx-x86_64/./bin/FileCheck'
>  -check-prefix=CHECK-DIAGS -check-prefix=CHECK-DIAGS-3 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/APINotes/versioned-objc.swift
> --
> Exit Code: 1
> 
> Command Output (stderr):
> --
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/APINotes/versioned-objc.swift:49:20:
>  error: expected string not found in input
>  // CHECK-DIAGS-4: [[@LINE-1]]:{{[0-9]+}}: error: 
> 'classWithManyRenamesForInt' has been replaced by 'init(swift4Factory:)'
>^
> :42:2: note: scanning from here
>  let _: RenamedGeneric = OldRenamedGeneric()
>  ^
> :42:2: note: with expression "@LINE-1" equal to "48"
>  let _: RenamedGeneric = OldRenamedGeneric()
>  ^
> :47:46: note: possible intended match here
> SOURCE_DIR/test/APINotes/versioned-objc.swift:48:28: error: 
> 'classWithManyRenamesForInt' has been replaced by 'init(for:)'
>  ^
> 
> --
> 
> 
> 
>> On May 16, 2017, at 2:05 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-ASAN-RA-osx [#718]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/718/ 
>> 
>> Project: oss-swift-incremental-ASAN-RA-osx
>> Date of build:   Tue, 16 May 2017 10:26:23 -0700
>> Build duration:  3 hr 39 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 
>> 
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all 

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (swift 4.0) #478

[Jordan Rose via swift-dev]

I merged the Clang half of this to the wrong branch. Sorry! Should be fixed now.

Jordan


> On May 15, 2017, at 11:04, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_10 [#478]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-ubuntu-16_10/478/ 
> 
> Project:  oss-swift-4.0-incremental-RA-linux-ubuntu-16_10
> Date of build:Mon, 15 May 2017 10:20:27 -0700
> Build duration:   44 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 1 test(s), Passed: 9363 test(s), Total: 9364 test(s)
> Failed: Swift(linux-x86_64).APINotes.versioned.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 420 test(s), Total: 420 test(s)
> 
> Changes
> 
> Commit a7835bfa2a6d0d0e3e9ea3baa931e941093886af by Jordan Rose:
> [IDE] Preserve order for Clang declarations with the same source loc.
> 
> edit: test/ClangImporter/Inputs/SwiftPrivateAttr.txt
> edit: lib/IDE/ModuleInterfacePrinting.cpp
> 
> Commit fc77813516dcb23129ecf9345b118d33c3f50304 by Jordan Rose:
> Update Swift-side tests for Clang providing an unversioned SwiftName.
> 
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/APINotesFrameworkTest.h
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/Types.h
> edit: 
> test/APINotes/Inputs/custom-frameworks/APINotesFrameworkTest.framework/Headers/APINotesFrameworkTest.apinotes
> edit: test/APINotes/versioned-objc.swift
> edit: test/APINotes/versioned.swift

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

Re: [swift-dev] New warning message while switching on an enum

[Jordan Rose via swift-dev]

I think they'll all be IsPatterns, which means you can look at the 
CheckedCastKind.

Jordan


> On May 9, 2017, at 13:54, Robert Widmann  wrote:
> 
> Is there a catch-all to query for such casts (sorry, I'm away from my 
> computer at the moment).
> 
> ~Robert Widmann
> 
> 2017/05/09 16:40、Jordan Rose  > のメッセージ:
> 
>> I think any bridging conversion or upcast would count.
>> 
>> enum Foo {
>>   case foo(NSFileManager)
>>   case bar(NSString)
>>   case baz(Int)
>> }
>> func test(x: Foo) {
>>   switch x {
>>   case .foo(let obj as NSObject):
>> print("totally legal")
>>   case .bar(let obj as String):
>> print("also cool")
>>   case .baz(let obj as Any):
>> print("I'm not sure why, but sure")
>>   }
>> }
>> 
>> Jordan
>> 
>>> On May 9, 2017, at 11:29, Robert Widmann >> > wrote:
>>> 
>>> Right.  I guess I should have asked: Are there any other kinds of patterns 
>>> we consider exhaustive that have this structure?  
>>> 
>>> ~Robert Widmann
>>> 
 On May 9, 2017, at 2:23 PM, Jordan Rose > wrote:
 
 "as NSError" isn't a tautology, though—the original type is 'Error'. 
 Additionally, the presence or absence of a warning shouldn't affect 
 exhaustiveness analysis, which is currently an error when you get it 
 wrong. Warnings are things you can build with and fix later.
 
 Jordan
 
 
> On May 9, 2017, at 11:22, Robert Widmann  > wrote:
> 
> We’ll warn if that kind of cast is a tautology, right?  That leaves only 
> the dynamic casts, which can’t be assumed exhaustive.
> 
> ~Robert Widmann
> 
>> On May 9, 2017, at 2:13 PM, Jordan Rose > > wrote:
>> 
>> It's neither a variable binding nor an expression pattern, right? It has 
>> to be compared against the original type to know whether it's exhaustive 
>> or not. (Consider "let error as NSError" in a catch clause, which should 
>> be considered exhaustive.)
>> 
>> Jordan
>> 
>>> On May 9, 2017, at 11:12, Robert Widmann >> > wrote:
>>> 
>>> It’s mine, yep.  It looks like it’s classifying the cast in the first 
>>> pattern as a variable binding instead of an expression pattern.  I’ll 
>>> push a fix later.
>>> 
>>> Thanks!
>>> 
 On May 9, 2017, at 1:52 PM, Jordan Rose > wrote:
 
 That looks like a bug to me, since of course the first pattern won't 
 always match. I suspect this is Robert's work on trying to make the 
 exhaustive checks better, https://github.com/apple/swift/pull/8908 
 . Thanks for catching this!
 
 Jordan
 
 
> On May 9, 2017, at 07:09, Pushkar N Kulkarni via swift-dev 
> > wrote:
> 
> Hi there, 
> 
> I see a new warning message for switch statements on enums, like this 
> one: 
> 
> enum Test {
> case one(Any)
> case two
> }
> 
> let x: Test = .one("One")
> switch x {
> case .one(let s as String): print(s)
> case .one: break
> case .two: break
> }
> 
> enum.swift:9:10: warning: case is already handled by previous 
> patterns; consider removing it
> case .one: break 
> 
> 
> I do not see this warning with the 04-24 dev snapshot. 
> 
> The warning goes away with the use of the wildcard pattern in the 
> second case:
> 
> switch x {
> case .one(let s as String): print(s)
> case .one(_): break
> case .two: break
> }
> 
> 
> I am wondering if this change is intentional, though it does make 
> sense to me. Can someone please point me to the related commit?
> 
> Thanks in advance!
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
 
>>> 
>> 
> 
 
>>> 
>> 

___
swift-dev mailing list

Re: [swift-dev] New warning message while switching on an enum

[Jordan Rose via swift-dev]

It's neither a variable binding nor an expression pattern, right? It has to be 
compared against the original type to know whether it's exhaustive or not. 
(Consider "let error as NSError" in a catch clause, which should be considered 
exhaustive.)

Jordan

> On May 9, 2017, at 11:12, Robert Widmann  wrote:
> 
> It’s mine, yep.  It looks like it’s classifying the cast in the first pattern 
> as a variable binding instead of an expression pattern.  I’ll push a fix 
> later.
> 
> Thanks!
> 
>> On May 9, 2017, at 1:52 PM, Jordan Rose > > wrote:
>> 
>> That looks like a bug to me, since of course the first pattern won't always 
>> match. I suspect this is Robert's work on trying to make the exhaustive 
>> checks better, https://github.com/apple/swift/pull/8908 
>> . Thanks for catching this!
>> 
>> Jordan
>> 
>> 
>>> On May 9, 2017, at 07:09, Pushkar N Kulkarni via swift-dev 
>>> > wrote:
>>> 
>>> Hi there, 
>>> 
>>> I see a new warning message for switch statements on enums, like this one: 
>>> 
>>> enum Test {
>>> case one(Any)
>>> case two
>>> }
>>> 
>>> let x: Test = .one("One")
>>> switch x {
>>> case .one(let s as String): print(s)
>>> case .one: break
>>> case .two: break
>>> }
>>> 
>>> enum.swift:9:10: warning: case is already handled by previous patterns; 
>>> consider removing it
>>> case .one: break 
>>> 
>>> 
>>> I do not see this warning with the 04-24 dev snapshot. 
>>> 
>>> The warning goes away with the use of the wildcard pattern in the second 
>>> case:
>>> 
>>> switch x {
>>> case .one(let s as String): print(s)
>>> case .one(_): break
>>> case .two: break
>>> }
>>> 
>>> 
>>> I am wondering if this change is intentional, though it does make sense to 
>>> me. Can someone please point me to the related commit?
>>> 
>>> Thanks in advance!
>>> 
>>> Pushkar N Kulkarni,
>>> IBM Runtimes
>>> 
>>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
>>> 
>>> 
>>> ___
>>> 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] New warning message while switching on an enum

[Jordan Rose via swift-dev]

That looks like a bug to me, since of course the first pattern won't always 
match. I suspect this is Robert's work on trying to make the exhaustive checks 
better, https://github.com/apple/swift/pull/8908 
. Thanks for catching this!

Jordan


> On May 9, 2017, at 07:09, Pushkar N Kulkarni via swift-dev 
>  wrote:
> 
> Hi there, 
> 
> I see a new warning message for switch statements on enums, like this one: 
> 
> enum Test {
> case one(Any)
> case two
> }
> 
> let x: Test = .one("One")
> switch x {
> case .one(let s as String): print(s)
> case .one: break
> case .two: break
> }
> 
> enum.swift:9:10: warning: case is already handled by previous patterns; 
> consider removing it
> case .one: break 
> 
> 
> I do not see this warning with the 04-24 dev snapshot. 
> 
> The warning goes away with the use of the wildcard pattern in the second case:
> 
> switch x {
> case .one(let s as String): print(s)
> case .one(_): break
> case .two: break
> }
> 
> 
> I am wondering if this change is intentional, though it does make sense to 
> me. Can someone please point me to the related commit?
> 
> Thanks in advance!
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> ___
> 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] Fixing 'Identifier' with 'DeclBaseName'

[Jordan Rose via swift-dev]

Hi, all. I wanted to give a heads-up about some work Alex Hoppen has been doing 
to fix one of our longstanding problems: the DeclName for subscripts is just 
the Identifier “subscript”. (And similarly for ‘init’, ‘deinit’, etc.) The 
solution he’s come up with (after discussions with me and John) is to split out 
part of Identifier as “DeclBaseName”, which can either be a normal Identifier 
or a “special name”. This change then has to propagate through the whole 
compiler.

I’ve been putting off reviewing this because it’s such a big change, but in 
response Alex has split up the patch into several smaller PRs that adopt 
DeclBaseName separately in each component. That leads us to a question of 
timing, and I suspect the best time to land these patches is the last week of 
May. Why? Because it will make cherry-picking to other active branches very 
difficult, and since we have our final rebranch of swift-4.0-branch from master 
on Jun 1 that difficulty will then only last a short period of time.

If we don’t get the changes in now, then I’d want to hold off for even longer 
since I suspect there will be a lot of cherry-picking in the weeks immediately 
after the branch. I feel bad for Alex on this mark, since he’s already had to 
rebase his patches several times since he started this effort, but I wouldn’t 
want to disrupt anyone either.

Thoughts, objections?
Jordan___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [swift-users] Guarantees of Tuples as Fixed Sized (stack allocated) Arrays

[Jordan Rose via swift-dev]

> On Apr 28, 2017, at 16:28, John McCall via swift-users 
>  wrote:
> 
>> On Apr 28, 2017, at 7:03 AM, Johannes Weiss via swift-dev 
>> > wrote:
>> Hi swift-users,
>> 
>> (sorry for the cross post to swift-dev, but wasn't sure where it belongs)
>> 
>> I tried to find guarantees about the memory layout Swift tuples but couldn't 
>> find anything. The reason I ask is because I'd like to use them as fixed 
>> sized (stack allocated) arrays. I'm pretty sure they're actually not 
>> guaranteed to be stack allocated but highly likely I assume :).
> 
> Tuples are guaranteed to use a standard C-style layout wherever that layout 
> is ABI-observable, e.g. when you construct an UnsafePointer to one.

Ah, is this true for non-homogeneous tuples? I thought we only guaranteed it 
for homogeneous ones.

Jordan

___
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 - OS X (swift 4.0) #228

[Jordan Rose via swift-dev]

I don’t think that’s any of us. Philippe, does this look familiar?

[ RUN  ] TestCharacterSet.test_moreSetOperations
stdout>>> check failed at 
/Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/swift/test/stdlib/TestCharacterSet.swift,
 line 292
stdout>>> unexpected value: "" (of type Foundation.CharacterSet)
stdout>>> check failed at 
/Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/swift/test/stdlib/TestCharacterSet.swift,
 line 294
stdout>>> expected: true
stdout>>> check failed at 
/Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/swift/test/stdlib/TestCharacterSet.swift,
 line 296
stdout>>> expected: true
[ FAIL ] TestCharacterSet.test_moreSetOperations

Jordan

> On Apr 25, 2017, at 11:43, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-4.0-incremental-RA-osx [#228]
> 
> Build URL:https://ci.swift.org/job/oss-swift-4.0-incremental-RA-osx/228/ 
> 
> Project:  oss-swift-4.0-incremental-RA-osx
> Date of build:Tue, 25 Apr 2017 10:59:23 -0700
> Build duration:   44 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 1 test(s), Passed: 9211 test(s), Total: 9212 test(s)
> Failed: Swift(macosx-x86_64).stdlib.TestCharacterSet.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
> 
> Changes
> 
> Commit 5d90b805331c3589478d854b52b617c788fd027a by Jordan Rose:
> [ClangImporter] Classify enums using flag_enum and enum_extensibility
> 
> edit: lib/ClangImporter/ImportEnumInfo.cpp
> edit: test/IDE/Inputs/swift_name.h
> edit: test/ClangImporter/Inputs/enum-objc.h
> edit: test/IDE/Inputs/print_clang_header_swift_name.h
> edit: test/Inputs/clang-importer-sdk/usr/include/user_objc.h
> edit: lib/PrintAsObjC/PrintAsObjC.cpp
> edit: test/ClangImporter/enum.swift
> edit: test/ClangImporter/Inputs/custom-modules/SwiftName.h
> 
> Commit 5e66ed04d95689d61dac61f58815b895fc9508be by Jordan Rose:
> [ClangImporter] If enum_extensibility was removed, it's not an enum.
> 
> add: test/Inputs/clang-importer-sdk/usr/include/enums_using_attributes.h
> add: 
> test/Inputs/clang-importer-sdk/usr/include/enums_using_attributes.apinotes
> edit: test/ClangImporter/enum.swift
> edit: test/Inputs/clang-importer-sdk/usr/include/module.map
> edit: lib/ClangImporter/ImportEnumInfo.cpp
> 
> Commit 026bbd4426dfebea9bf693d755fbef66b658c56b by Bruno Cardoso Lopes:
> [Modules] Fix a null deference in new redefinition diagnostics
> 
> edit: lib/Sema/SemaDecl.cpp

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

Re: [swift-dev] IRGen's swift_rt_* functions

[Jordan Rose via swift-dev]

I believe these are interposition points for things like dtrace, and also 
useful for Roman's experiments with nonatomic retain counting. Roman, do you 
know?

(JoeG would know too but he's on vacation.)

Jordan


> On Apr 24, 2017, at 17:15, Slava Pestov via swift-dev  
> wrote:
> 
> Hi all,
> 
> Now that we’re using swiftcc, does IRGen still need to emit the swift_rt_* 
> wrappers around runtime calls? They look like no-ops at this point since the 
> runtime entry points themselves should be swiftcc with the callee save 
> variant?
> 
> Slava
> ___
> 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (master) #9603

[Jordan Rose via swift-dev]

This needs a clean build after my commits. I didn't manage to find what the 
missing dependency was, sorry.


> On Apr 24, 2017, at 11:24, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#9603]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9603/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Mon, 24 Apr 2017 10:54:44 -0700
> Build duration:   29 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 2 test(s), Passed: 9258 test(s), Total: 9260 test(s)
> Failed: Swift(macosx-x86_64).Reflection.typeref_decoding_imported.swift 
> 
> Failed: Swift(macosx-x86_64).Reflection.typeref_decoding_objc.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
> 
> Changes
> 
> Commit 25985cb7649a8d550e96ff7e3b2a9193bda8b57b by Jordan Rose:
> [Mangling] Uniformly use "So" for imported decls.
> 
> edit: test/SILGen/imported_struct_array_field.swift
> edit: test/Serialization/sil-imported-enums.swift
> edit: test/stdlib/RuntimeObjC.swift
> edit: test/IRGen/objc_super.swift
> edit: test/IRGen/c_layout.sil
> edit: test/SILGen/objc_bridging.swift
> edit: lib/AST/ASTMangler.cpp
> edit: test/Demangle/Inputs/manglings.txt
> edit: test/IRGen/newtype.swift
> edit: test/SILGen/objc_imported_generic.swift
> edit: test/IRGen/foreign_types.sil
> edit: test/IRGen/objc.swift
> edit: test/IRGen/objc_generic_class_metadata.sil
> edit: test/SILGen/external_definitions.swift
> edit: lib/Demangling/Remangler.cpp
> edit: test/SILGen/newtype.swift
> edit: include/swift/Strings.h
> edit: test/SILGen/cf_members.swift
> edit: test/IRGen/partial_apply_objc.sil
> edit: test/SILGen/objc_enum.swift
> edit: test/SILGen/cf.swift
> edit: test/SILGen/c_materializeForSet_linkage.swift
> edit: lib/Demangling/OldDemangler.cpp
> edit: test/IRGen/objc_ns_enum.swift
> edit: test/IRGen/reflection_metadata_imported.swift
> edit: test/SILGen/mangling.swift
> edit: test/SourceKit/DocSupport/doc_clang_module.swift.response
> edit: test/IRGen/abitypes.swift
> edit: test/IRGen/objc_class_export.swift
> edit: test/SILOptimizer/predictable_memopt_unreferenceable_storage.swift
> edit: test/IRGen/protocol_conformance_records_objc.swift
> edit: lib/IDE/TypeReconstruction.cpp
> edit: test/ClangImporter/ctypes_ir.swift
> edit: test/SourceKit/DocSupport/doc_error_domain.swift
> edit: test/SILGen/objc_bridging_any.swift
> edit: test/Reflection/typeref_decoding_objc.swift
> edit: lib/RemoteAST/RemoteAST.cpp
> edit: test/IRGen/objc_structs.swift
> edit: stdlib/public/runtime/Demangle.cpp
> edit: lib/Demangling/Demangler.cpp
> 
> Commit 129fd372d53ca37411c0071c3833975b76f45e76 by Jordan Rose:
> ASTPrinter: Qualify names when printing nested declarations.
> 
> edit: include/swift/AST/ASTPrinter.h
> edit: include/swift/AST/PrintOptions.h
> edit: lib/AST/ASTPrinter.cpp
> edit: test/SourceKit/DocSupport/doc_source_file.swift.response
> edit: test/SourceKit/DocSupport/doc_swift_module.swift.response
> edit: lib/IDE/CommentConversion.cpp
> 
> Commit e575d2d5ba7d1a2fc70f364ce82c276ada95ffa7 by Jordan Rose:
> [ClangImporter] Error structs from enums are not imported decls.
> 
> edit: lib/IRGen/GenProto.cpp
> edit: lib/IRGen/GenMeta.cpp
> edit: lib/AST/USRGeneration.cpp
> edit: test/SourceKit/DocSupport/doc_error_domain.swift
> edit: test/ClangImporter/enum-error.swift
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: lib/IRGen/GenDecl.cpp
> edit: lib/AST/ProtocolConformance.cpp
> edit: lib/Sema/DerivedConformances.cpp
> edit: lib/Sema/TypeCheckProtocol.cpp
> edit: lib/Sema/CodeSynthesis.cpp
> 

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

Re: [swift-dev] Renamed types (Swift 3/4 Mix-and-Match)

[Jordan Rose via swift-dev]

> On Apr 20, 2017, at 18:25, Michael Ilseman <milse...@apple.com> wrote:
> 
>> 
>> On Apr 20, 2017, at 4:55 PM, Jordan Rose via swift-dev <swift-dev@swift.org 
>> <mailto:swift-dev@swift.org>> wrote:
>> 
>> TLDR: Should we just always import C/ObjC types under their Swift 4 names, 
>> and use typealiases in Swift 3 mode?
>> 
>> ---
>> 
>> Hi, swift-dev. As my recent PRs have probably indicated, I've been working 
>> on the problems that can come up when mixing Swift 3 and Swift 4 code. Most 
>> of these problems have to do with C/ObjC APIs that might present themselves 
>> differently in Swift 3 and Swift 4, using the "API notes" feature in our 
>> downstream branch of Clang, and a good subset of these problems have to do 
>> with types getting renamed. (This includes being "renamed" into a member, 
>> such as NSNotificationName becoming (NS)Notification.Name in Swift.)
>> 
>> What's the problem? Well, there are a few. First of all, an API defined in 
>> terms of the Swift 3 name should still be callable in Swift 4. As an 
>> example, let's pretend NSNotification.Name was going to be renamed 
>> NSNotification.Identifier in Swift 4.
>> 
>> // Swift 3 library
>> public func postTestNotification(named name: NSNotification.Name) { … }
>> 
>> // Swift 4 app
>> let id: Notification.Identifier = …
>> postTestNotification(named: id) // should work
>> 
>> This means the reference to "NSNotification.Name" in the library's 
>> swiftmodule needs to still be resolvable. This isn't too bad if we leave 
>> behind a typealias for 'NSNotification.Name'. I have a reasonable (but too 
>> broad) implementation at https://github.com/apple/swift/pull/8737 
>> <https://github.com/apple/swift/pull/8737>.
>> 
>> That just leads us to another problem, though: because Swift functions can 
>> be overloaded, the symbol name includes the type, and the type has changed. 
>> The Swift 3 library exposes a symbol 
>> '_T03Lib20postTestNotificationySo14NSNotificationC4NameV5named_tF', but the 
>> Swift 4 client expects 
>> '_T03Lib20postTestNotificationySo14NSNotificationC10IdentifierV5named_tF'.
>> 
>> My planned approach to combat this was to use the C name of the type in the 
>> mangling, producing 
>> '_T03Lib20postTestNotificationySo18NSNotificationNamea5named_tF'. This is 
>> prototyped in https://github.com/apple/swift/pull/8871 
>> <https://github.com/apple/swift/pull/8871>.
>> 
>> 
>> At this point Slava pointed out I was chasing down a lot of issues when 
>> there's a much simpler solution for Swift 4: when importing types, always 
>> use the Swift 4 name, and use typealiases to handle Swift 3 compatibility. 
>> This defines both of the previous issues away, as well as any more that I 
>> just haven't thought of yet.
>> 
>> There are some downsides:
>> - We currently keep people from using Swift 4 names in Swift 3 code, and we 
>> wouldn't be able to do that, since the actual declaration of the type always 
>> needs to be available.
> 
> I don’t know if this is an important distinction to worry about. That code 
> will still be able to use features from Swift 4, and perhaps even Swift 4 
> only types (e.g. Substring from SE-0163).
> 
>> - We'd probably want to tweak the "aka" printing in diagnostics to not look 
>> through these typealiases. That's not hard, though.
>> - We can't keep doing this once we have ABI stability. Hopefully framework 
>> owners aren't going to continue changing Swift names of types, but we'll 
>> probably need to implement my "C name in the mangling" plan anyway, just in 
>> case.
>> 
> 
> Would this fall under the realm of library evolution, wherein name changes 
> should be versioned? In that case, would we need both symbols whether they 
> came from C or not?

I suspect we'll end up doing my appended follow-up for this: "mangle me as if 
my name were ___". That doesn't cover everything the importer does, though 
(turning enums into structs, swift_wrapper, import-as-member, etc).

I also hope we just don't have to deal with name changes very often in 
Swift-land.

Jordan

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

Re: [swift-dev] Renamed types (Swift 3/4 Mix-and-Match)

[Jordan Rose via swift-dev]

> On Apr 20, 2017, at 16:55, Jordan Rose via swift-dev <swift-dev@swift.org> 
> wrote:
> 
> TLDR: Should we just always import C/ObjC types under their Swift 4 names, 
> and use typealiases in Swift 3 mode?
> 
> ---
> 
> Hi, swift-dev. As my recent PRs have probably indicated, I've been working on 
> the problems that can come up when mixing Swift 3 and Swift 4 code. Most of 
> these problems have to do with C/ObjC APIs that might present themselves 
> differently in Swift 3 and Swift 4, using the "API notes" feature in our 
> downstream branch of Clang, and a good subset of these problems have to do 
> with types getting renamed. (This includes being "renamed" into a member, 
> such as NSNotificationName becoming (NS)Notification.Name in Swift.)
> 
> What's the problem? Well, there are a few. First of all, an API defined in 
> terms of the Swift 3 name should still be callable in Swift 4. As an example, 
> let's pretend NSNotification.Name was going to be renamed 
> NSNotification.Identifier in Swift 4.
> 
> // Swift 3 library
> public func postTestNotification(named name: NSNotification.Name) { … }
> 
> // Swift 4 app
> let id: Notification.Identifier = …
> postTestNotification(named: id) // should work
> 
> This means the reference to "NSNotification.Name" in the library's 
> swiftmodule needs to still be resolvable. This isn't too bad if we leave 
> behind a typealias for 'NSNotification.Name'. I have a reasonable (but too 
> broad) implementation at https://github.com/apple/swift/pull/8737 
> <https://github.com/apple/swift/pull/8737>.
> 
> That just leads us to another problem, though: because Swift functions can be 
> overloaded, the symbol name includes the type, and the type has changed. The 
> Swift 3 library exposes a symbol 
> '_T03Lib20postTestNotificationySo14NSNotificationC4NameV5named_tF', but the 
> Swift 4 client expects 
> '_T03Lib20postTestNotificationySo14NSNotificationC10IdentifierV5named_tF'.
> 
> My planned approach to combat this was to use the C name of the type in the 
> mangling, producing 
> '_T03Lib20postTestNotificationySo18NSNotificationNamea5named_tF'. This is 
> prototyped in https://github.com/apple/swift/pull/8871 
> <https://github.com/apple/swift/pull/8871>.
> 
> 
> At this point Slava pointed out I was chasing down a lot of issues when 
> there's a much simpler solution for Swift 4: when importing types, always use 
> the Swift 4 name, and use typealiases to handle Swift 3 compatibility. This 
> defines both of the previous issues away, as well as any more that I just 
> haven't thought of yet.
> 
> There are some downsides:
> - We currently keep people from using Swift 4 names in Swift 3 code, and we 
> wouldn't be able to do that, since the actual declaration of the type always 
> needs to be available.
> - We'd probably want to tweak the "aka" printing in diagnostics to not look 
> through these typealiases. That's not hard, though.
> - We can't keep doing this once we have ABI stability. Hopefully framework 
> owners aren't going to continue changing Swift names of types, but we'll 
> probably need to implement my "C name in the mangling" plan anyway, just in 
> case.
> 
> What do people think?

Oh, I forgot there's one more option for fixing the mangling issue: save all 
mangled names into the swiftmodule. That also doesn't work once we have ABI 
stability, though, because you need to match the name for the previous release 
as well as the current one.

Jordan

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

[swift-dev] Renamed types (Swift 3/4 Mix-and-Match)

[Jordan Rose via swift-dev]

TLDR: Should we just always import C/ObjC types under their Swift 4 names, and 
use typealiases in Swift 3 mode?

---

Hi, swift-dev. As my recent PRs have probably indicated, I've been working on 
the problems that can come up when mixing Swift 3 and Swift 4 code. Most of 
these problems have to do with C/ObjC APIs that might present themselves 
differently in Swift 3 and Swift 4, using the "API notes" feature in our 
downstream branch of Clang, and a good subset of these problems have to do with 
types getting renamed. (This includes being "renamed" into a member, such as 
NSNotificationName becoming (NS)Notification.Name in Swift.)

What's the problem? Well, there are a few. First of all, an API defined in 
terms of the Swift 3 name should still be callable in Swift 4. As an example, 
let's pretend NSNotification.Name was going to be renamed 
NSNotification.Identifier in Swift 4.

// Swift 3 library
public func postTestNotification(named name: NSNotification.Name) { … }

// Swift 4 app
let id: Notification.Identifier = …
postTestNotification(named: id) // should work

This means the reference to "NSNotification.Name" in the library's swiftmodule 
needs to still be resolvable. This isn't too bad if we leave behind a typealias 
for 'NSNotification.Name'. I have a reasonable (but too broad) implementation 
at https://github.com/apple/swift/pull/8737 
.

That just leads us to another problem, though: because Swift functions can be 
overloaded, the symbol name includes the type, and the type has changed. The 
Swift 3 library exposes a symbol 
'_T03Lib20postTestNotificationySo14NSNotificationC4NameV5named_tF', but the 
Swift 4 client expects 
'_T03Lib20postTestNotificationySo14NSNotificationC10IdentifierV5named_tF'.

My planned approach to combat this was to use the C name of the type in the 
mangling, producing 
'_T03Lib20postTestNotificationySo18NSNotificationNamea5named_tF'. This is 
prototyped in https://github.com/apple/swift/pull/8871 
.


At this point Slava pointed out I was chasing down a lot of issues when there's 
a much simpler solution for Swift 4: when importing types, always use the Swift 
4 name, and use typealiases to handle Swift 3 compatibility. This defines both 
of the previous issues away, as well as any more that I just haven't thought of 
yet.

There are some downsides:
- We currently keep people from using Swift 4 names in Swift 3 code, and we 
wouldn't be able to do that, since the actual declaration of the type always 
needs to be available.
- We'd probably want to tweak the "aka" printing in diagnostics to not look 
through these typealiases. That's not hard, though.
- We can't keep doing this once we have ABI stability. Hopefully framework 
owners aren't going to continue changing Swift names of types, but we'll 
probably need to implement my "C name in the mangling" plan anyway, just in 
case.

What do people think?

Jordan___
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 14.04 (master) #2124

[Jordan Rose via swift-dev]

 TEST 'Swift-Unit :: 
runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata' FAILED 


/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/unittests/runtime/Metadata.cpp:462:
 Failure
  Expected: ab
  Which is: 0x53e6e0
To be equal to: ba
  Which is: 0x53e7d0


This can't possibly be my commit.


> On Apr 18, 2017, at 18:01, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#2124]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/2124/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Tue, 18 Apr 2017 17:25:59 -0700
> Build duration:   35 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit e88e93cabf72ba487362a6b25a8674c72d6f77e1 by Jordan Rose:
> Use PrettyStackTrace to say /which/ SIL function already exists.
> 
> edit: lib/SIL/SILFunction.cpp

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

Re: [swift-dev] Unexpected Expr type

[Jordan Rose via swift-dev]

Hi, Halen. Welcome to the compiler. :-) What you're seeing is that we don't 
usually use C++'s normal RTTI 
 mechanism, but 
instead go with a "Kind" field that's checked by the custom 'cast', 'dyn_cast', 
and 'isa' functions. (More information in the LLVM Programmer's Manual 
.)
 The debugger doesn't know about this, so it just always shows the base class 
to be conservative. If you're debugging, you can call dump() to see what kind 
of Expr it really is, and then cast the pointer down to the right type as 
needed. In your actual code, you can check `isa(src)`, or 
`dyn_cast(src)` if you then need to manipulate the ParenExpr.

Hope that helps,
Jordan


> On Apr 6, 2017, at 15:30, Halen Wooten via swift-dev  
> wrote:
> 
> Hi swift devs,
> 
> I'm working on SR-4464 to learn how to contribute to Swift. I think I
> have the solution, but I'm getting unexpected results.
> 
> I'm using the swift repl within Xcode for testing. Here's my test code.
> 
> var name = "name"
> name = (name)
> 
> In TypeChecker::diagnoseSelfAssignment in CSDiag.cpp, the src of the
> AssignExpr is a plain Expr *, but I would expect it to be a ParenExpr
> *. Could someone help me figure out what's happening?
> 
> Thanks,
> Halen
> ___
> 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] PR test failing with clang compile error

[Jordan Rose via swift-dev]

Erik may have beat you to it. https://github.com/apple/swift/pull/8595 


Jordan

> On Apr 6, 2017, at 15:18, mishal_shah via swift-dev  
> wrote:
> 
> Looks like this was cherry-picked in swift-clang without PR testing.
> 
> Thanks,
> Mishal Shah
>> On Apr 6, 2017, at 3:17 PM, Slava Pestov > > wrote:
>> 
>> I have a fix pending in this PR: https://github.com/apple/swift/pull/8594 
>> 
>> 
>> But I’m surprised this wasn’t caught in CI.
>> 
>> Slava
>> 
>>> On Apr 6, 2017, at 2:58 PM, Mishal Shah >> > wrote:
>>> 
>>> Hi Slave, 
>>> 
>>> This started after following commits:
>>> 
>>> https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/ 
>>> 
>>> Git (clang)
>>> 
>>> Change -ffp-contract=fast test to run on Aarch64 (detail 
>>> )
>>> Remove -ffp-contract=fast from this test (detail 
>>> )
>>> Encapsulate FPOptions and use it consistently (detail 
>>> )
>>> Use FPContractModeKind universally (detail 
>>> )
>>> Use 'unsigned' for enum bitfields (detail 
>>> )
>>> Set FMF for -ffp-contract=fast (detail 
>>> )
>>> Add #pragma clang fp (detail 
>>> )
>>> Fix sphinx warning from r299470 (detail 
>>> )
>>> Another attempt to fix the sphinx warning from r299470 (detail 
>>> )
>>> 
>>> Thanks, 
>>> Mishal Shah
 On Apr 6, 2017, at 2:53 PM, Slava Pestov via swift-dev 
 > wrote:
 
 Hi all,
 
 I’m hitting this in github PR testing:
 
 /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/swift/lib/ClangImporter/ImportDecl.cpp:994:34:
  error: no matching constructor for initialization of 
 'clang::BinaryOperator'
 
auto cSetterExpr = new (Ctx) clang::BinaryOperator(cSetterMemberExpr,
 ^ ~~
 /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2929:3:
  note: candidate constructor not viable: no known conversion from 'bool' 
 to 'clang::FPOptions' for 8th argument
  BinaryOperator(Expr *lhs, Expr *rhs, Opcode opc, QualType ResTy,
  ^
 /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:3085:3:
  note: candidate constructor not viable: requires 9 arguments, but 8 were 
 provided
  BinaryOperator(Expr *lhs, Expr *rhs, Opcode opc, QualType ResTy,
  ^
 /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:3100:3:
  note: candidate constructor not viable: requires 2 arguments, but 8 were 
 provided
  BinaryOperator(StmtClass SC, EmptyShell Empty)
  ^
 /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2947:12:
  note: candidate constructor not viable: requires single argument 'Empty', 
 but 8 arguments were provided
  explicit BinaryOperator(EmptyShell Empty)
   ^
 /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2913:7:
  note: candidate constructor (the implicit copy constructor) not viable: 
 requires 1 argument, but 8 were provided
 class BinaryOperator : public Expr {
  ^
 /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2913:7:
  note: candidate constructor (the implicit move constructor) not viable: 
 requires 1 argument, but 8 were provided
 1 error generated.
 
 Is there a Clang/LLVM merge in progress or something?
 
 Slava
 ___
 swift-dev mailing list
 swift-dev@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-dev 
 
>>> 
>> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> 

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

[Jordan Rose via swift-dev]

> Test Suite 'TestNSOrderedSet' started at 12:15:18.649
> Test Case 'TestNSOrderedSet.test_BasicConstruction' started at 12:15:18.649
> Test Case 'TestNSOrderedSet.test_BasicConstruction' passed (0.0 seconds)
> Test Case 'TestNSOrderedSet.test_Enumeration' started at 12:15:18.649
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script-impl:
>  line 263: 34208 Segmentation fault  "$@"
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 139, aborting
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 1, aborting

Is it build-script-impl that’s segfaulting, or something under it?

Jordan


> On Mar 29, 2017, at 10:16, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2700]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2700/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Wed, 29 Mar 2017 10:02:22 -0700
> Build duration:   13 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9107 test(s), Total: 9107 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 416 test(s), Total: 416 test(s)
> 
> Changes
> 
> Commit 343193f0f886c53cc067967a81558091d61e94d6 by Arnold Schwaighofer:
> Fix test cases and enable copy-on-write existentials
> 
> edit: test/SILGen/address_only_types.swift
> edit: test/SILOptimizer/mandatory_inlining.sil
> edit: test/IRGen/global_resilience.sil
> edit: test/IRGen/existentials_objc.sil
> edit: test/IRGen/generic_metatypes_arm.swift
> edit: test/IRGen/alloc.sil
> edit: test/IRGen/fixed_size_buffer_peepholes.sil
> edit: test/SILGen/opaque_values_silgen.swift
> edit: test/SILGen/existential_erasure.swift
> edit: utils/build-script-impl
> edit: test/SILGen/function_conversion.swift
> edit: test/IRGen/generic_metatypes.swift
> edit: test/IRGen/witness_table_multifile.swift
> edit: test/SILGen/objc_bridging_any.swift
> edit: CMakeLists.txt
> edit: test/SILOptimizer/sil_combine.sil
> edit: test/sil-llvm-gen/alloc.sil
> edit: test/SILGen/functions.swift
> edit: test/SILGen/protocol_extensions.swift
> 
> Commit c066e42bf22a378105c4ae9fd22bb619f8a3cbb1 by Arnold Schwaighofer:
> IRGen: Use a plain slowDealloc call for deallocateBoxedExistential box
> 
> edit: lib/IRGen/GenExistential.cpp
> 
> Commit 7e043dc769f5376394cfa285f8ab2d108a2f1fff by Arnold Schwaighofer:
> Fix test case
> 
> edit: test/IRGen/existentials_opaque_boxed.sil
> 
> Commit 3dc54c2518e3f0f65202e06d3f6820ab622eafdf by Arnold Schwaighofer:
> Really fix test case
> 
> edit: test/IRGen/existentials_opaque_boxed.sil
> 
> Commit d56fd64952d538325f98b36147ecc3cd5dde656d by Jordan Rose:
> [test] Split out Mac-host-dependent parts of test/Driver/linker.swift.
> 
> edit: test/Driver/linker.swift
> add: test/Driver/linker-arclite.swift
> 
> Commit 4ad2ea5c0c93843d8e53925cd279de87cf579a3c by Jordan Rose:
> [Driver] Fix passing -Fsystem to the linker.
> 
> edit: test/Driver/linker.swift
> edit: lib/Driver/ToolChains.cpp
> 
> Commit 7790ae0908a3a99f22dc7b978e3ececc9c1858f7 by Mehdi Amini:
> Add support for -fno-builtin to LTO and ThinLTO to libLTO
> 
> edit: lib/LTO/ThinLTOCodeGenerator.cpp
> edit: include/llvm/LTO/legacy/ThinLTOCodeGenerator.h
> edit: lib/LTO/LTOCodeGenerator.cpp
> edit: tools/lto/lto.cpp
> add: test/ThinLTO/X86/tli-nobuiltin.ll
> edit: include/llvm/LTO/legacy/LTOCodeGenerator.h
> edit: tools/llvm-lto/llvm-lto.cpp

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

[swift-dev] New conformances and source compatibility

[Jordan Rose via swift-dev]

Hi, everyone. I wanted to get some advice on an issue I've been worrying about: 
the effect of added conformances on source compatibility. Let's take my own 
(stale) PR as an example: #4568  
makes all CF types Equatable and Hashable, using the functions CFHash and 
CFEqual. What happens if somebody's already done that in their own extension 
of, say, CFBag 
?

(Let's not debate in this thread whether this is a good idea. It's consistent 
with NSObject, at least.)

Since conformances are globally unique today, I think the only valid short-term 
answer is to say the user's conformance is invalid, and indeed that's the 
behavior you would get today if you update to a newer version of a package and 
discover that they've added a conformance.

The trouble is that this breaks Swift 3 source compatibility. Unlike many other 
changes, conformances cannot be made conditional on the language version. This 
isn't just because of syntax; someone may have a generic type that relies on 
the conformance being present, and it would be an error to construct that type 
without the conformance.

The solution I thought of was to downgrade the error to a warning, saying "this 
conformance is invalid and will be ignored". This isn't ideal, but it will 
probably do the right thing—how often is there a protocol you can add to a type 
in multiple, significantly different ways?

Okay, great. Except this only solves half the problem: in order to implement 
Hashable, I need to provide a 'hashValue' property. We normally don't treat API 
additions as breaking changes because that would keep us from making any 
changes, but protocol requirements are a little different—in those cases we are 
clearly going to have naming conflicts. These, of course, are reported as 
errors today, and it feels much stranger to downgrade those errors to warnings. 
"Sorry, this code you have written is going to be ignored, but we'll keep 
building anyway?" Seems very fishy.

Options (as I see them):
- Downgrade redeclaration errors to warnings for both conformances and members
- Downgrade conformance redeclaration errors to warnings, but leave member 
redeclaration as an error
- Just leave both of these as errors, and accept that this facet of source 
compatibility is imperfect, and anyone who needs to continue compiling with 
Swift 3.1 can add #if.

Thoughts, answers? Thanks,
Jordan

P.S. All of this will come back in spades with library evolution 
, and in particular there 
are open issues 
 in the 
document around this.

P.P.S. Thanks to Dave Abrahams and Huon Wilson for initial discussion on this.___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Filename, Line and Column for SourceLoc

[Jordan Rose via swift-dev]

FWIW this sounds like a great idea to me. Clang calls these "presumed 
locations" instead of "virtual locations" but either way is fine with me. I'd 
like one of the SourceKit folks to weigh in, though, since they're the most 
involved in operations at this layer. (That'd be Argyrios Kyrtzidis, Ben 
Langmuir, Xi Ge, David Farler, or Nathan Hawes.)

Jordan


> On Mar 15, 2017, at 23:23, rintaro ishizaki via swift-dev 
>  wrote:
> 
> Hi all,
> 
> I would like to propose to reorganize methods for retrieving filename, line 
> and column from SourceLoc.
> 
> Motiavion
> 
> When we want to retrieve filename, line and column from SourceLoc, we have 
> several ways to do that.
> 
> Filename:
>   SourceManager::getBufferIdentifierForLoc
>   SourceManager::getIdentifierForBuffer
>   SourceFile::getFilename
>   LoadedFile::getFilename
>   llvm::MemoryBuffer::getBufferIdentifier
> 
> Line and Column:
>   SourceManager::getLineAndColumn
>   SourceManager::getLineNumber
> 
> Some of them respect #sourceLocation directive, but some not:
> 
> Virtual (respect #sourceLocation):
>   SourceManager::getBufferIdentifierForLoc
>   SourceManager::getLineAndColumn
> 
> Actual:
>   SourceManager::getIdentifierForBuffer
>   SourceFile::getFilename
>   LoadedFile::getFilename
>   llvm::MemoryBuffer::getBufferIdentifier
>   SourceManager::getLineNumber
> 
> Mixed use of them causes errors like https://github.com/apple/swift/pull/5425 
> 
> Since current method namings are unclear about this, I think it's very error 
> prone. Also, we currently don't have any method for *real* getLineAndColumn. 
> When we want to retrieve the real line and column, we have use 
> getLineNumber(loc) for the line, and getLineAndColumn(loc).second for the 
> column. Most of our codebase doesn't bother to do that, though.
> 
> I suspect that Xcode crash when using #sourceLocation in PlayGround is 
> probably caused by this kind of problem; i.e. Xcode expects "real" line and 
> column, but the compiler or sourcekit returns virtual one.
> 
> 
> Proposed Solution
> 
> Reorganize SourceManager methods.
> 
> We need methods for "real" one, and "virtual" one. And they need to have 
> distinct name for that.
> 
> ** RFC for method names **
> 
> class SourceManager {
> 
> public:
> 
>   /// @{
>   /// Real buffer-name, line, and column.
>   /// These methods does not respect '#sourceLocation'
> 
>   /// Returns the identifier string for the buffer with the given ID.
>   StringRef
>   getIdentifierForBuffer(unsigned BufferID) const;
> 
>   /// Returns the buffer identifier string for the Loc.
>   /// If 'BufferID' is provided 'Loc' must come from that buffer.
>   StringRef
>   getIdentifierForBuffer(SourceLoc Loc, unsigned BufferID = 0) const;
> 
>   /// Returns the pair of line and column in the buffer.
>   /// If 'BufferID' is provided 'Loc' must come from that buffer.
>   std::pair
>   getLineAndColumnInBuffer(SourceLoc Loc, unsigned BufferID = 0) const;
> 
>   /// }
> 
>   /// @{
>   /// Virtual buffer-name, line, and column.
>   /// These methods does respect '#sourceLocation'
> 
>   /// Returns the virtual filename string for the Loc.
>   /// If 'BufferID' is provided 'Loc' must come from that buffer.
>   StringRef
>   getVirtualFilenameForLoc(SourceLoc Loc, unsigned BufferID = 0) const;  
> 
>   /// Returns the pair of line and column in the buffer
>   /// respecting #sourceLocation directive.
>   /// If 'BufferID' is provided 'Loc' must come from that buffer.
>   std::pair
>   getVirtutalLineAndColumnForLoc(SourceLoc Loc, unsigned BufferID = 0) const;
> 
>   /// }
> 
> Roughly:
> 
> Remove: getLineNumber
> ASIS: getIdentifierForBuffer(BufferID)
> Add: getIdentifierForBuffer(Loc) // overload
> Add:  getLineAndColumnInBuffer
> Rename: getBufferIdentifierForLoc => getVirtualFilenameForLoc
> Rename: getLineAndColumn => getVirtutalLineAndColumnForLoc
> 
> 
> Audit every current usage of these methods
> 
> We already have several mix usage of them. For example:
> 
> getLineNumber & getLineAndColumn
> https://github.com/apple/swift/blob/6293546/lib/AST/RawComment.cpp#L61-L63 
> 
> 
> getIdentifierForBuffer & getLineAndColumn
> https://github.com/apple/swift/blob/6293546/lib/Frontend/SerializedDiagnosticConsumer.cpp#L242
>  
> 
> https://github.com/apple/swift/blob/6293546/lib/Frontend/SerializedDiagnosticConsumer.cpp#L451
>  
> 
> 
> SourceFile::getFilename & getLineAndColumn
> https://github.com/apple/swift/blob/6293546/lib/SILGen/SILGenProfiling.cpp#L706
>  
> 
> 

Re: [swift-dev] Debugging with Xcode/LLDB

[Jordan Rose via swift-dev]

Hi, Pawel. Unfortunately, this is what happens to inlinable code in debug 
builds (not just for LLDB, Xcode, or the Swift compiler). The debugger doesn’t 
have the body of inlinable functions, and the binary doesn’t have a copy of the 
code (since it was always inlined away). You have a handful of options here:

1. Poke at the members of SmallVectorImpl directly. (BeginX and EndX are the 
useful ones.)
2. Load the “data formatters” provided with LLVM into your LLDB session: 
`command script import llvm/utils/lldbDataFormatters.py`. This very 
conveniently shows formatted views of certain LLVM types, including 
SmallVector, without running code in the process you’re debugging. (This also 
isn’t magic; you can write your own for your own types, and we totally could 
write some for Swift types.)
3. Use a debug compiler, where nothing will get inlined away. Sometimes this is 
necessary anyway because it’s always hard to debug optimized code, but it does 
have its downsides.

Some day we’ll also have

4. `expr @import LLVMADT` (or similar), to have LLDB pull in all the 
declarations from the LLVM ADT headers using the modules 
 feature. Support for C++ modules is 
still pretty shaky, but it should still be possible to do this with LLVM, which 
has its headers properly grouped into modules. I haven’t tried it, though, and 
Swift hasn’t undergone this treatment yet.

Hope that helps,
Jordan


> On Mar 8, 2017, at 00:00, Pawel Szot (PGS Software) via swift-dev 
>  wrote:
> 
> Hi,
> I’m using LLDB when debugging in Xcode. `p x->dump()` works fine, but what 
> about vectors? For example `SmallVectorImpl` doesn’t offer `dump()`, and I 
> can’t even get it’s size:
> ```
> error: Couldn't lookup symbols:
>  __ZNK4llvm25SmallVectorTemplateCommonIN5swift11constraints8SolutionEE4sizeEv
> ```
> ___
> 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (master) #8580

[Jordan Rose via swift-dev]

It's sporadic. We've been mostly unable to reproduce it on demand and aren't 
yet sure why it occurs. Hopefully this week we'll get it!

Jordan

> On Feb 26, 2017, at 22:54, Andrew Trick via swift-dev  
> wrote:
> 
> Building CoreAudio on armv7k:
> 
> (dependent_member_type assoc_type=Swift.(file).Strideable.Stride
>   (base=generic_type_param_type depth=0 index=0 decl=Swift.(file).func 
> decl.T))
> deserialization produced an invalid type (rdar://problem/30382791 
> )
>  <>UNREACHABLE executed at 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swift/lib/Serialization/Deserialization.cpp:4246!
> 
> Looks like there’s already a radar for this. Slava, I don’t know if this is 
> just sporadic or if you've exposed something.
> 
> -Andy
> 
>> On Feb 26, 2017, at 10:50 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#8580]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-RA-osx/8580/ 
>> 
>> Project: oss-swift-incremental-RA-osx
>> Date of build:   Sun, 26 Feb 2017 22:43:33 -0800
>> Build duration:  6 min 52 sec
>> Identified problems:
>> 
>> Assertion failure: This build failed because of an assertion failure. Below 
>> is a list of all errors in the build log:
>> Indication 1 
>> 
>> Changes
>> 
>> Commit 38d44c216405817bd8f42b474b7aa968eb12f364 by atrick:
>> AddressLowering: rewrite the call-site lowering logic.
>> 
>> edit: test/SILOptimizer/address_lowering.sil
>> edit: include/swift/SIL/SILBuilder.h
>> edit: include/swift/SIL/SILFunctionConventions.h
>> edit: lib/SILOptimizer/Mandatory/AddressLowering.cpp
>> 
>> Commit 754c7feb2669bf93ec80a9d30ed4c38b9c279a55 by spestov:
>> IRGen: Use SubstitutionMap in one spot
>> 
>> edit: lib/IRGen/IRGenSIL.cpp
>> 
>> Commit 0af2845c6ddfb2e3e2afa5569cec278dd4bdf9e6 by spestov:
>> SILGen: Emission of materializeForSet for generic subscripts
>> 
>> edit: lib/SILGen/SILGenLValue.cpp
>> edit: test/SILGen/lifetime.swift
>> edit: test/SILGen/accessors.swift
>> edit: lib/SIL/SILVerifier.cpp
>> edit: test/SILGen/materializeForSet.swift
>> edit: test/SILGen/constrained_extensions.swift
>> edit: test/SILGen/addressors.swift
>> edit: test/SILGen/properties.swift
>> edit: test/SILOptimizer/devirt_materializeForSet.swift
>> edit: lib/SIL/TypeLowering.cpp
>> edit: lib/SILGen/SILGenMaterializeForSet.cpp
>> edit: include/swift/SIL/TypeLowering.h
>> 
>> Commit 8b0094fe42d1081c3cc43a952f788a1d345d64ec by spestov:
>> Add executable test for generic subscripts
>> 
>> add: test/Interpreter/generic_subscript.swift
>> 
>> Commit fa8f2ce503f114987e80f81846b0bc2f5286f28d by spestov:
>> Add CHANGELOG.md entries for SE-0110 and SE-0148
>> 
>> edit: CHANGELOG.md
> 
> ___
> 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 - Long Test (master) #785

[Jordan Rose via swift-dev]

Ahmed, I suspect this is just LLVM and Clang getting out of sync, and the next 
build should pass?

/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:278:45:
 error: no type named 'DiagnosticInfoWithDebugLocBase' in namespace 'llvm'; did 
you mean 'DiagnosticInfoWithLocationBase'?

Jordan


> On Feb 24, 2017, at 13:02, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10-long-test [#785]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/785/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10-long-test
> Date of build:Fri, 24 Feb 2017 12:52:00 -0800
> Build duration:   10 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 
> 
> Changes
> 
> Commit 13287514a013614e95418c459a5416db6b599830 by hughbellars:
> Get the REPL building on Linux
> 
> edit: lib/Immediate/REPL.cpp
> edit: CMakeLists.txt
> 
> Commit 8943ad6cc402a66eedb91c741044f61e2d5c1b5a by hughbellars:
> Improve the error message for an unsupported system or architecture in
> 
> edit: utils/swift_build_support/swift_build_support/targets.py
> 
> Commit 184b6394f01ce426b7fafa980a39dffc6faea99d by hughbellars:
> Improve the error message for a platform without a Toolchain
> 
> edit: utils/swift_build_support/swift_build_support/toolchain.py
> 
> Commit 00b8913efa28360962bc172891aecb23fa3409ba by hughbellars:
> Fix mismatching path to ICU source in build-script and build-script-impl
> 
> edit: utils/swift_build_support/swift_build_support/products/product.py
> edit: utils/build-script
> edit: utils/swift_build_support/swift_build_support/products/libicu.py
> 
> Commit bab7bbd283f8e015aedf15e804ecd570cba2a4a7 by hughbellars:
> Report a fatal error in build-script rather than build-script-impl for
> 
> edit: utils/build-script
> edit: utils/build-script-impl
> 
> Commit 83795ecd066f4849c0b0ee5817a8ca87593c81f8 by hughbellars:
> Fix source code paths of corelibs products in build-sciript
> 
> edit: utils/swift_build_support/swift_build_support/products/foundation.py
> edit: utils/swift_build_support/swift_build_support/products/xctest.py
> edit: utils/swift_build_support/swift_build_support/products/libdispatch.py
> 
> Commit 904ef577d2e700aac6d82563872e1ab1240c7ca8 by hughbellars:
> Cleanup android import in build-script
> 
> add: utils/android/__init__.py
> edit: utils/build-script
> 
> Commit 409a214f8505b8b1ecf0607256146fa11eaf018b by hughbellars:
> Fix build-script shell to work on Windows
> 
> edit: utils/swift_build_support/swift_build_support/shell.py
> 
> Commit cac44b2a33568707b93371ad3be26930741e97de by jordan_rose:
> Disable Foundation.Data test that fails with resilience enabled.
> 
> edit: test/stdlib/TestData.swift
> 
> Commit d697c2fdcb7770521a8a119dce91d61386508059 by dgregor:
> [GenericSig Builder] Diagnose redundant same-typeo-t-concrete
> 
> edit: include/swift/AST/DiagnosticsSema.def
> edit: include/swift/AST/GenericSignatureBuilder.h
> edit: lib/AST/GenericSignatureBuilder.cpp
> edit: test/attr/attr_specialize.swift
> edit: test/Constraints/same_types.swift
> 
> Commit a23b44fa96de8d0d236b1a52853a4cb2999ad422 by ahmed.bougacha:
> [GlobalISel] Simplify StringRef parameters. NFC.
> 
> edit: utils/TableGen/GlobalISelEmitter.cpp
> 
> Commit ca388a5e95145417b25b2aa57b3a91d602c4ea9b by ahmed.bougacha:
> [GlobalISel] Return an Expected for each SDAG pattern. NFC.
> 
> edit: utils/TableGen/GlobalISelEmitter.cpp
> 
> Commit e6295822fcb99b1a0cada5da7a2ddff04520ccaf by ahmed.bougacha:
> [Tablegen] Instrumenting table gen DAGGenISelDAG
> 
> edit: lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
> edit: CMakeLists.txt
> edit: utils/TableGen/DAGISelMatcherEmitter.cpp
> edit: cmake/modules/TableGen.cmake
> edit: include/llvm/CodeGen/SelectionDAGISel.h
> 
> Commit 9198723576557d4a99f8d7a3631f65fdbe384715 by ahmed.bougacha:
> [globalisel] Separate the SelectionDAG importer from the emitter. NFC
> 
> edit: utils/TableGen/GlobalISelEmitter.cpp
> 
> Commit d5eebbefa9728cf797017b78ba738faa1e80e8a7 by ahmed.bougacha:
> [globalisel] OperandPredicateMatcher's shouldn't need to generate the
> 
> edit: test/TableGen/GlobalISelEmitter.td
> edit: utils/TableGen/GlobalISelEmitter.cpp
> 
> Commit a6c10f8bbe2f89eb1830e4b68b2300d206991aa9 by ahmed.bougacha:
> tablegen: Fix android build
> 
> edit: utils/TableGen/GlobalISelEmitter.cpp
> 
> Commit 3a8ae81bb307acd6216c546f2d1d008f379c3f52 by ahmed.bougacha:
> MIRTests: Remove unnecessary 2>&1 redirection
> 
> edit: test/CodeGen/AVR/pseudo/ASRWRd.mir
> edit: test/CodeGen/AVR/pseudo/PUSHWRr.mir
> 

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (master) #8539

[Jordan Rose via swift-dev]

Doug?

> On Feb 23, 2017, at 15:05, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#8539]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/8539/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Thu, 23 Feb 2017 14:35:52 -0800
> Build duration:   29 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit 51d07154340e2f776636407563f7041200b92aaf by jordan_rose:
> [CMake] Update dependencies for CloudKit for Apple-internal configs.
> 
> edit: stdlib/public/SDK/CloudKit/CMakeLists.txt
> 
> Commit e71788d7a6cf1992210efff67fae999b1d8ab6d7 by dgregor:
> [GenericSigBuilder] Conformances due to concrete types can be abstract.
> 
> edit: test/Generics/requirement_inference.swift
> edit: lib/AST/GenericSignatureBuilder.cpp
> 
> Commit cbbf4154359f62c628f1b171de253fa4ab1f23e1 by dgregor:
> [GenericSigBuilder] Archetypes no longer make it to this path. NFC
> 
> edit: lib/AST/GenericSignatureBuilder.cpp

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

Re: [swift-dev] Failure in Swift-Unit :: Syntax/SwiftSyntaxTests/TypeSyntaxTest.MetatypeTypeWithAPIs

[Jordan Rose via swift-dev]

I'll XFAIL it for you for now.

> On Feb 20, 2017, at 10:19, David Farler  wrote:
> 
> Ah, NoAsserts builds, of course. The test checks for assertion failure :). I 
> will fix it up. I am AFK until after lunch - is it ok to wait until then?
> 
> David
> 
> On Feb 20, 2017, at 10:00 AM, Jordan Rose  > wrote:
> 
>> https://ci.swift.org/job/oss-swift_tools-R_stdlib-RD_test-simulator/1223/ 
>> 
>> 
>> Not sure why there wasn't a failure email for this, but the no-asserts full 
>> build bot has been failing steadily on one of the new Syntax tests. David, 
>> can you look into it?
>> 
>> Jordan
>> 
>>  TEST 'Swift-Unit :: 
>> Syntax/SwiftSyntaxTests/TypeSyntaxTest.MetatypeTypeWithAPIs' FAILED 
>> 
>> 
>> Note: Google Test filter = TypeSyntaxTest.MetatypeTypeWithAPIs
>> [==] Running 1 test from 1 test case.
>> [--] Global test environment set-up.
>> [--] 1 test from TypeSyntaxTest
>> [ RUN  ] TypeSyntaxTest.MetatypeTypeWithAPIs
>> /Users/buildnode/jenkins/workspace/oss-swift_tools-R_stdlib-RD_test-simulator/swift/unittests/Syntax/TypeSyntaxTests.cpp:352:
>>  Failure
>> Death test: { SyntaxFactory::makeBlankMetatypeType() 
>> .withBaseTypeSyntax(Int) .withDotToken(Dot) 
>> .withTypeToken(SyntaxFactory::makeIdentifier("WRONG", {}, {})); }
>> Result: failed to die.
>>  Error msg:
>> [  DEATH   ] 
>> [  FAILED  ] TypeSyntaxTest.MetatypeTypeWithAPIs (2 ms)
>> [--] 1 test from TypeSyntaxTest (2 ms total)
>> 
>> [--] Global test environment tear-down
>> [==] 1 test from 1 test case ran. (2 ms total)
>> [  PASSED  ] 0 tests.
>> [  FAILED  ] 1 test, listed below:
>> [  FAILED  ] TypeSyntaxTest.MetatypeTypeWithAPIs
>> 
>>  1 FAILED TEST
>> 
>> 
>> 
>> 

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

Re: [swift-dev] [Swift CI] Build Still Failing: 1. OSS - Swift (Tools Opt+Assert, Stdlib Opt+DebInfo+Assert, Resilience) - macOS (master) #116

[Jordan Rose via swift-dev]

This bot has three separate issues:

- A flaky TSan test (that I thought Kuba disabled, but apparently not)
- A Foundation overlay test that Philippe knows about but hasn't gotten around 
to yet
- A SILGen failure that looks related to Michael's work on SIL ownership

Michael, can you look into the last one if it's not fixed yet? This is 
SILGen/opaque_values_silgen.swift, specifically with a resilience-enabled build.


> On Feb 20, 2017, at 05:18, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift_tools-RA_stdlib-RDA_test-macos-resilience [#116]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RDA_test-macos-resilience/116/
>  
> 
> Project:  oss-swift_tools-RA_stdlib-RDA_test-macos-resilience
> Date of build:Mon, 20 Feb 2017 03:47:00 -0800
> Build duration:   1 hr 31 min
> Identified problems:
> 
> Assertion failure: This build failed because of an assertion failure. Below 
> is a list of all errors in the build log:
> Indication 1 
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit 70054ba09e83fceb684570902d513e8f0375d952 by hughbellars:
> Fix build, edit, build loop on Windows
> 
> edit: cmake/modules/SwiftSource.cmake
> 
> Commit c6b32aea2c6166513fdd14dfbd79bba5d05a4eff by mgottesman:
> [silgen] Add APIs for creating managed buffers and managed rvalues in a
> 
> edit: lib/SILGen/SILGenFunction.h
> edit: lib/SILGen/SILGenDecl.cpp
> 
> Commit aa9efae56288e41a3686a340e4ec8cda84657a2b by jans.pavlovs:
> Update map example code
> 
> edit: stdlib/public/core/Sequence.swift
> 
> Commit bdb4195de8c5f33c25d5d192bc69ca6fa1d7efb3 by mgottesman:
> [silgen] ManagedValue::{formalEvaluationBorrow,formalAccessBorrow}()
> 
> edit: lib/SILGen/SILGenLValue.cpp
> edit: lib/SILGen/ManagedValue.cpp
> edit: lib/SILGen/ManagedValue.h
> 
> Commit 0ae6c2523882be544bb808b0d5a1f20df02e51c1 by mgottesman:
> [silgen] Make SILGenBuilder::createCopyValue a drop in replacement for
> 
> edit: lib/SILGen/SILGenBuilder.h
> edit: lib/SILGen/ManagedValue.cpp
> edit: lib/SILGen/SILGenBuilder.cpp
> 
> Commit 6b05692d31a24fb1d1f19695e778412ea6775ab8 by mgottesman:
> [silgen] Remove incorrect assumptions in
> 
> edit: lib/SILGen/ManagedValue.cpp
> edit: lib/SILGen/ManagedValue.h
> 
> Commit 5717eeba673a3ad6be689d057ab4868fde2a1580 by mgottesman:
> [silgen] Create a ManagedValue::formalAccessCopy(SILGenFunction &,
> 
> edit: lib/SILGen/ManagedValue.h
> edit: lib/SILGen/ManagedValue.cpp
> edit: lib/SILGen/SILGenBuilder.cpp
> edit: lib/SILGen/SILGenBuilder.h
> 
> Commit 9a964034960c2ec5cae78336813b63093f8bfe2a by mgottesman:
> [silgen] Refactor prepareArchetypeCallee to use a builder class instead
> 
> edit: lib/SILGen/SILGenApply.cpp
> 
> Commit 53b777cf9c1cf1891c6134c2b67ea3e58e620394 by mgottesman:
> [silgen] Add an assert that formalAccessCopy is only called in a
> 
> edit: lib/SILGen/ManagedValue.cpp
> 
> Commit 825765a0479379e2d7f842452370860954506d66 by mgottesman:
> [silgen] Change createFormalAccessCopyAddr to take take/init parameters.
> 
> edit: lib/SILGen/ManagedValue.cpp
> edit: lib/SILGen/SILGenBuilder.cpp
> edit: lib/SILGen/SILGenBuilder.h
> 
> Commit 5920daa373ce9e6ad9b1c63b2976b7f3491fd0f3 by mgottesman:
> [silgen] Refactor getAddressForInPlaceInitialization onto SGFContext().
> 
> edit: lib/SILGen/SILGenExpr.cpp
> edit: lib/SILGen/SILGenFunction.h
> 
> Commit dd5120e9f0baeb1b0f16d8b867e0488aa99acc78 by mgottesman:
> [silgen] Create a closure API called bufferForExprResult based on
> 
> edit: lib/SILGen/SILGenBuilder.cpp
> edit: lib/SILGen/SILGenBuiltin.cpp
> edit: lib/SILGen/SILGenLValue.cpp
> edit: lib/SILGen/SILGenApply.cpp
> edit: lib/SILGen/SILGenConvert.cpp
> edit: lib/SILGen/SILGenBuilder.h
> 
> Commit d4a5fe58beee33996e8cab2cace68b60d9ca780c by rudkx:
> Attempt to bind the result of unwrapping optionals if we're asked to
> 
> edit: test/Constraints/closures.swift
> edit: lib/Sema/CSSolver.cpp
> 
> Commit 1e17d86836d2f8851d462d7397c638872b9581f3 by mgottesman:
> [silgen] Change one instance of switch_enum{_addr} that were using
> 
> edit: test/SILGen/implicitly_unwrapped_optional.swift
> edit: test/SILGen/optional.swift
> edit: lib/SILGen/SILGenConvert.cpp
> edit: test/SILGen/objc_bridging.swift
> edit: 

[swift-dev] Bots in bad shape, but possibly a good thing for us

[Jordan Rose via swift-dev]

Hi, all. You might have noticed this morning that quite a few of the bots have 
broken with an assertion failure in deserialization. This is mostly a good 
thing for us, because we suspect that a non-deterministic issue has just gotten 
a lot more frequent. Doug, Slava, and I are looking into the issue, but 
meanwhile I’m going to speculatively revert Slava’s commit so we go back to the 
broken-but-still-mostly-blue state we were in before.

Hoping to squash this very soon.

Jordan___
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 - Swift Incremental RA - OS X (master) #8384

[Jordan Rose via swift-dev]

Looks like yours, Vedant?


> On Feb 14, 2017, at 15:22, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-osx [#8384]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/8384/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Tue, 14 Feb 2017 15:01:57 -0800
> Build duration:   20 min
> Identified problems:
> 
> Assertion failure: This build failed because of an assertion failure. Below 
> is a list of all errors in the build log:
> Indication 1 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 1 test(s), Passed: 8972 test(s), Total: 8973 test(s)
> Failed: Swift(macosx-x86_64).IRGen.coverage.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 370 test(s), Total: 370 test(s)
> 
> Changes
> 
> Commit 6d174f96529ed86bc3463053e0b495796a2e4449 by vsk:
> [profiling] Update test cases to deal with name variable change (NFC)
> 
> edit: test/Profile/cxx-virtual-destructor-calls.cpp
> edit: test/CoverageMapping/unused_names.c
> 
> Commit b816d5bcf524ba422c8a1b3b0c71704001f2f5c3 by vsk:
> Re-apply "[profiling] Remove dead profile name vars after emitting name
> 
> edit: test/Instrumentation/InstrProfiling/platform.ll
> edit: lib/Transforms/Instrumentation/InstrProfiling.cpp
> edit: test/Instrumentation/InstrProfiling/PR23499.ll
> edit: test/Instrumentation/InstrProfiling/profiling.ll
> edit: test/Transforms/PGOProfile/comdat_internal.ll
> 
> Commit 03d55cd0232933765272e612079a447e08f200c5 by shajrawi:
> Support for address based array initialization under opaque values mode
> 
> edit: test/SILGen/opaque_values_silgen_todo.swift
> edit: test/SILGen/opaque_values_silgen.swift
> edit: lib/SILGen/SILGenApply.cpp
> 
> Commit 1f04b2fecfa84969036e1dd4babdb15dd6693815 by dgregor:
> [Serialization] Wire up the generic parameter of a protocol early.
> 
> edit: lib/Serialization/Deserialization.cpp

___
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 14.04 - Long Test (master) #1033

[Jordan Rose via swift-dev]

Huon, Dave, any idea what's up with this one?

/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/stdlib/public/core/8/ExistentialCollection.swift:1833:17:
 error: '_CollectionBox' requires the types 'Element' and 
'C.SubSequence.Iterator.Element' be equivalent
self._box = _CollectionBox(
^
/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/stdlib/public/core/8/ExistentialCollection.swift:567:22:
 note: requirement specified as 'S.Iterator.Element' == 
'S.SubSequence.Iterator.Element' [with S = C]
internal final class _CollectionBox : 
_AnyCollectionBox
 ^

My reverts shouldn't have anything to do with this; they're all of Roman's SIL 
work.



> On Feb 13, 2017, at 13:05, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#1033]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/1033/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04-long-test
> Date of build:Mon, 13 Feb 2017 12:44:15 -0800
> Build duration:   21 min
> 
> Changes
> 
> Commit f0c0bd87915461189b907c947bf87f4332b4151b by jordan_rose:
> Revert "Merge pull request #7401 from
> 
> edit: lib/SIL/SILModule.cpp
> 
> Commit 1c60910198c8da69d65d5c9e22e61c6c5b835c75 by jordan_rose:
> Revert "Merge pull request #6092 from
> 
> edit: lib/SIL/Linker.cpp
> edit: test/SILOptimizer/devirt_covariant_return.swift
> edit: lib/AST/Substitution.cpp
> edit: lib/SIL/SILModule.cpp
> edit: lib/SILOptimizer/Transforms/FunctionSignatureOpts.cpp
> edit: stdlib/public/SwiftOnoneSupport/CMakeLists.txt
> edit: include/swift/SIL/SILModule.h
> edit: lib/Serialization/DeserializeSIL.h
> edit: test/SILOptimizer/opened_archetype_operands_tracking.sil
> edit: test/SILOptimizer/prespecialize.swift
> edit: lib/SILOptimizer/Utils/Generics.cpp
> edit: include/swift/Serialization/SerializedSILLoader.h
> edit: test/SILOptimizer/devirt_specialized_conformance.swift
> edit: include/swift/SILOptimizer/Utils/Devirtualize.h
> edit: lib/IRGen/IRGenSIL.cpp
> edit: lib/Serialization/SerializedSILLoader.cpp
> edit: lib/SILOptimizer/IPO/EagerSpecializer.cpp
> edit: test/SILOptimizer/devirt_protocol_method_invocations.swift
> edit: lib/Serialization/DeserializeSIL.cpp
> edit: test/SILGen/collection_cast_crash.swift
> edit: lib/SIL/Linker.h
> edit: lib/SILOptimizer/Transforms/PerformanceInliner.cpp
> edit: lib/SILOptimizer/Utils/Devirtualize.cpp
> edit: test/SILOptimizer/devirt_unbound_generic.swift
> 
> Commit c86f8e708988191cc6c4c4ebcdb4ffde74347bcc by github:
> [Serialization] Improve extensions of nested types with the same name
> 
> edit: lib/Serialization/Serialization.cpp
> add: test/Serialization/xref-extensions.swift
> add: test/Serialization/Inputs/def_xref_extensions_distraction.swift
> add: validation-test/Serialization/Inputs/SR3915-other.swift
> edit: lib/Serialization/Deserialization.cpp
> add: validation-test/Serialization/SR3915.swift
> edit: include/swift/Serialization/ModuleFormat.h
> edit: lib/Serialization/ModuleFile.cpp
> edit: include/swift/Serialization/ModuleFile.h
> add: test/Serialization/Inputs/def_xref_extensions.swift
> edit: lib/Serialization/Serialization.h

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

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 14.04 (master) #233

[Jordan Rose via swift-dev]

Ah, I see it's already been fixed. Sorry for the noise!

> On Feb 10, 2017, at 09:57, Jordan Rose via swift-dev <swift-dev@swift.org> 
> wrote:
> 
> Looks like an actual llbuild issue. Hey, Daniel, we're not using C++14 yet!
> 
> /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/llbuild/lib/BuildSystem/BuildFile.cpp:863:24:
>  error: no template named 'make_unique' in namespace 'std'; did you mean 
> 'llvm::make_unique'?
> auto description = std::make_unique();
>^~~~
>llvm::make_unique
> 
> Jordan
> 
> 
>> On Feb 9, 2017, at 16:36, no-reply--- via swift-dev <swift-dev@swift.org 
>> <mailto:swift-dev@swift.org>> wrote:
>> 
>> [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#233]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/233/ 
>> <https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/233/>
>> Project: oss-swift-package-linux-ubuntu-14_04
>> Date of build:   Thu, 09 Feb 2017 16:12:19 -0800
>> Build duration:  23 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 
>> <https://ci.swift.org//job/oss-swift-package-linux-ubuntu-14_04/233/consoleFull#1465163075ee1a197b-acac-4b17-83cf-a53b95139a76>
> 
> ___
> 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] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 14.04 (master) #233

[Jordan Rose via swift-dev]

Looks like an actual llbuild issue. Hey, Daniel, we're not using C++14 yet!

/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-14_04/llbuild/lib/BuildSystem/BuildFile.cpp:863:24:
 error: no template named 'make_unique' in namespace 'std'; did you mean 
'llvm::make_unique'?
auto description = std::make_unique();
   ^~~~
   llvm::make_unique

Jordan


> On Feb 9, 2017, at 16:36, no-reply--- via swift-dev  
> wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#233]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/233/ 
> 
> Project:  oss-swift-package-linux-ubuntu-14_04
> Date of build:Thu, 09 Feb 2017 16:12:19 -0800
> Build duration:   23 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 
> 

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

Re: [swift-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (swift 3.1) #55

[Jordan Rose via swift-dev]

Lost the builder machine. Mishal, do you think we should run it again, since 
this bot only runs once a day?

Jordan


> On Feb 10, 2017, at 00:49, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-3.1-incremental-ASAN-RA-osx [#55]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-3.1-incremental-ASAN-RA-osx/55/ 
> 
> Project:  oss-swift-3.1-incremental-ASAN-RA-osx
> Date of build:Fri, 10 Feb 2017 00:27:50 -0800
> Build duration:   21 min
> 
> Changes
> 
> Commit 3144d280b9c61fff4ec90cb5337db9f2308d7e5c by dgregor:
> Revert "Replace concrete init(stringInterpolationSegment:)'s with
> 
> edit: stdlib/public/core/StringInterpolation.swift.gyb
> delete: validation-test/Sema/interpolation_placeholders.swift
> edit: test/api-digester/source-stability.swift.expected
> 
> Commit bb4a29c816d1f603e74071b2a0a862b246250d40 by dgregor:
> [SR-3842] Add test from the bug report. We want to keep this working in
> 
> add: test/Compatibility/sr3842_map_string_init.swift
> 
> Commit 97a2f11c79f90a5e5d7551d546b1ce7f6a426832 by spestov:
> Sema: Fix crash when defining an extension of a nested type with
> 
> edit: test/decl/nested/type_in_type.swift
> edit: include/swift/AST/ArchetypeBuilder.h
> edit: lib/AST/ArchetypeBuilder.cpp
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: lib/Sema/TypeCheckGeneric.cpp
> 
> Commit 3c6d6cbbd6b55bafa37d77182bc6acb593d70839 by jgroff:
> Sema: Treat the implicit RawRepresentable conformance for enums as
> 
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: lib/AST/ConformanceLookupTable.h
> edit: lib/AST/ConformanceLookupTable.cpp
> add: test/Sema/enum_raw_representable_explicit_cart_before_horse.swift
> add: test/Sema/Inputs/enum_raw_representable_explicit_multi_file_2.swift
> add: test/Sema/enum_post_hoc_raw_representable_with_raw_type.swift
> add: test/Sema/enum_raw_representable_explicit.swift
> add: test/Sema/enum_raw_representable_explicit_multi_file.swift
> edit: test/decl/protocol/conforms/Inputs/placement_2.swift
> add: test/Sema/Inputs/enum_with_raw_type.swift
> edit: lib/Sema/TypeCheckProtocol.cpp
> edit: test/decl/protocol/conforms/placement.swift
> edit: lib/AST/ProtocolConformance.cpp
> 
> Commit e1d1a1fefeb53a1d25f910cabb0bb4392ea522d3 by jacobmizraji:
> sourcekitd/CMakeLists.txt: Add a flag for building sourcekitdInProc as a
> 
> edit: tools/SourceKit/tools/sourcekitd/bin/InProc/CMakeLists.txt
> 
> Commit 0c571ab0dd5aa52d9c7c308b44cfcd14cb593139 by jacobmizraji:
> [test] Time out individual lit tests after 20 minutes.
> 
> edit: test/CMakeLists.txt
> 
> Commit f39bfb1c21bbdfd0c492cf914d0f722b58ce4bcd by jacobmizraji:
> [test] Increasing test timeout to 30 minutes
> 
> edit: test/CMakeLists.txt
> 
> Commit 34ae0a321ca004eec4bb21ed14a9878c4479fa7e by jacobmizraji:
> Increase the test timeout to 50mins
> 
> edit: test/CMakeLists.txt
> 
> Commit c8691358aaea762829c8c129edae791eefe1740a by jordan_rose:
> When setting a willSet/didSet param's type, also set the TypeLoc (#7377)
> 
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: test/decl/var/properties.swift
> 
> Commit dc9990c9d594315b6101068ed2a8861d545b5007 by arphaman:
> [code-completion] Fix crash when trying to do postfix completion of
> 
> edit: test/CodeCompletion/member-access.cpp
> edit: lib/Parse/ParseExpr.cpp
> 
> Commit 9bd5590746b4180e753d547b8653bdb2dc56ae0e by arphaman:
> [Sema][ObjC++] Typo correction should handle ivars and properties
> 
> edit: lib/Sema/SemaExprCXX.cpp
> edit: lib/Sema/TreeTransform.h
> edit: test/SemaObjCXX/typo-correction.mm
> 
> Commit 0d4427d10d6971c36d165d77ba559d8ac059cea5 by bruno.cardoso:
> [PCH] Fix a regression when PCH is used with -fmodules
> 
> add: test/Modules/Inputs/invalid-module-id/NC.framework/Headers/NUGeometry.h
> add: test/Modules/Inputs/invalid-module-id/NC.framework/Headers/NC.h
> add: test/Modules/Inputs/invalid-module-id/NC.framework/PrivateHeaders/NULog.h
> add: 
> test/Modules/Inputs/invalid-module-id/NC.framework/Modules/module.private.modulemap
> add: 
> test/Modules/Inputs/invalid-module-id/NC.framework/PrivateHeaders/NUAssert.h
> add: test/Modules/Inputs/invalid-module-id/NC-Prefix.pch
> add: 
> test/Modules/Inputs/invalid-module-id/NC.framework/Headers/NU-Visibility.h
> add: 
> test/Modules/Inputs/invalid-module-id/NC.framework/Modules/module.modulemap
> edit: lib/Serialization/ASTWriter.cpp
> add: test/Modules/invalid-pch-module-id.m
> 
> Commit 6975c5acb860243efdcb5a156e004ddbbc786a15 by bruno.cardoso:
> Avoid VarDecl emission attempt if no owning module avaiable
> 
> edit: lib/Serialization/ASTReaderDecl.cpp
> add: test/PCH/empty-def-fwd-struct.h
> 
> Commit f186e73135bb053b302a65a5c99fbb5ed63a739e by aprantl:
> Canonicalize the path provided by -fmodules-cache-path.
> 
> edit: lib/Frontend/CompilerInvocation.cpp
> add: test/Modules/modules-cache-path-canonicalization.m

___
swift-dev mailing list
swift-dev@swift.org

Re: [swift-dev] [swift-lldb-dev] Changes to LLDB Branch Management

[Jordan Rose via swift-dev]

> On Feb 9, 2017, at 13:43, Chris Bieneman <be...@apple.com> wrote:
> 
> 
>> On Feb 9, 2017, at 12:09 PM, Jordan Rose via swift-dev <swift-dev@swift.org 
>> <mailto:swift-dev@swift.org>> wrote:
>> 
>> Hi, Chris. I’m a bit confused by these changes. Swift’s master-next isn’t 
>> paired with upstream-with-swift; it’s paired with stable-next, which is 
>> resync’d to upstream-with-swift on a fairly regular cadence. Have you 
>> discussed this with the “merge czars” on the Swift side, who maintain 
>> master-next and stable-next?
> 
> This has been discussed with the “merge czars”, and we may end up creating a 
> stable-next branch, but Bob Wilson suggested that they were considering 
> changes to the merge process that would eliminate the need for that branch.
> 
>> 
>> “upstream-with-trunk” is redundant; the “upstream” referred to in 
>> “upstream-with-swift” is LLVM trunk. “upstream-plus-swift-support” might 
>> have been a better name for the LLVM branch.
> 
> I mis-wrote that. It is “upstream-with-swift” not trunk. The LLDB “upstream” 
> branch will be going away because it is unnecessary to maintain a branch that 
> matches LLVM.org <http://llvm.org/>.


Thanks for the clarification! 

> 
>> 
>> What happens on the LLDB “stable" branch? No development happens on LLVM or 
>> Clang’s “stable” branch; they’re essentially just aliases for the latest 
>> release branch. Does the LLDB “stable” branch build against Swift master or 
>> Swift’s latest release branch?
> 
> LLDB’s stable branch will be maintained in exactly the same way LLVM & 
> Clang’s stable branches are. So it is currently identical to the 
> swift-4.0-branch.

I’m concerned because this means LLDB “stable" builds against Swift master, 
while the release branches all build together. It’s frequent for changes to go 
into Swift master that are not immediately cherry-picked to the latest release 
branch.


> 
>> 
>> When I change something on Swift master that affects LLDB, where do I send a 
>> pull request going forward? It would be very painful for Swift developers to 
>> have a master-next/stable-next build set up just to submit changes to LLDB; 
>> today, most Swift developers don’t even need to think about master-next 
>> unless something breaks.
> 
> Patches to LLDB for swift-related functionality should go into the most 
> current release branch, in the same way we handle LLVM & Clang changes.

Sorry, I don’t mean “patches for LLDB that add or change Swift functionality”. 
I mean “a Swift API changed, here’s a patch so that LLDB can continue 
building”. Admittedly we are not always good about this, but if the place to 
submit LLDB patches isn’t the standard build configuration for Swift, I think 
we’ll be much less likely to submit any at all. We get away with this for Clang 
and LLVM because (a) they do not have any pieces that depend on Swift, and (b) 
very few people make Swift-related changes in Clang and LLVM, so it’s okay if 
the process is a little awkward.

Jordan

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

Re: [swift-dev] Package Manager PR linux bot consistently failing

[Jordan Rose via swift-dev]

[+swift-lldb-dev]

> On Feb 8, 2017, at 04:16, Ankit Aggarwal via swift-dev  
> wrote:
> 
> Hi,
> 
> There is a llvm test failing on linux bots:
> 
> https://ci.swift.org/job/swift-package-manager-PR-Linux/810/ 
> 
> https://ci.swift.org/job/swift-package-manager-PR-Linux/811/ 
> 
> 
> --
> 
> 330 out of 716 test suites processed - TestSwiftStructChangeRerun.py  
>  
> 
> Session logs for test failures/errors/unexpected successes will go into 
> directory '2017-02-08-11_40_01'
> Command invoked: 
> /home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/test/dotest.py
>  --executable 
> /home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/lldb-linux-x86_64/bin/lldb
>  --rerun-all-issues -C 
> /home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/llvm-linux-x86_64/bin/clang
>  -s 2017-02-08-11_40_01 --results-port 45312 -S fnmac --inferior -p 
> TestWeakSelf.py 
> /home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test
>  --event-add-entries worker_index=10:int
> 
> Configuration: arch=x86_64 
> compiler=/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/llvm-linux-x86_64/bin/clang
> --
> Collected 3 tests
> 
> ==
> FAIL: test_with_dwarf (lldbsuite.test.lldbtest.TestWeakSelf)
> --
> Traceback (most recent call last):
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 153, in __test_with_dwarf
> self.do_test()
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 186, in do_test
> parser.handle_breakpoint(self, breakpoint_id)
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 85, in handle_breakpoint
> test.execute_user_command(breakpoint['command'])
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 168, in execute_user_command
> exec(__command, globals(), locals())
>   File "", line 1, in 
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 2251, in expect
> msg if msg else EXP_MSG(str, output, exe))
> AssertionError: False is not True : Data type(s) displayed correctly
> Config=x86_64-/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/llvm-linux-x86_64/bin/clang-4.0
> ==
> FAIL: test_with_dwo (lldbsuite.test.lldbtest.TestWeakSelf)
> --
> Traceback (most recent call last):
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 159, in __test_with_dwo
> self.do_test()
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 186, in do_test
> parser.handle_breakpoint(self, breakpoint_id)
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 85, in handle_breakpoint
> test.execute_user_command(breakpoint['command'])
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 168, in execute_user_command
> exec(__command, globals(), locals())
>   File "", line 1, in 
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 2251, in expect
> msg if msg else EXP_MSG(str, output, exe))
> AssertionError: False is not True : Data type(s) displayed correctly
> Config=x86_64-/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/llvm-linux-x86_64/bin/clang-4.0
> ==
> FAIL: test_with_gmodules (lldbsuite.test.lldbtest.TestWeakSelf)
> --
> Traceback (most recent call last):
>   File 
> "/home/buildnode/disk2/workspace/swift-package-manager-PR-Linux/lldb/packages/Python/lldbsuite/test/lldbinline.py",
>  line 165, in __test_with_gmodules
> self.do_test()
>   File 
> 

Re: [swift-dev] No return functions and program exit

[Jordan Rose via swift-dev]

I’ve said this Michael in person, but I’ll put it on the thread for others to 
see:

I don’t think modeling this is worth the increase in complexity. There’s a 
partial workaround for anyone who notices this being a problem, which is to put 
any expensive work in a ‘do’ block. And actually emitting cleanups before a 
call to, e.g., dispatch_main would be a change in semantics, which could both 
break existing programs and makes the language a bit harder to reason about. 
The current rule that “defers happen at the close brace, releases may happen 
sooner” is simple. (We certainly would not want to make ‘defer’s happen before 
calling dispatch_main, though perhaps we should warn that they will never be 
executed.)

Furthermore, we have no good way to distinguish these two kinds of functions 
(dispatch_main vs. abort), even less so when many of them come in from C. We’d 
have to invent some new kind of attribute just for this case. (Admittedly, 
since functions like dispatch_main are rare, the attribute doesn’t have to be 
pretty.)

I think this is just a theoretical concern, though admittedly one Michael is 
running into doing his work on explicit ownership in SIL, and I don’t think we 
need to consider changing any behavior here.

Jordan


> On Feb 6, 2017, at 09:48, Michael Gottesman via swift-dev 
>  wrote:
> 
> One thing that is an issue that has come up with ownership is that at the SIL 
> level we do not distinguish in between exceptional noreturn functions and 
> exceptional return functions.
> 
> This is important since in the non-exceptional case, we would like to clean 
> up all of the values used in the current function before calling the 
> no-return function. An example of such a function is dispatch_main from 
> libdispatch. In the exceptional case though, we are ok with leaking since the 
> program will be exiting. Beyond reducing code size (I guess?), the argument I 
> have heard for this is that this will allow for people to examine values in 
> the debugger since we will not have cleaned things up before the abort is 
> called.
> 
> From what I can tell, if we are going to distinguish in between these cases, 
> then we need a distinction in between the two baked into the compiler. 
> Thoughts? I have code written that will enable either case to be handled as 
> long as I can distinguish in between them at the SIL level.
> 
> Michael
> ___
> 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] [Swift CI] Build Still Failing: 1. OSS - Swift (Tools Opt+Assert, Stdlib Opt+DebInfo+Assert, Resilience) - macOS (master) #99

[Jordan Rose via swift-dev]

/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-macos-resilience/swift/test/Prototypes/TextFormatting.swift:118:3:
 error: initializer declared in an extension of non-'@_fixed_layout' type 
'Integer' must delegate to another initializer
  init (_ i: N) {
  ^

Huge blamelist here, unfortunately. Slava, this is the bug where assigning to 
self doesn’t count as delegating to another initializer. Is there a quick fix 
for that?

  init (_ i: N) {
// Implementation based on Egyptian Multiplication of i by 1 allows us to
// avoid any mixed-type numeric operations, which the current standard
// library doesn't support.  Note: we also don't have a protocol that
// provides shift operators, so we use / 2 here.
var n = i
self = 0
// …

Jordan


> On Feb 3, 2017, at 05:10, no-reply--- via swift-dev  
> wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift_tools-RA_stdlib-RDA_test-macos-resilience [#99]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RDA_test-macos-resilience/99/
>  
> 
> Project:  oss-swift_tools-RA_stdlib-RDA_test-macos-resilience
> Date of build:Fri, 03 Feb 2017 03:47:00 -0800
> Build duration:   1 hr 23 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
___
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 14.04 (master) #775

[Jordan Rose via swift-dev]

None of these changes would have affected the failing XCTest test. Adding 
swift-corelibs-dev. 
https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-14_04/775/consoleFull#-936285465fca400bf-2f4a-462e-b517-e058d770b2d7

> *** Error in 
> `/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates':
>  double free or corruption (fasttop): 0x7f7108000a70 ***
> 
> error: command failed with exit status: -6
> $ "true"
> $ 
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker.py"
>  
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/main.swift.tmp"
>  
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift"
> # command stderr:
> Traceback (most recent call last):
>   File 
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker.py",
>  line 15, in 
> xctest_checker.main.main()
>   File 
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker/main.py",
>  line 61, in main
> compare.compare(args.actual, args.expected, args.check_prefix)
>   File 
> "/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker/compare.py",
>  line 85, in compare
> repr(expected_line)))
> xctest_checker.error.XCTestCheckerError: 
> 
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:26:
>  There were more lines expected to appear than there were lines in the actual 
> input. Unmet expectation: 
> '.*/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:32: 
> error: 
> PredicateExpectationsTestCase.test_immediatelyFalsePredicateAndObject_fails : 
> Asynchronous wait failed - Exceeded timeout of 0.1 seconds, with unfulfilled 
> expectations: Expect `` for object 
> '
> 
> 
> 

> On Jan 27, 2017, at 12:05, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#775]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/775/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Fri, 27 Jan 2017 11:31:23 -0800
> Build duration:   33 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit 98ead6bf0471f4d7762aeb47b907b9897252a8d4 by jordan_rose:
> [Verifier] Always check function DeclName / ParamDecl matches.
> 
> edit: lib/AST/ASTVerifier.cpp
> 
> Commit 4020f49f8ee794b8383fff8d2e917311ef678055 by jordan_rose:
> [Verifier] Fix ClangImporter imported decls verification.
> 
> edit: lib/ClangImporter/ImporterImpl.h
> edit: lib/ClangImporter/ClangImporter.cpp
> 
> Commit abb88f94921a962aa19ec39653e62ee05cec48cb by jordan_rose:
> [Verifier] Hack: Don't verify loaded modules in SIL mode.
> 
> edit: lib/Sema/TypeChecker.cpp
> 
> Commit fdbc84f7ec77105b23e2cc8b191112ecd01ba9bb by jordan_rose:
> [Importer] Preserve argument labels even for accessors.
> 
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: lib/ClangImporter/ImporterImpl.h
> edit: test/ClangImporter/Inputs/custom-modules/ObjCParseExtras.h
> edit: lib/ClangImporter/ImportType.cpp
> edit: test/ClangImporter/objc_parse.swift
> 
> Commit 7c8117301aa57ec6cf29d39acb98d1b9f3160f1d by github:
> In Swift 3 mode, allow "tuple unsplatting" in certain cases. (#7077)
> 
> edit: 
> validation-test/compiler_crashers_fixed/26813-generic-enum-tuple-optional-payload.swift
> edit: test/Constraints/tuple_arguments.swift
> edit: lib/Sema/CSSimplify.cpp
> edit: test/Compatibility/tuple_arguments.swift
> edit: validation-test/Sema/type_checker_crashers_fixed/rdar27261929.swift
> 
> Commit 02273a094e4630a73d6846844a648770a5587ce9 by anthony.parker:
> [Documentation] Add doc comments for NSKeyedArchiver (#842)
> 
> edit: 

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Jordan Rose via swift-dev]

> On Jan 26, 2017, at 12:55, Andrew Trick via swift-dev  
> wrote:
> 
>> 
>> On Jan 26, 2017, at 11:38 AM, Graydon Hoare  wrote:
>> 
>> 
>>> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev 
>>>  wrote:
>>> 
>>> Before I pull in a large PR that "accidentally" reformats a bunch of code, 
>>> I want to get feedback on how Swift compiler devs plan to use 
>>> `clang-format`. (BTW, here's the PR 
>>> https://github.com/apple/swift/pull/6922).
>>> 
>>> During the code review, I ran `git clang-format` as part of being a good 
>>> citizen. There's only one problem with the tool. It rewraps long boolean 
>>> expressions, hiding those unsightly operators at the end of lines (after 
>>> all who wants to see those?).
>>> 
>>>  if (some_expression->with_calls() ||
>>>  another_expression->with(nested_calls()) &&
>>>  an_even_longer_expression->making_your_eyes->glaze_over())
>>> 
>>> I don't get involved in style wars, but this is not a style change, it's an 
>>> objective code quality degradation. It's a demonstrably bug-prone thing to 
>>> do. It's hurt me too many times in the past, and I'm not happy using a 
>>> formatting tool that injects future bugs and harms code comprehension.
>> 
>> It's funny you'd mention this! I often format code that way, not out of any 
>> great love of it, but from muscle-memory of living under an old coding 
>> guideline somewhere in the distant past claiming that the ugliness of 
>> trailing unfinished-binops draws the eye to them and makes the user pay 
>> attention. Doug Crockford recommends this style; but of course Don Knuth 
>> agrees with you. I don't feel strongly about them as such, but I feel ... 
>> anti-strongly, I guess? Like changing that one thing isn't worth a 
>> cross-codebase rewrite / merge collision.
> 
> I’m not sure who’s recommending what. The above style obscures operators. 
> Does anyone disagree with that? A lot of code has been written in that way; I 
> think because developers value aesthetics over clarity, or just don’t think 
> about it. I care because when something doesn’t stand out, my brain fills in 
> the gaps with whatever it expects. For me, that leads to a bunch of silly 
> logic errors.
> 
> I need to see it this way:
> 
>  if (some_expression->with_calls()
>  || another_expression->with(nested_calls())
>  && an_even_longer_expression->making_your_eyes->glaze_over())
> 
> The need for parens now stands out. Sorry this isn’t a good example. Nested 
> expressions would make it much more compelling.
> 
> That’s the coding convention we use for Swift code (at least in the stdlib). 
> The compiler C++ code is just a hodge-podge.
> If anyone actually thinks trailing operators are a good idea for our code 
> base, I won’t argue, but I’ve never heard that argument.
> 
> BTW- I’m not interested at all in doing a mass reformatting or forcing a 
> convention on people. I just don’t want to apply clang-format to every line 
> of code I touch without knowing what settings to use.

I've never had a problem with the trailing operators, and find them mildly more 
aesthetically pleasing (when not in an if, it makes it clearer what I plan to 
do with the next line), but I see how they put it in your face in an if. I can 
change my style.

Jordan

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Jordan Rose via swift-dev]

> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev  
> wrote:
> 
>> 
>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir > > wrote:
>> 
>>> 
>>> On Jan 26, 2017, at 9:14 AM, Andrew Trick >> > wrote:
>>> 
>>> 
 On Jan 26, 2017, at 9:11 AM, Ben Langmuir > wrote:
> 
> ** Option 1: Add a simple configuration option to swift/.clang-format:
> 
> 1a. BreakBeforeBinaryOperators: All
> 
> 1b. BreakBeforeBinaryOperators: NonAssignment
 
> 
> I have absolutely no preference between 1a and 1b. It's purely style.
> 
> 1a:
> SomeLongTypeName someLongVariableName =
> someLongExpression();
> 
> 1b:
> SomeLongTypeName someLongVariableName
> = someLongExpression();
 
 1b sounds good to me.
>>> 
>>> I contradicted myself above. If you like the style shown in (1b), the 
>>> configuration option is actually BreakBeforeBinaryOperators: All.
>> 
>> Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check 
>> your example code against the above description :-)
> 
> Alright, I’l reformat my PR with that config, unless anyone else wants to 
> weigh in.
> 
> Incidentally, I despise what clang-format does with asserts now:
>   assert(condition
>  && “text”)
> 
> It’s a consequence of us not using a legit assert package, so I don’t know if 
> I want to push to get clang-format changed.

What do you want it to do with this style of assert?

___
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 - OS X (swift 3.1) #230

[Jordan Rose via swift-dev]

Jenkins error, not my commit.

> On Jan 26, 2017, at 00:13, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-3.1-incremental-RA-osx [#230]
> 
> Build URL:https://ci.swift.org/job/oss-swift-3.1-incremental-RA-osx/230/ 
> 
> Project:  oss-swift-3.1-incremental-RA-osx
> Date of build:Wed, 25 Jan 2017 23:22:53 -0800
> Build duration:   50 min
> 
> Changes
> 
> Commit a2f29b62ed9eb52252b0062301d790b5ff71a4f6 by jordan_rose:
> Use interface types when checking #keyPath. (#7028)
> 
> edit: lib/Sema/TypeCheckExprObjC.cpp
> add: validation-test/compiler_crashers_2_fixed/0064-sr3714.swift

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

Re: [swift-dev] How to test -assume-single-threaded option?

[Jordan Rose via swift-dev]

For anyone following along, frontend flags are not guaranteed to be 
stable (as in, they may be removed in a later version of Swift), nor are they 
guaranteed to produce correct or working code. Jiho’s use is exactly the 
correct one—to check for a difference of behavior in the Swift compiler 
itself—but please do not use these in production code.

Jordan


> On Jan 13, 2017, at 13:50, Slava Pestov via swift-dev  
> wrote:
> 
> Hi Jiho,
> 
> Some low-level frontend flags are not exposed to the driver.
> 
> To pass frontend flags directly via the driver, use -Xfrontend, eg
> 
> swiftc -Xfrontend -assume-single-threaded mytest.swift
> 
> This is different from -frontend — -frontend skips the driver entirely, 
> -Xfrontend runs the driver but passes the next argument to each frontend 
> invocation.
> 
> Slava
> 
>> On Jan 13, 2017, at 1:01 PM, Jiho Choi via swift-dev  
>> wrote:
>> 
>> Hi,
>> 
>> I want to try -assume-single-threaded option to measure the overhead of 
>> atomic operations for reference counting.  However, it seems that the option 
>> works as intended with the frontend but not with the driver.  In other 
>> words, I tried two commands below, and only the first command replaced 
>> atomic operations.
>> 
>> swiftc -frontend -emit-sil -assume-single-threaded mytest.swift
>> swiftc -emit-sil -assume-single-threaded mytest.swift
>> 
>> Is the option disabled for the driver for some reason?
>> 
>> Thanks,
>> Jiho
>> ___
>> 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