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

You’re “safe" here: in a library with resilience enabled, protocol extension methods are not emitted into the client unless they’re marked @inlinable (or however that ends up being spelled when we’re done with SE-0193). That said, you can’t be sure someone didn’t just implement their own ‘contr

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

> On Jan 8, 2018, at 17:18, Chris Lattner wrote: > > >> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Hi, all. Swift 4.1 is off on its own branch and going well, but we never >> quite ca

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

> On Jan 5, 2018, at 23:43, David Hart wrote: > > I was really surprised when I saw that the release of 4.0 introduced this 3.2 > version to mean “the 4.0 compiler running in 3.1 compatibility mode”. So of > course, I’m even more surprised to see a new 3.3 version. I find it very > counter-i

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

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

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

Hi, all. Swift 4.1 is off on its own branch and going well, but we never quite came up with an answer for a particular problem developers might have: "am I running a Swift 4.1 compiler?". #if swift(>=3.2) // Swift 3.2 (4.0 in compatibility mode) // Swift 3.3 (4.1 in compatibility mode) // Swift

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

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

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

> On Dec 20, 2017, at 08:04, Arnold Schwaighofer via swift-dev > wrote: > > This is caused by clang change 1ac71826854a809f67ae15ddacaaa9a6eb8189e8. > > This change was reverted on swift-4.1-branch. Merging clang's > swift-4.1-branch into stable is blocked by another error that we can also s

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

We really don't want to make subscripting a non-O(1) operation. That just provides false convenience and encourages people to do the wrong thing with Strings anyway. I'm always interested in why people want this kind of ability. Yes, it's nice for teaching programming to be able to split string

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

> On Dec 13, 2017, at 14:19, Saleem Abdulrasool wrote: > >> On Dec 13, 2017, at 1:45 PM, Jordan Rose wrote: >> >> No one else has commented on this yet today, so I'll put in that I don't >> have any objections to this and don't foresee any major problems. The one >> place where we'd need to

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

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

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

> On Dec 12, 2017, at 14:15, Douglas Gregor via swift-dev > wrote: > > > >> On Dec 10, 2017, at 4:47 PM, Brent Royal-Gordon > > wrote: >> >>> On Dec 5, 2017, at 2:28 PM, Douglas Gregor via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> >>> To perform

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

Since all of the functions that use TwoWordPair::Return are part of the Swift runtime and not intended to be overloaded, we could also just make them all `extern "C"`, or give them explicit mangled names, either everywhere or just on x64 Windows. Jordan > On Dec 5, 2017, at 17:30, Thomas Roug

Re: [swift-dev] [Proposal] RangeReplaceableCollection should inherits from MutableCollection

> On Dec 4, 2017, at 18:48, Brent Royal-Gordon via swift-dev > wrote: > >> On Dec 2, 2017, at 12:31 PM, Cao, Jiannan via swift-dev >> wrote: >> >> I'd like to discuss the relation between RangeReplaceableCollection and >> MutableCollection >> >> MutableCollection is a Collection type that

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

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-dev] Default deployment target for swiftc

Thanks, all. Sounds like following Clang and the interpreter is the way to go. https://github.com/apple/swift/pull/13114 Jordan > On Nov 27, 2017, at 16:44, Jordan Rose via swift-dev > wrote: > > Hi, all. Consider the following command, as run on a Mac with an up-to-date >

[swift-dev] Default deployment target for swiftc

Hi, all. Consider the following command, as run on a Mac with an up-to-date Xcode installed: xcrun swiftc foo.swift The question: should this build for the current running OS, or the oldest macOS Swift supports (10.9)? You can always specify the deployment target OS version explicitly with the

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

> 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...@gith

Re: [swift-dev] sharing tips and tricks and scripts

I always dislike wrapper scripts because it means that people are working around undesirable behavior in a tool rather than fixing it. But that doesn't seem to be a practical answer, because people are already using wrapper scripts. (I've lost this argument several times before.) Jordan > On

Re: [swift-dev] CVaListPointer

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

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

Our worry when discussing it was that someone might have an autogenerated 1000-case enum, and passing an entire page worth of resolved symbols might not be worth it. (It is of course questionable for someone to have an autogenerated 1000-case enum as part of their binary interface, and then for

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

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

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

I will note that the Makefile build is not something we test. What happens if you drop -m from your build command, to use Ninja instead? Jordan > On Oct 8, 2017, at 22:36, Slava Pestov via swift-dev > wrote: > > Hi Atul, > > The master branch is tested in CI, so any build failures are likel

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

+Saleem, who's been looking at Dispatch's build system. > On Oct 5, 2017, at 22:12, Slava Pestov wrote: > > We keep seeing this failure in the bots: > > src/libdispatch.so: error: undefined reference to > ‘_T0s17_assertionFailures5NeverOs12StaticStringV_SSAE4fileSu4lines6UInt32V5flagstFTfq4nx

Re: [swift-dev] Exclusivity checker hacking?

> On Oct 5, 2017, at 15:44, David Zarzycki wrote: > > > >> On Oct 5, 2017, at 18:34, Jordan Rose > > wrote: >> >> >> >>> On Oct 5, 2017, at 15:23, David Zarzycki mailto:d...@znu.io>> >>> wrote: >>> >>> >>> On Oct 5, 2017, at 18:08, Jordan Rose >>>

Re: [swift-dev] Exclusivity checker hacking?

> On Oct 5, 2017, at 15:23, David Zarzycki wrote: > > > >> On Oct 5, 2017, at 18:08, Jordan Rose > > wrote: >> >> >> >>> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev >> > wrote: >>> >>> Hello, >>> >>> As an experiment, I

Re: [swift-dev] Exclusivity checker hacking?

> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev > wrote: > > Hello, > > As an experiment, I’d like to force the exclusivity checking logic to always > error at compile time, rather than a mix of compile time and run time. Near > as I can tell, there is no built in debugging logic t

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

None of these changes are related to the test that failed. We'll see if the next build passes. > On Oct 4, 2017, at 12:01, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#938] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubu

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

(Oops, it already did.) > On Oct 4, 2017, at 12:45, Jordan Rose wrote: > > None of these changes are related to the test that failed. We'll see if the > next build passes. > > >> On Oct 4, 2017, at 12:01, no-re...@swift.org >> wrote: >> >> [FAILURE] oss-swift-in

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

I wiped the workspace of the Linux bots as Roman suggested. > On Oct 3, 2017, at 16:50, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#849] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/849/

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

/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swiftpm/Tests/SourceControlTests/RepositoryManagerTests.swift:199: error: RepositoryManagerTests.testBasics : Asynchronous wait failed - Exceeded timeout of 1.0 seconds, with unfulfilled expectations: Repository lookup

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

; > On Mon, Oct 2, 2017 at 4:36 PM, Pavel Yaskevich via swift-dev > mailto:swift-dev@swift.org>> wrote: > Sorry it might be my commit actually, I am AFK for a bit, will revert once I > am back. > > Sent from my iPhone > > On Oct 2, 2017, at 3:48 PM, Jordan Rose vi

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

Doug, did you win back all the regressions yet? If not, we should probably bump up the Linux timeout for now. It's waffling back and forth between success and failure so 40 minutes ought to be enough for testing. (Yes, we want the incremental bot to be fast.) Jordan > On Oct 2, 2017, at 18:21

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

Anton just reupdated AsyncNinja, but it looks we have a new problem there: /Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/project_cache/AsyncNinja/Sources/Producer.swift:42:27: error: ambiguous use of 'suffix' _bufferedUpdates.push(bufferedUpdates.suffix(bufferSiz

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

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

Re: [swift-dev] Function overload resolution

> On Sep 26, 2017, at 18:02, Robert Widmann via swift-dev > wrote: > >> >> On Sep 25, 2017, at 10:01 AM, Nevin Brackett-Rozinsky >> mailto:nevin.brackettrozin...@gmail.com>> >> wrote: >> >> func triple(_ x: Int) -> Int { >> return 3 * x >> } >> >> extension Int { >> func triple() -

[swift-dev] Thoughts on a hypothetical "Multiple primary file" mode

Hi, all. David Ungar and Graydon Hoare have been doing compiler performance investigations, and in particular are interested in the cases where WMO-with-Onone builds are faster than the multi-file -Onone builds. By now this is out there as a hackaround for build time on targets with many files b

Re: [swift-dev] libdispatch switched to CMake

> On Sep 25, 2017, at 11:28, Jordan Rose wrote: > > > >> On Sep 24, 2017, at 19:32, Saleem Abdulrasool > > wrote: >> >> On Sat, Sep 23, 2017 at 5:02 AM, David P Grove > > wrote: >> With autotools, the first time libdispatch was built (f

Re: [swift-dev] libdispatch switched to CMake

> On Sep 24, 2017, at 19:32, Saleem Abdulrasool wrote: > > On Sat, Sep 23, 2017 at 5:02 AM, David P Grove > wrote: > With autotools, the first time libdispatch was built (for SourceKit), it just > did the C build of libdispatch. That had to be blown away and rebuilt

Re: [swift-dev] Metadata Representation

> On Sep 25, 2017, at 09:24, Joe Groff via swift-dev > wrote: > > > >> On Sep 24, 2017, at 10:30 PM, John McCall wrote: >> >> >>> On Sep 22, 2017, at 8:39 PM, Saleem Abdulrasool >>> wrote: >>> >>> On Thu, Sep 21, 2017 at 10:28 PM, John McCall wrote: >>> On Sep 21, 2017, at 10:10

Re: [swift-dev] libdispatch switched to CMake

Hey, Saleem. I don't build libdispatch that often, but it seems to be broken for me. If I delete the libdispatch-specific build directory and then use build-script with --reconfigure, it doesn't actually attempt to reconfigure. [4/50] Performing build step for 'libdispatch' FAILED: cd /home/jro

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

This (and the 14.04 failure) are just because the corresponding Clang commit hadn't propagated to the stable branch yet. The next build should pass. > On Sep 15, 2017, at 17:09, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#554] > > Build URL: > http

Re: [swift-dev] History of build-script, build-script-impl, and CMake?

Heh. Let's see: > On Sep 8, 2017, at 08:14, Brian Gesiak via swift-dev > wrote: > > Hello all, > > I'm hoping a long-time Swift contributor can help shed some light on > how the apple/swift repository ended up with a utils/build-script, a > utils/build-script-impl, and CMake files. > > Based

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

t;>> “either/or” nature of this proposal. >>>>>>> >>>>>>> First, reordering: The ability to reorder declarations is deeply >>>>>>> ingrained into the subconsciousness of Swift programmers and for good >>>>>>&

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

>>>>> The net result is that people will frequently forget about local order >>>>> sensitivity. Yes, the compiler can engage in heroics and compare the >>>>> previous module ABI and the new module ABI for conflicts, but that seems >>>>> r

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

For >>> example: >>> >>> @fixedContents(3) struct Foo { >>> @abi(0) var x: Int >>> func a() { >>> // a thousand lines of ABI layout distraction >>> } >>> @abi(1) var y: Double >>> func b() { >&

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

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

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

gt; } > @abi(2) var z: String > } > > That would enable both renaming and reordering, would it not? This approach > would also aid the compiler in quickly detecting hastily added/deleted > declarations too because the count of @abi([0-9]+) declarations wouldn’t &g

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

> On Sep 5, 2017, at 15:52, Greg Parker wrote: > > >> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Hey, all. In preparation for the several proposals we have to come this >> year, I cl

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

> On Sep 5, 2017, at 15:08, Slava Pestov via swift-dev > wrote: > >> >> On Sep 5, 2017, at 2:48 PM, Thomas Roughton via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Having an explicit @abi annotation could also go some way to addressing the >> issue of manual layout with structs.

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

Hey, all. In preparation for the several proposals we have to come this year, I cleaned up docs/LibraryEvolution.rst a little bit based on what's changed in Swift 4. This is mostly just mentioning things about generic subscripts, but there is one issu

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

Hi, Dimitri. The Swift compiler always tries to choose the most specific function when it tries to satisfy protocol requirements. In your case, that means it's going to prefer members defined in concrete types over members defined in protocol extensions. Unfortunately I think that means you're n

Re: [swift-dev] Building and Generating Xcode project for Swift source code

Hm, any chance there are spaces or slashes in "(base path)"? Maybe we forgot to quote something again. Jordan > On Sep 5, 2017, at 09:23, Alwyn Concessao via swift-dev > wrote: > > Hey Swift enthusiasts, > > I'm stuck with building the swift source code and generating the Xcode > project

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

Hm. The benchmark targets don't seem to be passing a -module-cache-path option, so it's going to be buried in your /var/folders directory. Here you go: rm -rf $(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang* Jordan > On Aug 30, 2017, at 13:54, David Zarzycki wrote: > > Hi Jordan, > > Thanks

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

Crashes in clang::ASTReader usually mean "clear your module cache". That does mean there's a bug, though, that we're not putting the revision numbers into the module hash. Mind filing an SR to track that, since I thought we were? Jordan > On Aug 30, 2017, at 13:30, David Zarzycki via swift-dev

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

Whoops. I think this is evidence in favor of having the -Werror, but also in re-running PR tests. I’ll get it. Jordan > On Aug 1, 2017, at 09:47, Andrew Trick wrote: > > Jordan, Dave, > > Are you reverting/fixing now? > -Andy > >> On Aug 1, 2017, at 9:41 AM, no-re...@swift.org

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

> On Jul 29, 2017, at 13:20, Chris Lattner wrote: > > >> On Jul 28, 2017, at 3:59 PM, Jordan Rose via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >>>> So generic code to instantiate type metadata would have to construct these >>

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

> On Jul 28, 2017, at 16:03, Joe Groff wrote: > > >> On Jul 28, 2017, at 3:59 PM, Jordan Rose > > wrote: >> >> >> >>> On Jul 28, 2017, at 15:35, Joe Groff via swift-dev >> > wrote: >>> On Jul 28, 2017, at 3:30 PM, John Mc

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

> On Jul 28, 2017, at 15:35, Joe Groff via swift-dev > wrote: > >> >> On Jul 28, 2017, at 3:30 PM, John McCall wrote: >> >>> On Jul 28, 2017, at 6:24 PM, Joe Groff wrote: On Jul 28, 2017, at 3:15 PM, John McCall wrote: > On Jul 28, 2017, at 6:02 PM, Andrew Trick via s

Re: [swift-dev] autocompletions for local variables

Hi, Mansimar. I don't work on code completion myself, but my recollection was that the results are always computed for the start location of the identifier, ignoring any text that may have already been typed. This is because SourceKit is meant to have an IDE as a client, and so to minimize traff

Re: [swift-dev] End location of the SourceRange of a NumberLiteralExpr?

Hi, David. From the docs for SourceRange: /// SourceRange in swift is a pair of locations. However, note that the end /// location is the start of the last token in the range, not the last character /// in the range. This is mainly an optimization for single-token expressions, like number liter

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

> On Jun 29, 2017, at 16:35, Daniel Dunbar wrote: > > >> On Jun 29, 2017, at 10:43 AM, Jordan Rose via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Thanks for following through on this, Gonzalo! (The two of us talked about >> this brief

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

Thanks for following through on this, Gonzalo! (The two of us talked about this briefly at WWDC.) My idea was a little less clever than yours: just always include the internal members in the main header unless you provide the name of a second header to put them in. (I called this flag -emit-obj

[swift-dev] CI failures in deserialization

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

Re: [swift-dev] Swift question

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

Re: [swift-dev] statically initialized arrays

> On Jun 14, 2017, at 11:24, Erik Eckstein via swift-dev > wrote: > > Hi, > > I’m about implementing statically initialized arrays. It’s about allocating > storage for arrays in the data section rather than on the heap. > > Info: the array storage is a heap object. So in the following I’m u

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

> On Jun 13, 2017, at 16:11, John McCall via swift-dev > wrote: > > So, there's a longstanding issue that we're planning to fix in Swift 4, and I > want to both make sure that the plan is documented publicly and give people a > chance to disagree with it. > > A bridging conversion is a conv

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

michael-yuji on GitHub just sent us a patch in https://github.com/apple/swift/pull/9940 , so at least that part's not a concern. > On May 25, 2017, at 17:47, Michael Ilseman via swift-dev > wrote: > > If that’s the case, we’ll want to add in FreeBSD

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

I don't think this is any of mine. /home/buildnode/disk2/workspace/oss-swift-4.0-incremental-RA-linux-ubuntu-16_04/swift/test/SourceKit/CursorInfo/cursor_no_cancel.swift:19:11: error: expected string not found in input // CHECK: source.lang.swift.decl.function.free ^ :1:1: note: scanni

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

Just looking into it now, was in the migration fest. > On May 16, 2017, at 14:09, Michael Ilseman wrote: > > Jordan, are you currently tracking this? > > Script: > -- > rm -rf > /Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64/t

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

I merged the Clang half of this to the wrong branch. Sorry! Should be fixed now. Jordan > On May 15, 2017, at 11:04, no-re...@swift.org wrote: > > [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_10 [#478] > > Build URL: > https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-u

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

I think they'll all be IsPatterns, which means you can look at the CheckedCastKind. Jordan > On May 9, 2017, at 13:54, Robert Widmann wrote: > > Is there a catch-all to query for such casts (sorry, I'm away from my > computer at the moment). > > ~Robert Widmann > > 2017/05/09 16:40、Jordan

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

I think any bridging conversion or upcast would count. enum Foo { case foo(NSFileManager) case bar(NSString) case baz(Int) } func test(x: Foo) { switch x { case .foo(let obj as NSObject): print("totally legal") case .bar(let obj as String): print("also cool") case .baz(let ob

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

"as NSError" isn't a tautology, though—the original type is 'Error'. Additionally, the presence or absence of a warning shouldn't affect exhaustiveness analysis, which is currently an error when you get it wrong. Warnings are things you can build with and fix later. Jordan > On May 9, 2017, a

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

It's neither a variable binding nor an expression pattern, right? It has to be compared against the original type to know whether it's exhaustive or not. (Consider "let error as NSError" in a catch clause, which should be considered exhaustive.) Jordan > On May 9, 2017, at 11:12, Robert Widman

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

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

[swift-dev] Fixing 'Identifier' with 'DeclBaseName'

Hi, all. I wanted to give a heads-up about some work Alex Hoppen has been doing to fix one of our longstanding problems: the DeclName for subscripts is just the Identifier “subscript”. (And similarly for ‘init’, ‘deinit’, etc.) The solution he’s come up with (after discussions with me and John)

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

> On Apr 28, 2017, at 16:28, John McCall via swift-users > wrote: > >> On Apr 28, 2017, at 7:03 AM, Johannes Weiss via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> Hi swift-users, >> >> (sorry for the cross post to swift-dev, but wasn't sure where it belongs) >> >> I tried to find gua

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

I don’t think that’s any of us. Philippe, does this look familiar? [ RUN ] TestCharacterSet.test_moreSetOperations stdout>>> check failed at /Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/swift/test/stdlib/TestCharacterSet.swift, line 292 stdout>>> unexpected value: ""

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

I believe these are interposition points for things like dtrace, and also useful for Roman's experiments with nonatomic retain counting. Roman, do you know? (JoeG would know too but he's on vacation.) Jordan > On Apr 24, 2017, at 17:15, Slava Pestov via swift-dev > wrote: > > Hi all, > >

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

This needs a clean build after my commits. I didn't manage to find what the missing dependency was, sorry. > On Apr 24, 2017, at 11:24, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#9603] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9603/ >

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

> On Apr 20, 2017, at 18:25, Michael Ilseman wrote: > >> >> On Apr 20, 2017, at 4:55 PM, Jordan Rose via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> TLDR: Should we just always import C/ObjC types under their Swift 4 name

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

t; > @availability(swift, obsoleted: 4.0) > typealias NSNotification.Name = Notification.Identifier > > To prevent source compatibility issues? > >> On Apr 20, 2017, at 16:55, Jordan Rose via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> TLDR:

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

> On Apr 20, 2017, at 16:55, Jordan Rose via swift-dev > wrote: > > TLDR: Should we just always import C/ObjC types under their Swift 4 names, > and use typealiases in Swift 3 mode? > > --- > > Hi, swift-dev. As my recent PRs have probably indicated, I've

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

TLDR: Should we just always import C/ObjC types under their Swift 4 names, and use typealiases in Swift 3 mode? --- Hi, swift-dev. As my recent PRs have probably indicated, I've been working on the problems that can come up when mixing Swift 3 and Swift 4 code. Most of these problems have to d

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

TEST 'Swift-Unit :: runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata' FAILED /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/unittests/runtime/Metadata.cpp:462: Failure Expected: ab Which is: 0x

Re: [swift-dev] Unexpected Expr type

Hi, Halen. Welcome to the compiler. :-) What you're seeing is that we don't usually use C++'s normal RTTI mechanism, but instead go with a "Kind" field that's checked by the custom 'cast', 'dyn_cast', and 'isa' functions. (More informati

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

Erik may have beat you to it. https://github.com/apple/swift/pull/8595 Jordan > On Apr 6, 2017, at 15:18, mishal_shah via swift-dev > wrote: > > Looks like this was cherry-picked in swift-clang without PR testing. > > Thanks, > Mishal Shah >> On Apr

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

That was fast. Looks like the AST APIs I was using changed since yesterday. > On Apr 4, 2017, at 10:03, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#9209] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9209/ >

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

> Test Suite 'TestNSOrderedSet' started at 12:15:18.649 > Test Case 'TestNSOrderedSet.test_BasicConstruction' started at 12:15:18.649 > Test Case 'TestNSOrderedSet.test_BasicConstruction' passed (0.0 seconds) > Test Case 'TestNSOrderedSet.test_Enumeration' started at 12:15:18.649 > /home/buildnode/

[swift-dev] New conformances and source compatibility

Hi, everyone. I wanted to get some advice on an issue I've been worrying about: the effect of added conformances on source compatibility. Let's take my own (stale) PR as an example: #4568 makes all CF types Equatable and Hashable, using the functions CF

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

+DougC > On Mar 22, 2017, at 16:37, David Farler via swift-dev > wrote: > > Doesn't look like my change. Did tools or clang/llvm change? > >> On Mar 22, 2017, at 4:32 PM, no-re...@swift.org >> wrote: >> >> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#2

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

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

Re: [swift-dev] Statically-emitted or statically-allocated objects with new refcounting

> On Mar 14, 2017, at 13:52, Greg Parker via swift-dev > wrote: > > >> On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev > > wrote: >> >> >>> On Mar 14, 2017, at 12:43 PM, Joe Groff >> > wrote: >>> >>> Hey Greg, what are the correct

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

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

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

It's sporadic. We've been mostly unable to reproduce it on demand and aren't yet sure why it occurs. Hopefully this week we'll get it! Jordan > On Feb 26, 2017, at 22:54, Andrew Trick via swift-dev > wrote: > > Building CoreAudio on armv7k: > > (dependent_member_type assoc_type=Swift.(file).

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

Ahmed, I suspect this is just LLVM and Clang getting out of sync, and the next build should pass? /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:278:45: error: no type named 'DiagnosticInfoWithDebugLocBase' i

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

Doug? > On Feb 23, 2017, at 15:05, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#8539] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/8539/ > > Project: oss-swift-incremental-RA-

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

> > 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 > <mailto:swift-dev@swift.org>> wrote: >> >> Foun

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

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

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

I'll XFAIL it for you for now. > On Feb 20, 2017, at 10:19, David Farler wrote: > > Ah, NoAsserts builds, of course. The test checks for assertion failure :). I > will fix it up. I am AFK until after lunch - is it ok to wait until then? > > David > > On Feb 20, 2017, at 10:00 AM, Jordan Rose

  1   2   3   >