Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (master) #1021

That test failure is my fault. Sorry about that, I’ll fix it shortly. In the mean time you can do a smoke test instead of a full test and it won’t run i386 tests. Slava > On Jan 11, 2018, at 2:51 PM, Itai Ferber wrote: > > Hi Doug, Slava, > > Looks like this is still an issue — just hit this

Re: [swift-dev] "available externally" vs build time

> On Jan 4, 2018, at 1:08 PM, Erik Eckstein wrote: > > > >> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev >> wrote: >> >> >> >>> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev >>> wrote: >>> >

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

> On Jan 3, 2018, at 7:36 PM, Vedant Kumar wrote: > >> >> On Jan 3, 2018, at 7:34 PM, Mark Lacey > > wrote: >> >> >> >>> On Jan 3, 2018, at 7:31 PM, Vedant Kumar >> > wrote: >>> On Jan 3, 2018, at 7:23 PM, Mark Lacey >>>

Re: [swift-dev] "available externally" vs build time

> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev > wrote: > > Folks working on the SIL optimizer, particularly those interested in faster > builds: > > If I understand the SIL optimizer correctly, it seems that when the current > program references an external symbol declared as @

Re: [swift-dev] Build standard library failed in debug

This is an error compiling Clang. Which branch/tag are you building? Slava > On Dec 24, 2017, at 6:56 PM, Meiliang Dong via swift-dev > wrote: > > Hi swift developers, I get a compile error when try to build standard > library in debug with command:`$ swift/utils/build-script --release-debug

Re: [swift-dev] Protocol Devirtualizer Pass

> On Dec 20, 2017, at 3:56 PM, Raj Barik wrote: > > Thank you Arnold & Slava! The protocol devirtualizer pass works fine now for > most cases. I should be creating a PR soon (after some more testing). > > I am thinking about extending this to Optional types as well, i.e., I’m not sure if it

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

> On Dec 18, 2017, at 6:27 PM, Dave Abrahams via swift-dev > wrote: > > > >> On Dec 18, 2017, at 4:52 PM, Douglas Gregor via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Hi all, >> >> A little while back, I added an error to the Swift 4.1 compiler that

Re: [swift-dev] Simple question about ParameterTypeFlags

tter. >> >> Slava >> >>> On Dec 11, 2017, at 2:05 PM, David Zarzycki wrote: >>> >>> Hi Slava, >>> >>> Interesting. Did I make a mistake in my test then? Both __shared @escaping >>> and __shared @autoclosure are failing be

Re: [swift-dev] Create SILType from GenericTypeParamType

There are two things that need to happen here, first the generic type parameter needs to be substituted with a concrete type, then it needs to be “lowered” to a SIL type. You can try something like this, GenericTypeParamType *paramTy = …; SILFunction *F = …; SILType T = F->getModule().Types.get

Re: [swift-dev] Simple question about ParameterTypeFlags

Hi Slava, > > Interesting. Did I make a mistake in my test then? Both __shared @escaping > and __shared @autoclosure are failing below. > > Dave > >> On Dec 11, 2017, at 16:58, Slava Pestov via swift-dev >> wrote: >> >> I think perhaps __shared @escaping

Re: [swift-dev] Simple question about ParameterTypeFlags

I think perhaps __shared @escaping and __shared @autoclosure should be OK. You’re just passing the context as a +0 value instead of +1. Also __shared varargs make sense for the same reason. But it’s not important to get that working right now. The others look OK. Slava > On Dec 11, 2017, at 1

Re: [swift-dev] [SE-0143] Dynamic casting for conditional conformances

> On Dec 6, 2017, at 10:04 PM, Slava Pestov via swift-dev > wrote: > >> >> In AST terms: >> func matchEnvironment(GenericSignature, Type, TypeMetadata) -> >> GenericEnvironment? >> func substitute(GenericEnvironment, Type) -> TypeMetadata? &g

Re: [swift-dev] [SE-0143] Dynamic casting for conditional conformances

> On Dec 6, 2017, at 10:00 PM, John McCall wrote: > > Yes, I can see how there's some nice synergy there, and it would certainly be > good to avoid having to eagerly generate code for this operation. And it > should be possible to optimize the cast operation in the runtime if we find > ours

Re: [swift-dev] [swift-build-dev] Swift CI will be down for maintenance - Dec 5th 2017 - 1pm PST

CI is not triggering for me here: https://github.com/apple/swift/pull/13288 Slava > On Dec 5, 2017, at 4:25 PM, Mishal Shah via swift-dev > wrote: > > Maintenance completed. > > Thanks, > Mishal Shah > >> On Dec 5, 2017, at 1:00 PM, Mishal Shah v

Re: [swift-dev] [SE-0143] Dynamic casting for conditional conformances

> On Dec 5, 2017, at 4:05 PM, Douglas Gregor via swift-dev > wrote: > > > >> On Dec 5, 2017, at 3:56 PM, David Hart > > wrote: >> >> But that wouldn’t allow surfacing a func type(named: String) Standard >> Library function that worked on any type, wouldn’t it (lik

Re: [swift-dev] [SE-0143] Dynamic casting for conditional conformances

> On Dec 5, 2017, at 3:42 PM, John McCall via swift-dev > wrote: > >> On Dec 5, 2017, at 5:28 PM, Douglas Gregor via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> Hi all, >> >> The main missing piece for conditional conformances >> (https://github.com/apple/swift-evolution/blob/master

Re: [swift-dev] Equatable for two dimension array still not working (e.g. [[1]] == [[1]])

Try the master development snapshot. The changes have not been merged to swift-4.1-branch. Slava > On Dec 2, 2017, at 12:34 PM, Cao, Jiannan via swift-dev > wrote: > > I used the swift-4.1-DEVELOPMENT-SNAPSHOT-2017-11-30-a-osx to test: > > Welcome to Apple Swift version 4.1-dev (LLVM 05fee6f

Re: [swift-dev] Protocol Devirtualizer Pass

Hi Raj, The way I would approach this problem is first, turn a function taking a protocol value into one taking a protocol-constrained generic parameter. So @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{ return a.increment(i:val) } Would become @inline(always) internal

Re: [swift-dev] Potential contributions to compilation time reporting?

> On Nov 28, 2017, at 5:01 PM, Mark Lacey via swift-dev > wrote: > > > >> On Nov 19, 2017, at 9:02 PM, Brian Gesiak via swift-dev > > wrote: >> >> Thanks for the reply, Graydon, and for your other email on the topic >>

Re: [swift-dev] [swift-users] Where to read about *.swiftmodule file format?

Hi Volodymyr, The format is not documented anywhere and is subject to change. A good starting point is include/swift/Serialization/ModuleFormat.h, but I would first be curious to know what exactly you’re planning on doing with it. It might be better to extend swift-ide-test and similar utilitie

Re: [swift-dev] Building Swift 2.2.1 on macOS High Sierra (10.13)

> On Nov 19, 2017, at 6:12 PM, leanne wrote: > > If I get where you're going, though, Slava, does building Swift 2.2.1 require > an older version of the Xcode Command Line Tools, then??? Is that why I might > need an older Xcode? That’s my theory, yeah. Slava

Re: [swift-dev] Building Swift 2.2.1 on macOS High Sierra (10.13)

What version of Xcode are you using to _build_ Swift 2.2? You might need an older Xcode for that. Slava > On Nov 19, 2017, at 11:24 AM, leanne wrote: > > Yes, I could, Slava. I was hoping not to, though. That's the point of using > swiftenv. > > On Sat, Nov 18, 2017 at 6:24 PM, Slava Pestov

Re: [swift-dev] Building Swift 2.2.1 on macOS High Sierra (10.13)

Instead of building Swift yourself, can you download and run Xcode 7 instead? Slava > On Nov 18, 2017, at 7:19 PM, leanne via swift-dev wrote: > > I'm using swiftenv (https://github.com/kylef/swiftenv > ) to install Swift versions 2 and 3, so I > can work wi

Re: [swift-dev] AutomaticEnumValueKind Tuple of Literals

Hi Mohammed, The ‘automatic enum value’ code path is used if you have code like this, where you declare a raw type but don’t assign raw values: enum E : Int { case a case b case c } This only makes sense for a raw type of integer, and not string — or a tuple. Even if you have (Int, Int)

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

I reverted Kelvin’s change in the swift-4.1-branch. Foundation auto merges from master to swift-4.1-branch but Swift does not, so the two repositories were out of sync. https://github.com/apple/swift-corelibs-foundation/pull/1327 Sl

Re: [swift-dev] Highlighting other platforms for Swift?

> On Nov 15, 2017, at 11:35 AM, Ted Kremenek via swift-dev > wrote: > > That said, do you have specific ideas on how such efforts should be > highlighted on swift.org , and what should be the optics? I think more prominent links to instructions for building Swift on other

Re: [swift-dev] No attribute(swiftcall) support on Linux?

This is while building the metadata unit tests — I’m assuming those are built with the host clang? Do we build the runtime with the Swift clang on Linux? If so, we should still be able to use swiftcall. Slava > On Nov 13, 2017, at 10:47 PM, Greg Parker via swift-dev > wrote: > > I see that i

Re: [swift-dev] Preparing metadata records for ABI stability

> On Nov 13, 2017, at 11:40 AM, John McCall via swift-dev > wrote: > > - I feel like we're not boxing ourselves in too much to assume a layout of > the generic requirements. Having a base offset already imposes a pretty > steep compatibility requirement — e.g. even if we significantly gene

Re: [swift-dev] SR-3423 Enum RawValue Tuple of Literals

> On Nov 12, 2017, at 5:37 PM, Mohammed Ennabah via swift-dev > wrote: > > Hi All, > > I’m working on SR-3423, the issue basically is Swift does not allow using > literals when they are represented as tuples. Now when I went through the > codebase, I found that (AFAIK) it can be fixed by ei

Re: [swift-dev] deprecating -Ounchecked

> On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev > wrote: > > Random question: when did you introduce -Osize, and why didn’t it go through > the evolution process? If this is a major flag that you expect users to > interact with (not some obscure debugging feature) then it is part

Re: [swift-dev] deprecating -Ounchecked

> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev > wrote: > > So if we replace Ounchecked with an option -unsafe-remove-checks (similar to > -assume-single-threaded), as Johannes suggested, this is more like a “at your > own risk” thing (regarding performance). For example, it might

Re: [swift-dev] How does a standard collection know when its storage has to die?

These types are essentially single-field structs. The underlying storage is referenced from this field, which has a reference type. While structs cannot have user-defined destructors, the compiler knows when a value of struct type goes out of scope and destroys its fields, which for reference ty

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

> 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

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

There has been a missing dependency here forever. Can someone well versed in cmake take a look? It should be an easy fix. Slava > On Oct 17, 2017, at 11:54 AM, Pavel Yaskevich via swift-dev > wrote: > > This is my changes - they require a clean build (because I changed TypeRef > but didn’t c

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

Another dispatch failure: 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-incremental-RA-linux-ubuntu-16_04/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Disp

Re: [swift-dev] Reducing array abstraction

> On Oct 7, 2017, at 2:01 PM, Chris Lattner wrote: > > Right. If we ignore source compatibility for the moment, it seems clear that > the best callee side representation for varargs is a borrowing array slice > (like llvm::ArrayRef or UnsafeBufferPointer). This provides the essential > abs

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

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

Re: [swift-dev] Reducing array abstraction

> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev > wrote: > > This question is somewhere between swift-dev and swift-users, not sure where > best to post this. > > I’m working on a project that wants to get very low-abstraction penalty array > operations, particularly with varar

Re: [swift-dev] Should non-final classes be allowed to conform to Collection?

ngIterator { … } >> } >> >> I believe this will fix the source compatibility issue and also make ‘for x >> in Derived()’ type check. The downside is that the witness table for a >> Collection conformance now stores an additional associated type for the >> static c

Re: [swift-dev] Should non-final classes be allowed to conform to Collection?

ver that’s exactly what you need to store > somewhere to make this work for non-final classes. > > Slava > >> On Oct 6, 2017, at 12:25 AM, Slava Pestov via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Hi all, >> >> Consider this code,

Re: [swift-dev] Should non-final classes be allowed to conform to Collection?

ere to make this work for non-final classes. Slava > On Oct 6, 2017, at 12:25 AM, Slava Pestov via swift-dev > wrote: > > Hi all, > > Consider this code, > > class Base : Collection { > var startIndex: Int { return 0 } > > var endIndex: Int { return

[swift-dev] Should non-final classes be allowed to conform to Collection?

Hi all, Consider this code, class Base : Collection { var startIndex: Int { return 0 } var endIndex: Int { return 10 } func index(after i: Int) -> Int { return i + 1 } subscript(index: Int) -> Int { return index } } We infer the associated type ‘Iterator’ as ‘IndexingIterator’. I can

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

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 bu

Re: [swift-dev] Builtin.loadRaw

Hi Sam, The builtin is defined in lib/SILGen/SILGenBuiltin.cpp, look for the function named emitBuiltinLoadRaw(). However I suspect the problem in this case is not that the builtin is implemented incorrectly (it eventually lowers to an LLVM load instruction) but that something further upstream

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

You’re right, because it’s due to my changes. This should fix it: https://github.com/apple/swift/pull/12131 Slava > On Sep 26, 2017, at 1:13 PM, Pavel Yaskevich via swift-dev > wrote: > > Hi guys, > >This doesn’t seem to be caused by my change

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

This should fix it: https://github.com/apple/swift/pull/12119 <https://github.com/apple/swift/pull/12119> Slava > On Sep 25, 2017, at 9:55 PM, Slava Pestov via swift-dev > wrote: > > This is from my changes. I think I know what the problem is, I’ll test a fix > now. &g

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

This is from my changes. I think I know what the problem is, I’ll test a fix now. Slava > On Sep 25, 2017, at 9:38 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-ASAN-RA-osx [#293] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/293/ >

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

For PR testing, a clean build fixed the issue for me. Slava > On Sep 19, 2017, at 11:08 AM, Joe Shajrawi via swift-dev > wrote: > > libdispatch is still failing to build on some platforms: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10//634/console > >

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (master) #311

Greg, Does this look OK? https://github.com/apple/swift/pull/12002 > On Sep 19, 2017, at 11:37 AM, no-reply--- via swift-dev > wrote: > > [FAILURE] oss-swift-package-osx [#311] > > Build URL:https://ci.swift.org/job/oss-swift-package-osx/311/

Re: [swift-dev] Unit tests for the Swift project

> On Sep 12, 2017, at 11:29 PM, Alwyn Concessao wrote: > > Okay.I see a couple of Swift files and .gyb files inside test/stdlib.I've > made changes to the RangeReplaceableCollection protocol of the Swift > stdlib.How can I write unit tests for that?Can I generate an Xcode project > for the un

Re: [swift-dev] Value-type bound protocols?

> On Sep 13, 2017, at 12:23 PM, Matthew Johnson via swift-dev > wrote: > > > > Sent from my iPhone > >> On Sep 13, 2017, at 11:56 AM, David Zarzycki via swift-dev >> wrote: >> >> >> >>> On Sep 13, 2017, at 13:53, David Sweeris wrote: >>> >>> On Sep 13, 2017, at 09:54, David Zarz

Re: [swift-dev] Unit tests for the Swift project

Take a look at test/stdlib/. Unit tests use the SwiftUnittest framework, you should be able to get started by looking at existing examples. Slava > On Sep 12, 2017, at 5:35 AM, Alwyn Concessao via swift-dev > wrote: > > Hey Swift devs, > > So I have been able to clone the Swift project from

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

> On Sep 6, 2017, at 7:57 PM, Brent Royal-Gordon via swift-dev > wrote: > >> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev > > wrote: >> >> Now, we don't plan to stick to C's layout for structs, even fixed-contents >> structs. We'd really like users to not

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

> On Sep 6, 2017, at 11:09 AM, David Zarzycki via swift-dev > wrote: > > I see. Would “@fixedSize” or “@abi(size)” be better names? In other words, > the developer promises that whatever size the struct is now, it will be that > way forever? > > Also, wouldn’t the Pair example below require

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

> On Sep 5, 2017, at 6:37 PM, Nevin Brackett-Rozinsky via swift-dev > wrote: > > On Tue, Sep 5, 2017 at 6:08 PM, Slava Pestov via swift-dev > mailto:swift-dev@swift.org>> wrote: > We expect that “define your struct in C” is still the way to go for layout > compati

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

> On Sep 5, 2017, at 1:01 PM, David Zarzycki via swift-dev > 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 abil

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

> 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 layo

Re: [swift-dev] Advice for implementing "literal values as generic types"

> On Aug 29, 2017, at 2:21 PM, David Sweeris wrote: > > >> On Aug 29, 2017, at 1:49 PM, Slava Pestov > > wrote: >> >> >>> On Aug 29, 2017, at 11:03 AM, David Sweeris via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> >>> Hi everyone! I'm trying to implement

Re: [swift-dev] Advice for implementing "literal values as generic types"

> On Aug 29, 2017, at 11:03 AM, David Sweeris via swift-dev > wrote: > > Hi everyone! I'm trying to implement literal values as generic types. Can you briefly explain what you mean by this? Are you referring to let-polymorphism, like let fn = { $0 } let f1: (Int) -> Int = fn let f2: (Float)

Re: [swift-dev] Making a protocol's associated type concrete via inheritance

This is not supported right now but it is within the realm of possibility of things that we can support. The restriction on using protocols as types is artificial — it was put in place to avoid confusing users. So it is a matter of tweaking the logic which diagnosed unsupported protocol types t

Re: [swift-dev] swift module format

> On Aug 24, 2017, at 10:56 PM, John McCall via swift-dev > wrote: > > Or if you really want to avoid the FFI, you could take our current ASTDumper > output, which is currently pseudo-machine-readable, and make it actually > machine-readable. The elegant approach there would be to take the e

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

I think this is a transient failure because my patch changed ABI — can someone clean the workspace? > On Aug 24, 2017, at 6:17 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#254] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-li

Re: [swift-dev] swift module format

Yeah, it’s important to keep in mind we don’t have a stable module format right now, so anything developed Swift 4 will likely need to be revised again with the next version. The C++ API is not stable either, but approach could be to dump the ‘generated interface’ using swift-ide-tool or simila

Re: [swift-dev] Build Failure with Xcode 9.0 beta 5

> On Aug 16, 2017, at 6:21 PM, David Sweeris via swift-dev > wrote: > > Does it hurt anything to have both betas installed? I'm in the process of > installing the 4th beta now. Once that's done, I'm going to build the Xcode > project. I'd like to reinstall beta 5 after that, but not if that'l

Re: [swift-dev] Portable stdlib

> On Aug 14, 2017, at 9:44 AM, Andy Best via swift-dev > wrote: > > Hey, > > I'm currently looking at building a portable version of the standard library > (for targeting microcontrollers, kernel dev, etc). I’m a bit confused about your terminology. By “portable” do you mean no dependencies

Re: [swift-dev] Is swift.org/contributing/ stale?

I think it’s still up to date. You need commit access to trigger CI, and to merge PRs. Otherwise you’ll have to ask someone with commit access to do that for you. Slava > On Aug 14, 2017, at 1:14 PM, David Zarzycki via swift-dev > wrote: > > On the swift.org/contributing/ web page, under “Co

Re: [swift-dev] switches versus the visitor pattern?

I’ve seen some switches over TypeKind more easily expressed as a series of if/else if statements also. However unless you come across an ugly switch that you want to refactor while working on something else, I probably wouldn’t spend time actively seeking them out and changing them. I don’t thi

Re: [swift-dev] 107 lines of "dead" code in ConstraintSystem::performMemberLookup?

I see you’re two steps ahead of me already: https://github.com/apple/swift/pull/11397 This looks good, nice catch! Slava > On Aug 8, 2017, at 8:45 PM, Slava Pestov wrote: > > >> On Aug 8, 2017, at 3:34 PM, David Zarzycki via swift-dev >> wrote:

Re: [swift-dev] 107 lines of "dead" code in ConstraintSystem::performMemberLookup?

> On Aug 8, 2017, at 3:34 PM, David Zarzycki via swift-dev > wrote: > > In ConstraintSystem::performMemberLookup(), constructors with “simple” names > have a dedicated lookup path. In contrast, constructors with compound names > are handled by the normal lookup. If I delete this code and let

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

> On Jul 30, 2017, at 5:47 PM, John McCall wrote: > >> On Jul 29, 2017, at 7:35 PM, Slava Pestov > > wrote: >>> On Jul 29, 2017, at 12:53 PM, John McCall via swift-dev >>> mailto:swift-dev@swift.org>> wrote: On Jul 29, 2017, at 12:48 AM, Andrew Trick >>>

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

> On Jul 28, 2017, at 4:07 PM, Jordan Rose via swift-dev > wrote: > > My point is we can't use our usual mangling in the string, because that > contains type names. > We could invent a ‘mangling’ format (either using the existing demangler with a special flag or something else) where types

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

> On Jul 29, 2017, at 12:53 PM, John McCall via swift-dev > wrote: > >> On Jul 29, 2017, at 12:48 AM, Andrew Trick > > wrote: >>> On Jul 28, 2017, at 8:13 PM, John McCall >> > wrote: On Jul 28, 2017, at 11:11 PM, John McCall via swift-dev

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

Hi David, I reverted your PR because it appears to have broken the build: https://github.com/apple/swift-corelibs-libdispatch/pull/278 Please take a look when you get a chance. Slava > On Jul 13, 2017, at 9:02 PM, no-re...@swift.o

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

FWIW I filed rdar://33276769 to track the issue internally. > On Jul 12, 2017, at 3:44 PM, Pavel Yaskevich wrote: > > Log says: > > /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script-impl: > line 262: 27497 Segmentation fault "$@" > /home

Re: [swift-dev] Pathway to becoming an effective contributor

> On Jun 21, 2017, at 2:12 PM, Natthan Leong via swift-dev > wrote: > > Hi, > > As someone who also recently started contributing, I was surprised to discover > how much computing power was needed to build Swift. My first few build > attempts > on a mid-2014 rMBP took more than an hour with 1

Re: [swift-dev] CI failure: .../TestFoundation: undefined symbol: _T0ScN

It’s an incremental build issue. The bots don’t always rebuild Foundation, or something. I think we need to clean the workspace out. Slava > On May 13, 2017, at 12:13 AM, Boris Buegling via swift-dev > wrote: > > Hi everyone, > > I am seeing a CI failure on llbuild for seemingly unrelated re

Re: [swift-dev] PR review process

y 4, 2017, at 2:40 PM, Slava Pestov via swift-dev > wrote: > > Hi Pavol, > > Bug us mercilessly if you need something reviewed. > > Slava > >> On May 4, 2017, at 9:26 AM, Pavol Vaskovic via swift-dev >> wrote: >> >> Hello! >> >> Wh

Re: [swift-dev] PR review process

Hi Pavol, Bug us mercilessly if you need something reviewed. Slava > On May 4, 2017, at 9:26 AM, Pavol Vaskovic via swift-dev > wrote: > > Hello! > > What is the process for getting a PR reviewed and merged into Swift? My > experience so far is inconsistent. Sometimes I get a response in a

Re: [swift-dev] Miscompile with protocol compositions

Q : class, P {} extension P { mutating func foo() { bar() } } class C : Q { let x: Int = 100 func bar() { print(x) // crash here } } func takesQ(q: Q) { var qq = q qq.foo() } takesQ(q: C()) > On Apr 27, 2017, at 12:35 AM, Slava Pestov via swift-dev > wrote: >

[swift-dev] Miscompile with protocol compositions

Hi all, I’ve spent most of the last two days debugging various issues with property and subscript accesses on class-constrained existentials and I’ve just now realized the root cause is a much more fundamental issue. Consider the following code: protocol P { var x: Int { get set } init()

[swift-dev] IRGen's swift_rt_* functions

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 ___ s

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

This is most definitely not your fault, because it is my fault, from the subclass existential runtime changes. I first saw the failure a few days ago but it slipped my mind. Will look at it now. Slava > On Apr 18, 2017, at 6:01 PM, Jordan Rose via swift-dev > wrote: > >

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

This could be a regression from https://github.com/apple/swift/pull/8770 . I’ll take a look. > On Apr 14, 2017, at 9:08 PM, Andrew Trick via swift-dev > wrote: > > > runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED > > This is unr

Re: [swift-dev] IRGen variadic function declaration

Please don’t use @_silgen_name. Soon it will only be available within the standard library. Instead, write C wrappers around your intrinsics and create a Clang module that you can import from Swift. If you define the wrappers as static inline functions in a header file there won’t be any runtim

Re: [swift-dev] Compiler crash when optimisation enabled

tps://github.com/apple/swift/commit/2307145c0ef7daaefe4fe0ac20fedb17f0b22730> Slava > On Apr 7, 2017, at 7:55 PM, Slava Pestov via swift-dev > wrote: > > There’s a chance this might already be fixed — > https://github.com/apple/swift/pull/8588 > <https://github.com/apple/sw

Re: [swift-dev] Compiler crash when optimisation enabled

There’s a chance this might already be fixed — https://github.com/apple/swift/pull/8588 . Do you mind trying a 4.0 snapshot when it rolls around (probably tomorrow)? Slava > On Apr 7, 2017, at 8:32 AM, Mark Woollard via swift-dev > wrote: > > https:

Re: [swift-dev] Unexpected Expr type

Here’s what the AST looks like in this case — there is a ParenExpr but it’s inside a LoadExpr — we’re semantically loading the largest sub-expression that’s an lvalue, which here is ‘(x)’ not ‘x’: (assign_expr (declref_expr type='@lvalue Int' accessKind=write location=x.swift:3:1

Re: [swift-dev] PR test failing with clang compile error

il > <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>) > Another attempt to fix the sphinx warning from r299470 (detail > <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>) > > Thanks, > Mishal Shah >> On Apr 6, 2

[swift-dev] PR test failing with clang compile error

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::BinaryOpera

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

I thought this was my changes but then it cleared up on the next build. Xi, I filed rdar://31234811 with some information. Since you’re the build czar can you keep an eye on this bot and see if this test fails again? Slava > On Mar 23, 2017, at 8:32 PM, no-re...@swift.org wrote: > > [FAILURE

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

This needs someone to clean the workspace. > On Feb 20, 2017, at 9:30 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2035] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2035/ >

Re: [swift-dev] Profiling ARC

> On Feb 16, 2017, at 6:48 PM, Jiho Choi via swift-dev > wrote: > > Hi, > > I was curious about the overhead of ARC and started profiling some benchmarks > found in the Computer Language Benchmark Game > (http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift >

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

I’ve seen this before. It would be useful if we kept all old CI logs in an easily searchable form. Slava > On Feb 13, 2017, at 1:28 PM, Jordan Rose via swift-dev > wrote: > > clang-4.0: error: unable to execute command: Bus error > clang-4.0: error: linker command failed due to signal (use -v

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch wrote: > > Thanks to the magic of git blame: > > > https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b > > > > > > Unless you thin

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 7, 2017, at 9:18 PM, Jacob Bandes-Storch wrote: > > I don't think it would be a very big parser change to invert the > relationship. Maybe I'll try it out and put up another PR. Unless you think there’s something to be gained, I’m not sure it’s worth it… > > On the other hand, notic

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch wrote: > > PR'd: https://github.com/apple/swift/pull/7326 > > > Although I would also ask: why is CaptureListExpr a parent of ClosureExpr and > not a child? I think it’s kind of arbitrary. You could

Re: [swift-dev] ArchetypeBuilder rename

It’s merged. Rename all you want, see if I care!!! > On Feb 7, 2017, at 7:46 PM, Douglas Gregor wrote: > > Go for it! I haven't even created the renaming PR and don't want to step on > toes. > > Sent from my iPhone > > On Feb 7, 2017, at 7:13 PM, Slava Pestov > wro

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev > wrote: > > I just learned about CaptureListExpr when working on some diagnostics. Is > there a particular reason that its member "closureBody" is an Expr* and not a > ClosureExpr*? There seems to be only one place it's built >

Re: [swift-dev] ArchetypeBuilder rename

Do you mind if I merge https://github.com/apple/swift/pull/7319 first? It’s ready to go in. Slava > On Feb 7, 2017, at 4:59 PM, Douglas Gregor via swift-dev > wrote: > > Hi all, > > The ArchetypeBuilder >

Re: [swift-dev] Change of requirements to build swift?

I think it should still build with 10.11, however you need Xcode 8.3 beta 1 now. Slava > On Feb 1, 2017, at 2:48 PM, Guillaume Lessard via swift-dev > wrote: > > Hello, > > Is master supposed to have dropped support for building on 10.11.x? > The previous snapshot I’d built was January 24th,

  1   2   >