Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

> On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev > wrote: > > - Does this help us with the nested dictionary CoW problem? > `foo["bar"]["baz"] += 1` My understanding is that this problem arises because we don’t have ‘optional addressors’. A dictionary lookup might return nil. If addr

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

https://bugs.swift.org/browse/SR-3110 [TEST] Dispatch Suspend Timer ... [BEGIN] tweedledee tick count Actual: 8 Expected: 7 [FAIL] tweedledee tick count (dispatch_suspend_timer.c:96) dispatch_suspend_timer.c:96 > On Nov 1, 2016, at 5:53 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-3.0-

Re: [swift-dev] SE-0047 - Defaulting non-Void functions so they warn on unused results

I agree that "_ =" is nicer than "(void)". > Do you find yourself writing a lot of functions that return non-void results that you frequently want to ignore? Maybe there's some idiom we could do a better job of recognizing. It really depends on the developer. Some will add return values thinking

Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

> On Oct 31, 2016, at 12:22 PM, Joe Groff via swift-dev > wrote: > We currently abstract over mutable property accesses using what I’ll call a > continuation-based model–the materializeForSet accessor is called before an > inout access, and returns a continuation callback that must be called wh

Re: [swift-dev] Inability to leverage privacy in the stdlib

The problem is if a private type or function X is referenced from a function Y with a serialized body, then if Y is inlined inside of another module, it cannot see the symbol for X. The solution is to disable -sil-seiralize-all and replace it with an explicit ‘fragile’ attribute that is put on c

Re: [swift-dev] [swift-lldb-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (swift 3.0) #142

Thanks! > On Nov 1, 2016, at 12:14 PM, Todd Fiala wrote: > > Comments in the bug. I have a candidate fix that I put in upstream in > LLVM.org LLDB svn trunk. > > I’ll pull that through after I get the current merge settled. > >> On Nov 1, 2016, at 11:21 AM, mishal_shah via

Re: [swift-dev] [swift-lldb-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (swift 3.0) #142

Comments in the bug. I have a candidate fix that I put in upstream in LLVM.org LLDB svn trunk. I’ll pull that through after I get the current merge settled. > On Nov 1, 2016, at 11:21 AM, mishal_shah via swift-lldb-dev > wrote: > > https://bugs.swift.org/browse/SR-3103

Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

> On Nov 1, 2016, at 11:00 AM, Jordan Rose wrote: > > I like the idea; it makes more sense to me than our current model (which > feels more like a plain callback than a continuation to me). Some things that > occurred to me when reading this: > > - This seems like it'll be much simpler to che

Re: [swift-dev] Inability to leverage privacy in the stdlib

on Tue Nov 01 2016, Alexis wrote: > Hmm, I excitedly prototyped out refactoring HashedCollections to > properly use privacy and decent naming since I’m clobbering the whole > file with the new indexing stuff anyway. Unfortunately I hit a linker > error. I can’t seem to produce a reduced test cas

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (swift 3.0) #142

https://bugs.swift.org/browse/SR-3103 > On Nov 1, 2016, at 11:17 AM, mishal_shah via swift-dev > wrote: > > FAIL: test_attach_to_process_by_name_dwarf > (functionalities/process_attach/TestProcessAttach.py) > > [TestProcessAttach.py FAILED] > Command invoked: /usr/bin/python > /home/buildnod

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (swift 3.0) #142

FAIL: test_attach_to_process_by_name_dwarf (functionalities/process_attach/TestProcessAttach.py) [TestProcessAttach.py FAILED] Command invoked: /usr/bin/python /home/buildnode/jenkins/workspace/oss-swift-3.0-package-linux-ubuntu-15_10/lldb/test/dotest.py --executable /home/buildnode/jenkins/wo

Re: [swift-dev] Inability to leverage privacy in the stdlib

Hmm, I excitedly prototyped out refactoring HashedCollections to properly use privacy and decent naming since I’m clobbering the whole file with the new indexing stuff anyway. Unfortunately I hit a linker error. I can’t seem to produce a reduced test case. Making similar but smaller changes to o

Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

I like the idea; it makes more sense to me than our current model (which feels more like a plain callback than a continuation to me). Some things that occurred to me when reading this: - This seems like it'll be much simpler to check for invalid concurrent access to the same location (inout vio

Re: [swift-dev] Inability to leverage privacy in the stdlib

I made a PR with some basic privacy usage for Array, and everything seems to be working on OSX, but not Linux. https://github.com/apple/swift/pull/5573 Exit Code: 1 Command Output (stderr): -- /usr/bin/ld.gold: error: /home/buildnode/jenkins/workspa