Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

[Jordan Rose via swift-corelibs-dev]

Hm. If this is the right setting to set on everybody's system, we could add it 
as part of Clang initialization (for the Clang inside Swift). Otherwise, you 
can use "-Xcc" to pass extra flags to Clang, in this case "-Xcc 
-D_GNU_SOURCE=1".

Hope that helps,
Jordan

> On Dec 20, 2015, at 2:29 , Dmitri Gribenko  wrote:
> 
> + swift-dev, Jordan
> 
> On Sun, Dec 20, 2015 at 2:21 AM, Dan Stenmark via swift-corelibs-dev
>  wrote:
>> I'm trying to invoke Linux's unshare() system call from Swift, but without 
>> much success.  From C, it requires _GNU_SOURCE to be #define'd before the 
>> #include .  The Glibc module map does indeed include sched.h, so 
>> the lack of _GNU_SOURCE appears to be the likely culprit.  What's the 
>> appropriate action to take here?
>> 
>> Dan
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> 
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-corelibs-dev] NSCoding methods

[Jordan Rose via swift-corelibs-dev]

IMHO on Linux NSKeyedArchiver should always use mangled names. If we want 
cross-platform archives, we should set up standard substitutions, but given 
that Swift classes exposed to Objective-C are archived with their full names it 
doesn't make sense to use "half the name" in the archive.

Jordan

> On Dec 19, 2015, at 13:23 , Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> Somewhat; the mangled symbols are technically searchable by dlsym but that 
> seems like a hack. Perhaps one of the stdlib/compiler team might be able to 
> speak more on this than myself and they may have suggestions for a better 
> way. Foundation is at a special spot in which we can sometimes get special 
> runtime considerations for these types of things. 
> 
> The tricksy spot would be cases where you would need to fetch a class without 
> the module name. 
> 
> For example NSUUID is defined by it’s module name Foundation.NSUUID; in that 
> a program could have it’s own NSUUID that is totally different (naming it the 
> same thing would be confusing to read and potentially viewed as bad form but 
> it can be done…). That would result in MyApplication.NSUUID to define the 
> symbolic name of the item. From the perspective of NSKeyedArchiver it will 
> encode things as NSUUID (without the namespace) in that in the realm of objc 
> there can be only one.
> 
> The tl;dr is that there is no manifest of classes or table of names stored in 
> the binaries; just symbols.
> 
>> On Dec 18, 2015, at 10:57 PM, Luke Howard  wrote:
>> 
>> 
>>> Specifically there is no NSClassFromString yet. I would say if you are 
>>> looking for a place to start, perhaps coming up with a good strategy for 
>>> accomplishing that in a uniform manner (for both Foundation classes as well 
>>> as user classes) would be a good step in the right direction to getting 
>>> this started.
>> 
>> Does Swift have enough runtime metadata to do this for native Swift classes?
>> 
>> -- Luke
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

[Jordan Rose via swift-corelibs-dev]

> On Dec 21, 2015, at 10:57 , Pierre Habouzit  wrote:
> 
>> On Dec 21, 2015, at 9:34 AM, Jordan Rose via swift-corelibs-dev 
>>  wrote:
>> 
>> Hm. If this is the right setting to set on everybody's system, we could add 
>> it as part of Clang initialization (for the Clang inside Swift). Otherwise, 
>> you can use "-Xcc" to pass extra flags to Clang, in this case "-Xcc 
>> -D_GNU_SOURCE=1”.
> 
> You definitely want -D_GNU_SOURCE=1 on linux systems, as all the non portable 
> calls (that also are the interesting ones) will be hidden behind this.

Seems reasonable. If anyone wants to fix this, the relevant function is 
getNormalInvocationArguments 
<https://github.com/apple/swift/blob/master/lib/ClangImporter/ClangImporter.cpp#L265>
 in ClangImporter.cpp; otherwise, please file a bug report at 
https://bugs.swift.org <https://bugs.swift.org/>.

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

Re: [swift-corelibs-dev] NSCoding methods

[Jordan Rose via swift-corelibs-dev]

No, we cannot encode things "non-mangled but with the namespace". For any type 
other than top-level non-generic class types, using a non-mangled name is not 
unique. The only correct answer for arbitrary classes is to use mangled names, 
or something that maps one-to-one with mangled names.

Now, Foundation classes are not arbitrary classes, but then I don't see why 
we'd need to use mangled names for those. We can just use the plain old 
Objective-C names that the OS X classes use today.

Jordan

> On Dec 22, 2015, at 10:16, Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> To clarify the goals: I think it is reasonable for us to have a goal to be 
> able to encode/decode archives from foreign targets; e.g. linux encodes an 
> archive and mac os x decodes or iOS encodes and linux decodes. This will 
> allow for server architecture to transmit binary archives across the wire. 
> This will mean that we will want to have the encoded class names from the 
> application scope to be encoded as the non mangled name but with the 
> namespace. However this presents a problem; Foundation will have a namespace 
> which will need to be inferred both for encoding and decoding. Thankfully 
> there may be a reasonable way to approach this;
> 
> public class func classNameForClass(cls: AnyClass) -> String?
> public class func setClassName(codedName: String?, forClass cls: AnyClass)
> 
> These methods can be used to allow for translation of classes by registering 
> the appropriate classes for a “shortened” name that drops the 
> Foundation/SwiftFoundation namespace prefix during encoding.
> 
>> On Dec 22, 2015, at 2:45 AM, Luke Howard via swift-corelibs-dev 
>>  wrote:
>> 
>> 
>>> On 22 Dec 2015, at 5:50 AM, Jordan Rose  wrote:
>>> 
>>> IMHO on Linux NSKeyedArchiver should always use mangled names. If we want 
>>> cross-platform archives, we should set up standard substitutions, but given 
>>> that Swift classes exposed to Objective-C are archived with their full 
>>> names it doesn't make sense to use "half the name" in the archive.
>> 
>> You mean namespaced but unmangled yes? If so I agree.
>> 
>> BTW I found a couple of small CF nits:
>> 
>> * in CFDictionaryGetKeysAndValues(), keybuf and valuebuf are transposed in 
>> the call to CF_SWIFT_FUNCDISPATCHV(NSDictionary.getObjects())
>> 
>> * _CFSwiftDictionaryGetKeysAndValues() does not handle keybuf or valbuf 
>> being NULL (either of which are valid when calling 
>> CFDictionaryGetKeysAndValues())
>> 
> 
> This is a bit un-related to NSCoding and the transposition is probably a 
> mistake if it is inverted (the CF method should be reversed from the NS 
> method to mimic the objc counterpart)
> 
>> — Luke
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSCoding methods

[Jordan Rose via swift-corelibs-dev]

Here's another example on OS X:

import Foundation

class Outer {
class Inner : NSObject, NSCoding {
let uuid: Foundation.NSUUID
required init?(coder aDecoder: NSCoder) {
uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
}
override init() {
uuid = Foundation.NSUUID()
}
func encodeWithCoder(aCoder: NSCoder) {
aCoder.encodeObject(uuid, forKey: "my.uuid")
}
}
}

NSKeyedArchiver.archiveRootObject(Outer.Inner(), toFile: 
"/Users/jrose/Desktop/test-archive")


Which results in this archive:

{
  "$version" => 10
  "$objects" => [
0 => "$null"
1 => {
  "my.uuid" => {value = 
2}
  "$class" => {value = 
4}
}
2 => {
  "NS.uuidbytes" => <67f0b08b c8274f8c b0c78d90 bd4627dc>
  "$class" => {value = 
3}
}
3 => {
  "$classname" => "NSUUID"
  "$classes" => [
0 => "NSUUID"
1 => "NSObject"
  ]
}
4 => {
  "$classname" => "_TtCC4main5Outer5Inner"
  "$classes" => [
0 => "_TtCC4main5Outer5Inner"
1 => "NSObject"
  ]
}
  ]
  "$archiver" => "NSKeyedArchiver"
  "$top" => {
"root" => {value = 1}
  }
}

NSStringFromClass makes pretty names when they fall into the "simple" category, 
but that's not an arbitrarily extensible transformation, and NSCoding shouldn't 
have to know anything about it.

Jordan

> On Dec 23, 2015, at 14:48, Philippe Hausler  wrote:
> 
> The archiving format encodes the names of the classes in the archive itself. 
> Here are a few code examples and a quasi readable output from them:
> 
> let uuid = NSUUID()
> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
> options: [], format: nil)
> print(archive)
> 
> prints the following:
> 
> {
> "$archiver" = NSKeyedArchiver;
> "$objects" = (
> "$null",
> {
> "$class" = " [0x7fff7ab33bb0]>{value = 2}";
> "NS.uuidbytes" = <797639fe dad74b14 902afab3 c490448b>;
> },
> {
> "$classes" = (
> NSUUID,
> NSObject
> );
> "$classname" = NSUUID;
> }
> );
> "$top" = {
> root = "{value = 1}";
> };
> "$version" = 10;
> }
> 
> Note the $classes and $classname objects; which are what tell the internal 
> implementation of NSKeyedUnarchiver what to construct; moreover you can 
> create your own classes..
> 
> // I don’t really think this is a good naming for an application’s class but 
> hey it might happen...
> class NSUUID : NSObject, NSCoding {
> let uuid: Foundation.NSUUID
> required init?(coder aDecoder: NSCoder) {
> uuid = aDecoder.decodeObjectForKey("my.uuid") as! Foundation.NSUUID
> }
> override init() {
> uuid = Foundation.NSUUID()
> }
> func encodeWithCoder(aCoder: NSCoder) {
> aCoder.encodeObject(uuid, forKey: "my.uuid")
> }
> }
> 
> let uuid = NSUUID()
> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
> options: [], format: nil)
> print(archive)
> 
> prints the following:
> 
> {
> "$archiver" = NSKeyedArchiver;
> "$objects" = (
> "$null",
> {
> "$class" = " [0x7fff7ab33bb0]>{value = 4}";
> "my.uuid" = " [0x7fff7ab33bb0]>{value = 2}";
> },
> {
> "$class" = " [0x7fff7ab33bb0]>{value = 3}";
> "NS.uuidbytes" = <546e5b5e 15c244a1 aa96eb90 30c3f7f6>;
> },
> {
> "$classes" = (
> NSUUID,
> NSObject
> );
> "$classname" = NSUUID;
> },
> {
> "$classes" = (
> "Archiver.NSUUID",
> NSObject
> );
> "$classname" = "Archiver.NSUUID";
> }
> );
> "$top" = {
> root = "{value = 1}";
> };
> "$version" = 10;
> }
> 
> Granted this is a questionable name for a class but it illustrates which 
> class names are encoded where and how they should be interpreted in the 
> pre-existing archive format; which we will have to figure out some sensible 
> way of inflating and deflating to/from disk/network etc.
> 
>> On Dec 23, 2015, at 2:37 PM, Jordan Rose > > wrote:
>> 
>> No, we cannot encode things "non-mangled but with the namespace". For any 
>> type other than top-level non-generic class types, using a non-mangled name 
>> is not unique. The only correct answer for arbitrary classes is to use 
>> mangled names, or something that maps one-to-one with mangled names.
>> 
>> Now, Foundation classes are not arbitrary classes, but then I don't see why 
>> we'd need to use mang

Re: [swift-corelibs-dev] NSCoding methods

[Jordan Rose via swift-corelibs-dev]

"We need to get ahold of a class given a name" is definitely a requirement to 
do NSCoding right. I'm not at all convinced dlsym is a valid long-term answer 
for that, though. If you have an 'internal' class, it doesn't (currently) have 
a public symbol that you can use dlsym for.

This sort of goes with the existing problem of static registration: there's no 
pure Swift way to get all subclasses of a class, or to get a class from a name 
for any other reason. That's a general language problem, though, and we should 
discuss it on swift-dev.

Jordan


> On Dec 23, 2015, at 15:12, Philippe Hausler  wrote:
> 
> NSCoding will have to use something to transform from strings to classes, and 
> that satisfy the two cases (or more) that we have already shown, currently 
> there is no thing that does that in either form; either mangled or non 
> mangled. Basically we need something to implement NSClassFromString with. 
> Which we have clearly shown that dlsym does not fully meet the needs since 
> there are cases that will emit as “module.classname” and others that emit as 
> the mangled name. The simple case is probably going to be the a very common 
> usage pattern for consumers (and of previously built applications). The inner 
> class should definitely be handled in addition to this case.
> 
> Are there any methods that can fetch the name (either the symbolic or the 
> readable) given a AnyClass in the runtime to get work started here? I think 
> it is definitely sensible as a start to restrict this just to descendants of 
> the class NSObject. I would presume that since the Metadata is potentially 
> volatile contents we should use something along the lines of 
> swift_getTypeName etc?
> 
>> On Dec 23, 2015, at 2:53 PM, Jordan Rose > > wrote:
>> 
>> Here's another example on OS X:
>> 
>> import Foundation
>> 
>> class Outer {
>> class Inner : NSObject, NSCoding {
>> let uuid: Foundation.NSUUID
>> required init?(coder aDecoder: NSCoder) {
>> uuid = aDecoder.decodeObjectForKey("my.uuid") as! 
>> Foundation.NSUUID
>> }
>> override init() {
>> uuid = Foundation.NSUUID()
>> }
>> func encodeWithCoder(aCoder: NSCoder) {
>> aCoder.encodeObject(uuid, forKey: "my.uuid")
>> }
>> }
>> }
>> 
>> NSKeyedArchiver.archiveRootObject(Outer.Inner(), toFile: 
>> "/Users/jrose/Desktop/test-archive")
>> 
>> 
>> Which results in this archive:
>> 
>> {
>>   "$version" => 10
>>   "$objects" => [
>> 0 => "$null"
>> 1 => {
>>   "my.uuid" => > [0x7fff7c5acd80]>{value = 2}
>>   "$class" => {value 
>> = 4}
>> }
>> 2 => {
>>   "NS.uuidbytes" => <67f0b08b c8274f8c b0c78d90 bd4627dc>
>>   "$class" => {value 
>> = 3}
>> }
>> 3 => {
>>   "$classname" => "NSUUID"
>>   "$classes" => [
>> 0 => "NSUUID"
>> 1 => "NSObject"
>>   ]
>> }
>> 4 => {
>>   "$classname" => "_TtCC4main5Outer5Inner"
>>   "$classes" => [
>> 0 => "_TtCC4main5Outer5Inner"
>> 1 => "NSObject"
>>   ]
>> }
>>   ]
>>   "$archiver" => "NSKeyedArchiver"
>>   "$top" => {
>> "root" => {value = 1}
>>   }
>> }
>> 
>> NSStringFromClass makes pretty names when they fall into the "simple" 
>> category, but that's not an arbitrarily extensible transformation, and 
>> NSCoding shouldn't have to know anything about it.
>> 
>> Jordan
>> 
>>> On Dec 23, 2015, at 14:48, Philippe Hausler >> > wrote:
>>> 
>>> The archiving format encodes the names of the classes in the archive 
>>> itself. Here are a few code examples and a quasi readable output from them:
>>> 
>>> let uuid = NSUUID()
>>> let data = NSKeyedArchiver.archivedDataWithRootObject(uuid)
>>> let archive = try! NSPropertyListSerialization.propertyListWithData(data, 
>>> options: [], format: nil)
>>> print(archive)
>>> 
>>> prints the following:
>>> 
>>> {
>>> "$archiver" = NSKeyedArchiver;
>>> "$objects" = (
>>> "$null",
>>> {
>>> "$class" = ">> [0x7fff7ab33bb0]>{value = 2}";
>>> "NS.uuidbytes" = <797639fe dad74b14 902afab3 c490448b>;
>>> },
>>> {
>>> "$classes" = (
>>> NSUUID,
>>> NSObject
>>> );
>>> "$classname" = NSUUID;
>>> }
>>> );
>>> "$top" = {
>>> root = "{value = 
>>> 1}";
>>> };
>>> "$version" = 10;
>>> }
>>> 
>>> Note the $classes and $classname objects; which are what tell the internal 
>>> implementation of NSKeyedUnarchiver what to construct; moreover you can 
>>> create your own classes..
>>> 
>>> // I don’t really think this is a good naming for an application’s class 
>>> but hey it might happen...
>>> class NSUUID : NSObject, NSCoding {
>>> let uuid: Foundation.NSUUID
>>> required init?(coder aDecoder: NSCoder) {
>>> uuid = aDecoder.decodeO

Re: [swift-corelibs-dev] [swift-users] build libdispatch failed in ubuntu 14.04

[Jordan Rose via swift-corelibs-dev]

(adding swift-corelibs-dev for additional eyes)

> On Mar 29, 2016, at 7:25 , qibo via swift-users  wrote:
> 
> Hi, everyone
> I follow the command written in INSTALL in 
> https://github.com/apple/swift-corelibs-libdispatch/blob/master/INSTALL 
> 
> 
> 
>   sh autogen.sh
>   ./configure
>   make
> but "make" failed, report is "No rule to make target `all'.  "
> Is there some optional command I missed?
> 
> Best Regards
> 
> ___
> swift-users mailing list
> swift-us...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Foundation and explicit pointer nullability

[Jordan Rose via swift-corelibs-dev]

Hey, Philippe, everyone. I've been working on implementing SE-0055: Making 
pointer nullability explicit 
,
 and it's been going well…but only now am I realizing how much it's going to 
affect Foundation, and possibly CF as well. While the nullability of APIs can 
usually be brought over from the Foundation headers, there are a lot of places 
where SwiftFoundation isn't clear about its nullability requirements within its 
implementation. For example, NSData appears to allow replacing a range of bytes 
with a {NULL, 0} buffer, but the implementation currently calls directly 
through to _CFDataReplaceBytes, which does not accept null pointers. (And if it 
were annotated to, it would then try to memmove from it, which is illegal.) The 
fix is trivial—just check for the null pointer case (or zero length case) and 
use an alternate API instead—but there might be quite a few of them.

I'm planning to run through all of Foundation (and XCTest) and get their tests 
passing using my branch of Swift , 
then submit a pull request for review, to be landed in sync with the Swift 
change. Does that sound like the best plan to you?

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

[swift-corelibs-dev] Foundation and explicit pointer nullability (CI edition)

[Jordan Rose via swift-corelibs-dev]

Hi, swift-corelibs-dev. I'm planning to land the changes for SE-0055: Making 
pointer nullability explicit 

 this afternoon in the Swift compiler; however, the corresponding diff for 
Foundation is fairly large (PR #304 
). Because of 
this, we've decided to hold off on migrating Foundation to the new model for 
UnsafePointer, so that it can be reviewed at leisure. This means that for a 
period of time, swift-corelibs-foundation will not build against the 'master' 
branch of the compiler. Instead, we're going to make a branch today that's 
passed all the CI checks, and use that for regression-testing (and building) 
Foundation for now.

Mishal, Jacob, or I will send a follow-up email once the compiler branch has 
been created, and another once CI has been updated.

Jordan


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

Re: [swift-corelibs-dev] Foundation and explicit pointer nullability (CI edition)

[Jordan Rose via swift-corelibs-dev]

Update: we've created the master-before-optional-pointers branch at ff373e9, 
but run into some complications putting this plan into action. (Specifically, I 
forgot that SwiftPM depends on XCTest for its test cases, and that XCTest of 
course depends on Foundation.) I'll send another message tomorrow with any new 
developments.

Jordan


> On Apr 11, 2016, at 12:23 , Jordan Rose via swift-corelibs-dev 
>  wrote:
> 
> Hi, swift-corelibs-dev. I'm planning to land the changes for SE-0055: Making 
> pointer nullability explicit 
> <https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md>
>  this afternoon in the Swift compiler; however, the corresponding diff for 
> Foundation is fairly large (PR #304 
> <https://github.com/apple/swift-corelibs-foundation/pull/304>). Because of 
> this, we've decided to hold off on migrating Foundation to the new model for 
> UnsafePointer, so that it can be reviewed at leisure. This means that for a 
> period of time, swift-corelibs-foundation will not build against the 'master' 
> branch of the compiler. Instead, we're going to make a branch today that's 
> passed all the CI checks, and use that for regression-testing (and building) 
> Foundation for now.
> 
> Mishal, Jacob, or I will send a follow-up email once the compiler branch has 
> been created, and another once CI has been updated.
> 
> Jordan
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-corelibs-dev] Foundation and explicit pointer nullability (CI edition)

[Jordan Rose via swift-corelibs-dev]

Final update: we decided it was cleaner to just update Foundation now rather 
than building with a separate branch and having to work out those dependencies, 
so essentially nothing will change. The pull request has been landed but is 
still planned to have a full post-commit review at a later date.

Apologies for all the confusion!
Jordan


> On Apr 11, 2016, at 20:56 , Jordan Rose via swift-corelibs-dev 
>  wrote:
> 
> Update: we've created the master-before-optional-pointers branch at ff373e9, 
> but run into some complications putting this plan into action. (Specifically, 
> I forgot that SwiftPM depends on XCTest for its test cases, and that XCTest 
> of course depends on Foundation.) I'll send another message tomorrow with any 
> new developments.
> 
> Jordan
> 
> 
>> On Apr 11, 2016, at 12:23 , Jordan Rose via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi, swift-corelibs-dev. I'm planning to land the changes for SE-0055: Making 
>> pointer nullability explicit 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md>
>>  this afternoon in the Swift compiler; however, the corresponding diff for 
>> Foundation is fairly large (PR #304 
>> <https://github.com/apple/swift-corelibs-foundation/pull/304>). Because of 
>> this, we've decided to hold off on migrating Foundation to the new model for 
>> UnsafePointer, so that it can be reviewed at leisure. This means that for a 
>> period of time, swift-corelibs-foundation will not build against the 
>> 'master' branch of the compiler. Instead, we're going to make a branch today 
>> that's passed all the CI checks, and use that for regression-testing (and 
>> building) Foundation for now.
>> 
>> Mishal, Jacob, or I will send a follow-up email once the compiler branch has 
>> been created, and another once CI has been updated.
>> 
>> Jordan
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

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

[Jordan Rose via swift-corelibs-dev]

[+swift-corelibs-dev] I don't think Foundation even tries to do incremental 
builds. I wonder if XCTest.so needs to be marked as a dependency somewhere in 
the higher-level build system.

Jordan

> On May 12, 2016, at 15:52, Brian Croom  wrote:
> 
> I'm not sure where the resiliency work stands, but I wonder if we've caught 
> incremental-compilation issue here? I added a field to XCTestCase, 
> TestFoundation which links to XCTest.so wasn't recompiled at all, and 
> proceeded to crash upon launch. 
> 
> torsdag 12 maj 2016 skrev mailto:no-re...@swift.org>>:
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5000]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5000/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 12 May 2016 14:45:34 -0700
> Build duration:   15 min
> Tests:
> 
> Name: Swift
> Failed: 0 test(s), Passed: 7902 test(s), Total: 7902 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 300 test(s), Total: 300 test(s)
> 
> Changes
> 
> Commit 5043bb6516a1f7396b27fd4b3417da9bd85a70e4 by jordan_rose:
> build-script: Make it easier to one-off modify a preset invocation.
> 
> edit: utils/build-script
> 
> Commit 41894742b0a9394960dd3f0dbb9b05ce1953f6a7 by jordan_rose:
> Handle trailing closures when renaming argument labels.
> 
> edit: lib/Sema/MiscDiagnostics.cpp
> edit: test/ClangModules/attr-swift_name_renaming.swift
> edit: test/ClangModules/Inputs/custom-modules/SwiftName.h
> 
> Commit c4d357c9f49253c482e5cfa547b1230304e5d56a by brian.s.croom:
> Add XCTestCase Performance Measurement APIs, with the wall clock time
> 
> edit: XCTest.xcodeproj/project.pbxproj
> add: Sources/XCTest/WallClockTimeMetric.swift
> add: Sources/XCTest/XCTestCase+Performance.swift
> edit: Sources/XCTest/XCTestObservation.swift
> add: Sources/XCTest/PerformanceMeter.swift
> edit: Sources/XCTest/XCTestCase.swift
> edit: Sources/XCTest/PrintObserver.swift
> edit: Sources/XCTest/XCTestObservationCenter.swift
> add: Tests/Functional/Performance/Misuse/main.swift
> add: Tests/Functional/Performance/main.swift
> 
> Commit ed708425c18285e1464893f4a9294d916775a1d2 by brian.s.croom:
> Remove a stray comment
> 
> edit: Sources/XCTest/WallClockTimeMetric.swift
> 
> Commit 1bb2e9e60a35def4de5514d90eb8f07911202542 by brian.s.croom:
> Add doc comments to `PerformanceMeterDelegate`
> 
> edit: Sources/XCTest/PerformanceMeter.swift
> 

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

[swift-corelibs-dev] JIRA labels (no worries)

[Jordan Rose via swift-corelibs-dev]

Hey, Brian. Re: your comment about labels 
:

> By the way, I'm curious for your thoughts on the swift-3.0 label, which I 
> introduced in 
> https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160516/000662.html.
>  I've seen you "curate" labels in the past, so I hope I didn't step on your 
> toes by creating one. I tagged this task as "swift-3.0" because it's a 
> sub-task of SR-710 , which is also 
> marked "swift-3.0" – we want to be able to generate tests lists before 
> shipping corelibs-xctest.


I knocked the "swift-3.0” label off because this was the first time I’d seen it 
in a non-corelibs issue, and because I wasn’t sure we had committed to doing 
this particular subtask in Swift 3—or rather, I wasn’t sure the SourceKit team 
had committed to doing this in Swift 3. I feel weird having release labels 
assigned by people working in other parts of the project because it feels like 
forcing the SourceKit engineers to fix it. I know that (a) wasn’t your 
intention, and (b) is probably accurate—as in, if this alternate solution 
hadn’t come up someone would have had to do something—but I reacted to it 
anyway and removed the label.

I do think now it was a bit of a knee-jerk reaction, so I apologize. As you 
noted, I’ve generally been the one adding labels, and removing or standardizing 
some of the ad hoc ones input by issue reporters; in this particular case that 
led to an instinct to remove a label I hadn’t seen rather than thinking about 
it. Certainly active contributors should be able to introduce new labels they 
find useful.

SR-1613 is resolved, so it’s kind of a moot point now, but do feel free to add 
useful labels in the future. If it matches one I’ve seen before I might 
standardize it, but I won’t remove them. Or if I do I’ll at least comment about 
it. :-)

Jordan

P.S. “swift-3.0” also doesn’t match my naming convention for labels, which is 
UpperCamelCase, but given that I didn’t write it down anywhere or tell anybody 
I can hardly complain!___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] JIRA workflow: "Resolved" -> "Verify"?

[Jordan Rose via swift-corelibs-dev]

Hi, swift-dev et al (but especially Ted). I’ve recently noticed that our JIRA 
workflow has been a bit confusing. We currently have five “statuses":

1. Opened: This bug has been filed.
2. In Progress: Someone is actively working on this bug. (Not everyone has been 
bothering to set this, but it seems reasonable to have.)
3. Resolved: A fix has been merged to master.
4. Closed: The fix has been verified by the reporter.
5. Reopened: The “fix" doesn’t actually fix the reporter’s problem.

The problem is that the “Resolved” and “Closed” statuses aren’t really 
distinguished on the site itself—it’s unclear for a contributor which one 
they’re supposed to use when they get something merged, and it’s unclear for 
the reporter what they’re supposed to say. Therefore, I suggest changing the 
“Resolved” status to “Verify” (like we use in Radar) and the “Resolve Issue” 
button to “Mark Resolved”.

(There are other things unspecified here, such as how to track what release a 
fix gets into, or what the story is for the Assignee field, but we can discuss 
those later.)

What do you think?
Thanks,
Jordan___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [swift-build-dev] JIRA workflow: "Resolved" -> "Verify"?

[Jordan Rose via swift-corelibs-dev]

It hasn’t been used so much so far, but on the bugs where it has I like being 
able to tell the difference. I don’t think we’d poke people about verification 
like we do with Radar, though, so we will (and have) end up with a lot of bugs 
left in Resolved/Verify.

Jordan


> On Aug 15, 2016, at 10:10, Daniel Dunbar  wrote:
> 
> Do we anticipate Verify being used in practice much? 
> 
> Would it be better to simplify the workflow and just have a single 
> "Resolved/Closed/Done" state? If the originator does test the bug and find it 
> isn't fixed, they can reopen.
> 
> My guess is not that many people are going to actively look at their JIRA 
> account to find bugs that they are supposed to be verifying.
> 
>  - Daniel
> 
>> On Aug 15, 2016, at 10:08 AM, Jordan Rose via swift-build-dev 
>> mailto:swift-build-...@swift.org>> wrote:
>> 
>> Hi, swift-dev et al (but especially Ted). I’ve recently noticed that our 
>> JIRA workflow has been a bit confusing. We currently have five “statuses":
>> 
>> 1. Opened: This bug has been filed.
>> 2. In Progress: Someone is actively working on this bug. (Not everyone has 
>> been bothering to set this, but it seems reasonable to have.)
>> 3. Resolved: A fix has been merged to master.
>> 4. Closed: The fix has been verified by the reporter.
>> 5. Reopened: The “fix" doesn’t actually fix the reporter’s problem.
>> 
>> The problem is that the “Resolved” and “Closed” statuses aren’t really 
>> distinguished on the site itself—it’s unclear for a contributor which one 
>> they’re supposed to use when they get something merged, and it’s unclear for 
>> the reporter what they’re supposed to say. Therefore, I suggest changing the 
>> “Resolved” status to “Verify” (like we use in Radar) and the “Resolve Issue” 
>> button to “Mark Resolved”.
>> 
>> (There are other things unspecified here, such as how to track what release 
>> a fix gets into, or what the story is for the Assignee field, but we can 
>> discuss those later.)
>> 
>> What do you think?
>> Thanks,
>> Jordan
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
> 

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

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

[Jordan Rose via swift-corelibs-dev]

Not it. Dispatch folks, any idea what's up?

> On Aug 24, 2016, at 16:04, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-libdispatch-linux-ubuntu-14_04 [#183]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-libdispatch-linux-ubuntu-14_04/183/
>  
> 
> Project:  oss-swift-incremental-RA-libdispatch-linux-ubuntu-14_04
> Date of build:Wed, 24 Aug 2016 15:36:44 -0700
> Build duration:   28 min
> 
> Changes
> 
> Commit 9fab7cb15f5584ce49b49f73e0e8ac277d7c2192 by jordan_rose:
> Fix s390x Enum load/storeMultiPayloadValue (#4461)
> 
> edit: stdlib/public/runtime/Enum.cpp

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

[swift-corelibs-dev] Fwd: [swift-users] [swift-dev] New Swift Snapshots Available!

[Jordan Rose via swift-corelibs-dev]

> Begin forwarded message:
> 
> From: Michael Ferenduros via swift-users 
> Subject: Re: [swift-users] [swift-dev] New Swift Snapshots Available!
> Date: August 26, 2016 at 08:00:55 PDT
> To: swift-us...@swift.org
> Reply-To: Michael Ferenduros 
> 
> 
>> On 24 Aug 2016, at 12:38, Chris Bailey via swift-users 
>> mailto:swift-us...@swift.org>> wrote:
>> 
>> If you haven't spotted it, the new snapshots include Dispatch on Linux for 
>> the first time - please test it out as there may well be number of issues to 
>> shake out, especially with the new Swift 3 API. 
> 
> I’m seeing weird behaviour with DispatchSources + sockets on Linux right now 
> - whereas on Mac both read and write sources fire correctly, on the latest 
> Linux snapshot only the read event is firing.
> 
> Eg: https://github.com/mike-ferenduros/SwiftySocketsDispatchIssue 
> 
> 
>> 
>> The availability is thanks to the hard work of a large number of people, 
>> including Dave Grove, Hubertus Franke, Pierre Habouzit, Daniel Steffan, Matt 
>> Wright, Tony Parker, Philippe Hausler and Mishal Shah. 
>> 
>> Chris
> 
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

[swift-corelibs-dev] Mailing list flakiness

[Jordan Rose via swift-corelibs-dev]

Hey, all. You might have noticed messages being dropped or taking a long time 
to get through on the swift.org mailing lists. The story is that the 
configuration for our outbound mail server changed on Tuesday, but we didn't 
get around to updating it until Wednesday. We think the system is just catching 
up at this point and should be back to normal by the end of the week, but we'll 
continue to investigate.

(Preemptive "this is why swift-evolution should use a forum site instead of 
mailing lists". There, now you don't have to say it.)

Sorry for the trouble,
Jordan
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Flaky NSOperationQueue test

[Jordan Rose via swift-corelibs-dev]

Anyone know what’s up with this one? We get it every few builds or so.

17:15:39 
TestFoundation/TestNSOperationQueue.swift:63: error: 
TestNSOperationQueue.test_OperationPriorities : XCTAssertEqual failed: 
("Operation1 executed") is not equal to ("Operation3 executed") - 
17:15:39 TestFoundation/TestNSOperationQueue.swift:64: error: 
TestNSOperationQueue.test_OperationPriorities : XCTAssertEqual failed: 
("Operation3 executed") is not equal to ("Operation1 executed") - 

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

Re: [swift-corelibs-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 - Long Test (swift 3.0) #302

[Jordan Rose via swift-corelibs-dev]

> Foundation/NSData.swift:19:8: error: module file was created by an older 
> version of the compiler; rebuild 'Dispatch' and try again: 
> /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule
> 
> import Dispatch
>^

I thought we fixed this—we need to build Swift, then libdispatch, then the 
Dispatch overlay, then Foundation. Has no one set that up yet?


> On Sep 23, 2016, at 0:51, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test [#302]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test/302/
>  
> 
> Project:  oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-long-test
> Date of build:Fri, 23 Sep 2016 00:42:00 -0700
> Build duration:   9 min 45 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: 8245 test(s), Total: 8245 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit d8a375727247d3c9e3295a9af1fec079485c5310 by jordan_rose:
> Merge pull request #4682 from jrose-apple/generic-param-fix-it
> 
> edit: test/Constraints/construction.swift
> edit: test/Constraints/generics.swift
> edit: include/swift/AST/DiagnosticsSema.def
> edit: lib/FrontendTool/FrontendTool.cpp
> edit: lib/Sema/TypeChecker.h
> edit: lib/Sema/MiscDiagnostics.cpp
> edit: lib/Sema/TypeCheckType.cpp
> edit: test/Constraints/bridging.swift
> edit: test/Constraints/incomplete_function_ref.swift
> edit: test/FixCode/fixits-apply.swift
> edit: test/decl/typealias/generic.swift
> edit: test/FixCode/fixits-apply.swift.result
> edit: lib/Sema/CSDiag.cpp
> 
> Commit 509ee4c7c8113e5865a22ffb9053b0236d7160ec by jordan_rose:
> Don't use construction to convert literals in rawValue fix-it. (#4934)
> 
> edit: test/FixCode/fixits-apply.swift.result
> edit: lib/Sema/CSDiag.cpp
> edit: test/FixCode/fixits-apply.swift

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

Re: [swift-corelibs-dev] [swift-dev] Swift CI PR builder dispatch linux failure

[Jordan Rose via swift-corelibs-dev]

I think the right order to build things is:

1. libdispatch (C)
2. Swift (compiler + stdlib + Dispatch overlay)
3. Foundation

Otherwise we need to build Swift, then build libdispatch, then go back to 
"Swift" to build the overlay, and only finally get to Foundation.

Jordan


> On Sep 23, 2016, at 14:32, David P Grove via swift-dev  
> wrote:
> 
> I'm playing with something. Should have a PR ready shortly.
> 
> --dave
> 
> 
> "Daniel A. Steffen via swift-dev" ---09/23/2016 04:45:06 PM---I 
> don’t know how these dependencies are expressed in CMake but it doesn’t seem 
> very difficult to do
> 
> From: "Daniel A. Steffen via swift-dev" 
> To: Ted Kremenek 
> Cc: swift-dev 
> Date: 09/23/2016 04:45 PM
> Subject: Re: [swift-dev] Swift CI PR builder dispatch linux failure
> Sent by: swift-dev-boun...@swift.org
> 
> 
> 
> 
> I don’t know how these dependencies are expressed in CMake but it doesn’t 
> seem very difficult to do so in the autotools buildsystem, we have
> 
> AC_ARG_WITH([swift-toolchain],
> [AS_HELP_STRING([--with-swift-toolchain], [Specify path to Swift toolchain])],
> [swift_toolchain_path=${withval}
> AC_DEFINE(HAVE_SWIFT, 1, [Define if building for Swift])
> SWIFTC="$swift_toolchain_path/bin/swiftc”
> 
> in configure.ac which ends up as a SWIFTC makefile variable, so as long as 
> that argument is passed as an absolute path, it should work as a dependency 
> in the build rules
> 
> $(abs_builddir)/swift/%.o: $(abs_srcdir)/swift/%.swift
> $(SWIFTC) -frontend -c $(SWIFT_ABS_SRC_FILES) -primary-file $< \
> 
> Is there a JIRA ticket for this ? the IBM folks should probably be the ones 
> making these changes since we still don’t have the whitelist in place for 
> Apple contributors to do so…
> 
> Daniel
> 
> On Sep 23, 2016, at 13:00, Ted Kremenek  > wrote:
> 
> + Daniel
> 
> Daniel: how hard would it be for the Dispatch project to be modified to add 
> the swiftc binary used to build the project as a dependency?
> On Sep 23, 2016, at 12:55 PM, Ted Kremenek via swift-dev  > wrote:
> 
> Dispatch is a separate project. There isn’t a dependency in the Dispatch 
> project to tell it is building with a new compiler. The project would need to 
> be modified to add a dependency on the swiftc binary being used to compile 
> this project.
> On Sep 21, 2016, at 9:39 AM, Mishal Shah via swift-dev  > wrote:
> 
> We should look into why it's not rebuilding dependencies. Do we need to fix 
> CMake logic? Can you please file a bug?
> 
> 
> Thanks,
> Mishal Shah
> 
> On Sep 21, 2016, at 9:28 AM, Michael Gottesman  > wrote:
> +CC Mishal
> On Sep 21, 2016, at 6:59 AM, David P Grove via swift-dev  > wrote:
> I don't know how the PR jobs are setup, but the error suggests that they are 
> trying to reuse too much of the workspace of previous runs.
> 
> :0: error: module file was created by an older version of the 
> compiler; rebuild 'Dispatch' and try again: 
> /home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/Dispatch.o.~partial.swiftmodule
> 
> --dave
> 
> 
> Ankit Aggarwal via swift-dev ---09/21/2016 03:08:58 AM---This 
> has been consistently failing on PRs, can someone look into this: 
> :0: error: module fi
> 
> From: Ankit Aggarwal via swift-dev  >
> To: swift-dev mailto:swift-...@swift.org>>
> Date: 09/21/2016 03:08 AM
> Subject: [swift-dev] Swift CI PR builder dispatch linux failure
> Sent by: swift-dev-boun...@swift.org 
> 
> 
> 
> 
> This has been consistently failing on PRs, can someone look into this:
> 
> :0: error: module file was created by an older version of the 
> compiler; rebuild 'Dispatch' and try again: 
> /home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/Dispatch.o.~partial.swiftmodule
> make[2]: *** 
> [/home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule]
>  Error 1
> make[2]: Leaving directory 
> `/home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/libdispatch-linux-x86_64/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory 
> `/home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/libdispatch-linux-x86_64/src'
> make: *** [all-recursive] Error 1
> /home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 2, aborting
> /home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 1, aborting
> 
> 
> https://ci.swift.org/job/swift-package-manager-PR-Linux/497/console 
> 

Re: [swift-corelibs-dev] [swift-dev] Swift CI PR builder dispatch linux failure

[Jordan Rose via swift-corelibs-dev]

Oh, I didn’t realize we had a separate copy of the overlay code (almost 
certainly the right thing to do at this point). But in that case, why are we 
seeing any of these errors?

Jordan

> On Sep 25, 2016, at 11:38, David P Grove  wrote:
> 
> The order may need to vary by platform. On Linux, the DIspatch Swift overlay 
> code lives in swift-corelibs-libdispatch/src/swift. So it works to build (1) 
> Swift (2) libdispatch (both C and Swift) (3) Foundation. 
> 
> --dave
> 
> Jordan Rose ---09/23/2016 06:34:46 PM---I think the right order 
> to build things is: 1. libdispatch (C)
> 
> From: Jordan Rose 
> To: David P Grove/Watson/IBM@IBMUS
> Cc: "Daniel A. Steffen" , swift-dev 
> , swift-corelibs-dev 
> Date: 09/23/2016 06:34 PM
> Subject: Re: [swift-dev] Swift CI PR builder dispatch linux failure
> Sent by: jordan_r...@apple.com
> 
> 
> 
> 
> I think the right order to build things is:
> 
> 1. libdispatch (C)
> 2. Swift (compiler + stdlib + Dispatch overlay)
> 3. Foundation
> 
> Otherwise we need to build Swift, then build libdispatch, then go back to 
> "Swift" to build the overlay, and only finally get to Foundation.
> 
> Jordan
> 
> On Sep 23, 2016, at 14:32, David P Grove via swift-dev  > wrote:
> I'm playing with something. Should have a PR ready shortly.
> 
> --dave
> 
> 
> "Daniel A. Steffen via swift-dev" ---09/23/2016 04:45:06 PM---I 
> don’t know how these dependencies are expressed in CMake but it doesn’t seem 
> very difficult to do
> 
> From: "Daniel A. Steffen via swift-dev"  >
> To: Ted Kremenek mailto:kreme...@apple.com>>
> Cc: swift-dev mailto:swift-...@swift.org>>
> Date: 09/23/2016 04:45 PM
> Subject: Re: [swift-dev] Swift CI PR builder dispatch linux failure
> Sent by: swift-dev-boun...@swift.org 
> 
> 
> 
> 
> I don’t know how these dependencies are expressed in CMake but it doesn’t 
> seem very difficult to do so in the autotools buildsystem, we have
> 
> AC_ARG_WITH([swift-toolchain],
> [AS_HELP_STRING([--with-swift-toolchain], [Specify path to Swift toolchain])],
> [swift_toolchain_path=${withval}
> AC_DEFINE(HAVE_SWIFT, 1, [Define if building for Swift])
> SWIFTC="$swift_toolchain_path/bin/swiftc”
> 
> in configure.ac which ends up as a SWIFTC makefile variable, so as long as 
> that argument is passed as an absolute path, it should work as a dependency 
> in the build rules
> 
> $(abs_builddir)/swift/%.o: $(abs_srcdir)/swift/%.swift
> $(SWIFTC) -frontend -c $(SWIFT_ABS_SRC_FILES) -primary-file $< \
> 
> Is there a JIRA ticket for this ? the IBM folks should probably be the ones 
> making these changes since we still don’t have the whitelist in place for 
> Apple contributors to do so…
> 
> Daniel
> On Sep 23, 2016, at 13:00, Ted Kremenek  > wrote:
> 
> + Daniel
> 
> Daniel: how hard would it be for the Dispatch project to be modified to add 
> the swiftc binary used to build the project as a dependency?
> On Sep 23, 2016, at 12:55 PM, Ted Kremenek via swift-dev  > wrote:
> 
> Dispatch is a separate project. There isn’t a dependency in the Dispatch 
> project to tell it is building with a new compiler. The project would need to 
> be modified to add a dependency on the swiftc binary being used to compile 
> this project.
> On Sep 21, 2016, at 9:39 AM, Mishal Shah via swift-dev  > wrote:
> 
> We should look into why it's not rebuilding dependencies. Do we need to fix 
> CMake logic? Can you please file a bug?
> 
> 
> Thanks,
> Mishal Shah
> 
> On Sep 21, 2016, at 9:28 AM, Michael Gottesman  > wrote:
> +CC Mishal
> On Sep 21, 2016, at 6:59 AM, David P Grove via swift-dev  > wrote:
> I don't know how the PR jobs are setup, but the error suggests that they are 
> trying to reuse too much of the workspace of previous runs.
> 
> :0: error: module file was created by an older version of the 
> compiler; rebuild 'Dispatch' and try again: 
> /home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/Dispatch.o.~partial.swiftmodule
> 
> --dave
> 
> 
> Ankit Aggarwal via swift-dev ---09/21/2016 03:08:58 AM---This 
> has been consistently failing on PRs, can someone look into this: 
> :0: error: module fi
> 
> From: Ankit Aggarwal via swift-dev  >
> To: swift-dev mailto:swift-...@swift.org>>
> Date: 09/21/2016 03:08 AM
> Subject: [swift-dev] Swift CI PR builder dispatch linux failure
> Sent by:swift-dev-boun...@swift.org 
> 
> 
> 
> 
> This has been consistently failing on PRs, can someone look into this:
> 
> :0: error: module file was created by an older version of the 
> compiler; rebuild 'Dispatch' and try again: 
> /home/buildnode/jenkins/workspace/swift-package-manager-PR-Linux/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/Disp

Re: [swift-corelibs-dev] [swift-dev] Swift CI PR builder dispatch linux failure

[Jordan Rose via swift-corelibs-dev]

The problem with moving the Darwin Dispatch overlay there is that other 
overlays depend on Dispatch, and we’re not ready to move those out somewhere 
else. That would compound this cross-repo dependency problem.

Jordan


> On Sep 26, 2016, at 12:32, Daniel A. Steffen  wrote:
> 
> this may be an unintended consequence of us putting the Linux overlay into 
> the library repo (as opposed to the compiler repo).
> 
> I still think that is the right place for the overlay to live though, and 
> that we should move the Darwin overlay there as well medium term (and work 
> out any resulting build issues).
> 
> On both platforms we want to move towards a more integrated support for the 
> Swift 3 interfaces directly from the library instead of the large overlay we 
> have now.
> 
> Daniel
> 
>> On Sep 26, 2016, at 10:19, David P Grove via swift-dev > > wrote:
>> 
>> We think that the libdispatch incremental rebuilds didn't know that if 
>> swiftc changed it needed to invalidate the compilation of the swift dispatch 
>> overlay files (missing dependency in the make rule). A localized change that 
>> could be enough to fix the problem is libdispatch PR #178. If that isn't 
>> enough, we might have to do a more ambitious restructuring of the 
>> libdispatch build.
>> 
>> --dave
>> 
>> Jordan Rose ---09/26/2016 01:07:24 PM---Oh, I didn’t realize we 
>> had a separate copy of the overlay code (almost certainly the right thing to
>> 
>> From: Jordan Rose mailto:jordan_r...@apple.com>>
>> To: David P Grove/Watson/IBM@IBMUS
>> Cc: "Daniel A. Steffen" mailto:dstef...@apple.com>>, 
>> swift-dev mailto:swift-...@swift.org>>, 
>> swift-corelibs-dev > >
>> Date: 09/26/2016 01:07 PM
>> Subject: Re: [swift-dev] Swift CI PR builder dispatch linux failure
>> Sent by: jordan_r...@apple.com 
>> 
>> 
>> 
>> Oh, I didn’t realize we had a separate copy of the overlay code (almost 
>> certainly the right thing to do at this point). But in that case, why are we 
>> seeing any of these errors?
>> 
>> Jordan
>> On Sep 25, 2016, at 11:38, David P Grove > > wrote:
>> The order may need to vary by platform. On Linux, the DIspatch Swift overlay 
>> code lives in swift-corelibs-libdispatch/src/swift. So it works to build (1) 
>> Swift (2) libdispatch (both C and Swift) (3) Foundation. 
>> 
>> --dave
>> 
>> Jordan Rose ---09/23/2016 06:34:46 PM---I think the right order 
>> to build things is: 1. libdispatch (C)
>> 
>> From: Jordan Rose mailto:jordan_r...@apple.com>>
>> To: David P Grove/Watson/IBM@IBMUS
>> Cc: "Daniel A. Steffen" mailto:dstef...@apple.com>>, 
>> swift-dev mailto:swift-...@swift.org>>, 
>> swift-corelibs-dev > >
>> Date: 09/23/2016 06:34 PM
>> Subject: Re: [swift-dev] Swift CI PR builder dispatch linux failure
>> Sent by: jordan_r...@apple.com 
>> 
>> 
>> 
>> 
>> I think the right order to build things is:
>> 
>> 1. libdispatch (C)
>> 2. Swift (compiler + stdlib + Dispatch overlay)
>> 3. Foundation
>> 
>> Otherwise we need to build Swift, then build libdispatch, then go back to 
>> "Swift" to build the overlay, and only finally get to Foundation.
>> 
>> Jordan
>> On Sep 23, 2016, at 14:32, David P Grove via swift-dev > > wrote:
>> I'm playing with something. Should have a PR ready shortly.
>> 
>> --dave
>> 
>> 
>> "Daniel A. Steffen via swift-dev" ---09/23/2016 04:45:06 PM---I 
>> don’t know how these dependencies are expressed in CMake but it doesn’t seem 
>> very difficult to do
>> 
>> From: "Daniel A. Steffen via swift-dev" > >
>> To: Ted Kremenek mailto:kreme...@apple.com>>
>> Cc: swift-dev mailto:swift-...@swift.org>>
>> Date: 09/23/2016 04:45 PM
>> Subject: Re: [swift-dev] Swift CI PR builder dispatch linux failure
>> Sent by: swift-dev-boun...@swift.org 
>> 
>> 
>> 
>> 
>> I don’t know how these dependencies are expressed in CMake but it doesn’t 
>> seem very difficult to do so in the autotools buildsystem, we have
>> 
>> AC_ARG_WITH([swift-toolchain],
>> [AS_HELP_STRING([--with-swift-toolchain], [Specify path to Swift 
>> toolchain])],
>> [swift_toolchain_path=${withval}
>> AC_DEFINE(HAVE_SWIFT, 1, [Define if building for Swift])
>> SWIFTC="$swift_toolchain_path/bin/swiftc”
>> 
>> in configure.ac which ends up as a SWIFTC makefile variable, so as long as 
>> that argument is passed as an absolute path, it should work as a dependency 
>> in the build rules
>> 
>> $(abs_builddir)/swift/%.o: $(abs_srcdir)/swift/%.swift
>> $(SWIFTC) -frontend -c $(SWIFT_ABS_SRC_FILES) -primary-file $< \
>> 
>> Is there a JIRA ticket for this ? the IBM folks should probably be the ones 
>> making these changes since we still don’t have the whitelist in place for 
>> Apple contributors to do so…
>> 
>> Daniel
>> On Sep 23, 2016, at 13:00, Ted Kremenek > 

Re: [swift-corelibs-dev] [swift-dev] Swift Class Encoding Standard?

[Jordan Rose via swift-corelibs-dev]

This is somewhat intentional. While simple names can be encoded hierarchically 
like this, generics make everything more tricky. Consider a demangled name 
"Contacts.Person.Address.PostCode"—in this case not 
only is splitting on "." is no longer a reasonable thing to do, but there's not 
currently a way to get the type for 'Address' with a particular generic 
argument.

The Swift compiler and Foundation teams were a bit at odds here, trying to 
decide whether it would be appropriate to use Swift's current mangling scheme 
for encoded class names, or whether it would be better to pick something else. 
(This is what the Objective-C runtime currently does on Apple platforms, but 
that too could be changed, though we'd have to be careful about 
backward-compatibility.) IIRC at the time we decided it was best to implement 
the minimal thing that handles the common case—top-level non-generic types—and 
worry about the more complicated things later.

Jordan



> On Oct 27, 2016, at 6:54, swizzlr via swift-dev  wrote:
> 
> Swift Foundation has an incomplete implementation of 
> NSClassFromString/NSStringFromClass (link: 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObjCRuntime.swift#L230-L282
>  
> )
>  due to a lack of a standardised method of encoding nested Swift classes, nor 
> other Swift types.
> 
> I would think that given
> 
> module Contacts
> 
> class Person {
>   struct Address {
>   class Postcode {}
>   }
> }
> 
> Postcode would be encoded as Contacts.Person.Address.Postcode. Since it is 
> not possible to have two different types with the same identifier in the same 
> namespace (i.e. an enum/a class/a struct with the same name at the same 
> declaration level) the encoding would similarly be simple. May I proceed 
> under that assumption or are there ABI stability issues I have yet to 
> consider?
> 
> Tom
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

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

[Jordan Rose via swift-corelibs-dev]

Adding swift-corelibs-dev, since that’s where the Dispatch folks hang out.

> On Nov 2, 2016, at 10:44, Doug Coleman via swift-dev  
> wrote:
> 
> https://bugs.swift.org/browse/SR-2931 
> 
> 
>> On Nov 2, 2016, at 10:43 AM, no-re...@swift.org wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#8568]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/8568/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-15_10
>> Date of build:   Wed, 02 Nov 2016 10:17:41 -0700
>> Build duration:  25 min
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8487 test(s), Total: 8487 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 299 test(s), Total: 299 test(s)
>> 
>> Changes
>> 
>> Commit 3575ee1954ea68f3d569c1f4481ca850d9fe87a3 by practicalswift:
>> [swiftc (94 vs. 5180)] Add crasher in ?
>> 
>> add: 
>> validation-test/compiler_crashers/28463-child-source-range-not-contained-within-its-parent-guard-stmt.swift
> 
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

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

[Jordan Rose via swift-corelibs-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: Foundation/NSKeyedArchiver.swi

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

[Jordan Rose via swift-corelibs-dev]

Foundation folks, have you seen this before?

TestFoundation/TestNSAffineTransform.swift:187: error: 
TestNSAffineTransform.test_Rotation_Radians : XCTAssertEqualWithAccuracy 
failed: ("10.0") is not equal to ("-10.0") +/- ("0.001") - y (expected: -10.0, 
was: 10.0): 

Jordan

> On Feb 20, 2017, at 12:05, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2022]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2022/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Mon, 20 Feb 2017 11:47:26 -0800
> 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 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8993 test(s), Total: 8993 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 341 test(s), Total: 341 test(s)
> 
> Changes
> 
> Commit 042e6510c324c699b86e7a8d0d20068b2ee8feb4 by dgregor:
> [AST] Drop ProtocolDecl's "inherited protocols" list.
> 
> edit: test/decl/class/circular_inheritance.swift
> edit: lib/IRGen/GenProto.cpp
> delete: 
> validation-test/compiler_crashers/28599-false-should-have-found-context-by-now.swift
> edit: include/swift/AST/Decl.h
> edit: lib/Sema/ITCDecl.cpp
> edit: lib/Sema/TypeCheckProtocol.cpp
> edit: lib/IRGen/GenMeta.cpp
> edit: test/decl/protocol/protocols.swift
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: lib/AST/Type.cpp
> edit: lib/AST/SubstitutionMap.cpp
> edit: lib/Serialization/Deserialization.cpp
> delete: 
> validation-test/compiler_crashers/28604-isinheritedprotocolsvalid.swift
> edit: lib/IRGen/GenArchetype.cpp
> add: 
> validation-test/compiler_crashers_fixed/28599-false-should-have-found-context-by-now.swift
> edit: lib/AST/LookupVisibleDecls.cpp
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: test/SILGen/objc_bridging_any.swift
> edit: lib/IRGen/GenClass.cpp
> edit: lib/Sema/TypeChecker.h
> edit: lib/AST/Decl.cpp
> edit: lib/Serialization/Serialization.cpp
> edit: include/swift/SIL/SILWitnessVisitor.h
> edit: lib/Sema/TypeCheckType.cpp
> add: 
> validation-test/compiler_crashers_fixed/28604-isinheritedprotocolsvalid.swift
> edit: lib/PrintAsObjC/PrintAsObjC.cpp
> edit: include/swift/Serialization/ModuleFormat.h
> edit: lib/IRGen/Fulfillment.cpp
> 
> Commit 205303aa64579b40d20c8e052d24c46a87d3a552 by blangmuir:
> Disable round_trip_stdlib.swift temporarily
> 
> edit: test/Syntax/round_trip_stdlib.swift
> 
> Commit cb5bc1fedf1da72e5cb25e529915cce941ad327d by mgottesman:
> Disable opaque_values_silgen.swift with a resilient stdlib until I have
> 
> edit: test/SILGen/opaque_values_silgen.swift
> 
> Commit b50f044c3d646abfe2e3264369b9a9b616ff6886 by github:
> Disable a part of the Syntax unit tests under no-asserts. (#7644)
> 
> edit: unittests/Syntax/TypeSyntaxTests.cpp

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

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

[Jordan Rose via swift-corelibs-dev]

Maybe something changed in the standard library's handling of floats? Max?

> On Feb 20, 2017, at 13:26, Philippe Hausler  wrote:
> 
> That would be new; I have not seen that failure before. the method is quite 
> droll - it just calls sin/cos and resets the m values accordingly. 
> 
> Did sin/cos change? the values being sent in are reasonable (not at a point 
> it would be in any question of the return value)
> 
> 
>> On Feb 20, 2017, at 9:18 PM, Jordan Rose via swift-dev > > wrote:
>> 
>> Foundation folks, have you seen this before?
>> 
>> TestFoundation/TestNSAffineTransform.swift:187: error: 
>> TestNSAffineTransform.test_Rotation_Radians : XCTAssertEqualWithAccuracy 
>> failed: ("10.0") is not equal to ("-10.0") +/- ("0.001") - y (expected: 
>> -10.0, was: 10.0): 
>> 
>> Jordan
>> 
>>> On Feb 20, 2017, at 12:05, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2022]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2022/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_10
>>> Date of build:  Mon, 20 Feb 2017 11:47:26 -0800
>>> 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 
>>> 
>>> Tests:
>>> 
>>> Name: Swift(linux-x86_64)
>>> Failed: 0 test(s), Passed: 8993 test(s), Total: 8993 test(s)
>>> Name: Swift-Unit
>>> Failed: 0 test(s), Passed: 341 test(s), Total: 341 test(s)
>>> 
>>> Changes
>>> 
>>> Commit 042e6510c324c699b86e7a8d0d20068b2ee8feb4 by dgregor:
>>> [AST] Drop ProtocolDecl's "inherited protocols" list.
>>> 
>>> edit: test/decl/class/circular_inheritance.swift
>>> edit: lib/IRGen/GenProto.cpp
>>> delete: 
>>> validation-test/compiler_crashers/28599-false-should-have-found-context-by-now.swift
>>> edit: include/swift/AST/Decl.h
>>> edit: lib/Sema/ITCDecl.cpp
>>> edit: lib/Sema/TypeCheckProtocol.cpp
>>> edit: lib/IRGen/GenMeta.cpp
>>> edit: test/decl/protocol/protocols.swift
>>> edit: lib/Sema/TypeCheckDecl.cpp
>>> edit: lib/AST/Type.cpp
>>> edit: lib/AST/SubstitutionMap.cpp
>>> edit: lib/Serialization/Deserialization.cpp
>>> delete: 
>>> validation-test/compiler_crashers/28604-isinheritedprotocolsvalid.swift
>>> edit: lib/IRGen/GenArchetype.cpp
>>> add: 
>>> validation-test/compiler_crashers_fixed/28599-false-should-have-found-context-by-now.swift
>>> edit: lib/AST/LookupVisibleDecls.cpp
>>> edit: lib/ClangImporter/ImportDecl.cpp
>>> edit: test/SILGen/objc_bridging_any.swift
>>> edit: lib/IRGen/GenClass.cpp
>>> edit: lib/Sema/TypeChecker.h
>>> edit: lib/AST/Decl.cpp
>>> edit: lib/Serialization/Serialization.cpp
>>> edit: include/swift/SIL/SILWitnessVisitor.h
>>> edit: lib/Sema/TypeCheckType.cpp
>>> add: 
>>> validation-test/compiler_crashers_fixed/28604-isinheritedprotocolsvalid.swift
>>> edit: lib/PrintAsObjC/PrintAsObjC.cpp
>>> edit: include/swift/Serialization/ModuleFormat.h
>>> edit: lib/IRGen/Fulfillment.cpp
>>> 
>>> Commit 205303aa64579b40d20c8e052d24c46a87d3a552 by blangmuir:
>>> Disable round_trip_stdlib.swift temporarily
>>> 
>>> edit: test/Syntax/round_trip_stdlib.swift
>>> 
>>> Commit cb5bc1fedf1da72e5cb25e529915cce941ad327d by mgottesman:
>>> Disable opaque_values_silgen.swift with a resilient stdlib until I have
>>> 
>>> edit: test/SILGen/opaque_values_silgen.swift
>>> 
>>> Commit b50f044c3d646abfe2e3264369b9a9b616ff6886 by github:
>>> Disable a part of the Syntax unit tests under no-asserts. (#7644)
>>> 
>>> edit: unittests/Syntax/TypeSyntaxTests.cpp
>> 
>> ___
>> swift-dev mailing list
>> swift-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 

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

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

[Jordan Rose via swift-corelibs-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-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[Jordan Rose via swift-corelibs-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-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

[Jordan Rose via swift-corelibs-dev]

(moving to more relevant list)

> On Dec 18, 2017, at 08:51, Benoit Pereira da silva via swift-users 
>  wrote:
> 
> Dear all
> 
> I've found a serious Bug in JSONEncoder SR-6131 
>  and would like to fix it.
> This bug cause JSON encoding issues on Double when using a local that does 
> not use dot as decimal separator e.g « fr_FR » (we use a coma)
> 
> Demonstration of the issue : 
> 
> import Foundation
> 
> // Required to call setLocale
> import Darwin
> 
> // Let's set to french
> setlocale(LC_ALL,"fr_FR")
>  
> struct Shot:Codable{
> let seconds:Double
> }
>  
> let shot = Shot(seconds: 1.1)
>  
> do{
> let data = try JSONEncoder().encode(shot)
> if let json =  String(data:data, encoding:.utf8){
> // the result is : "{"seconds":1,1001}"
> // The decimal separator should not be "," but "."
> print(json)
> }
> }catch{
> print("\(error)")
> }
>  
> exit(EX_OK)
> 
> 
> 
> 
> I would like to propose my fix, test it and, but i’m not mastering the 
> contribution mechanism.
> 
> Where should i start? 
> 
> I ve forked 
> https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 
> 
> I have a very simple Unit test that demonstrates the issue.
> 
> How can i test my 
> 
> 
> Thanks
> 
> 
> 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l'expéditeur.
> 
> 
> 
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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