from:"Andrew Trick via swift\-dev"

[swift-dev] @_specialize attribute

2016-03-19 Thread Andrew Trick via swift-dev

I'd like to let people know that I'm introducing an @_specialize(...)
function attribute. See https://github.com/apple/swift/pull/1725 
.
Feedback is welcome. Just keep in mind that for now this is only an
internal attribute. It is not yet a language change and has no impact
on API. The intention of this work is to provide an underlying capability
that we can build on in several ways (see below).


An internal @_specialize function attribute allows devlopers to force
full specialization by listing concrete type names corresonding to the
function's generic signature. A function's generic signature is a
concatenation of its generic context and the function's own generic
type parameters.::

  struct S {
var x: T
@_specialize(Int, Float)
mutating func exchangeSecond(u: U, _ t: T) -> (U, T) {
  x = t
  return (u, x)
}
  }

  // Substitutes:  with  producing:
  // S::exchangeSecond(u: Float, t: Int) -> (Float, Int)

@_specialize currently acts as a hint to the optimizer, which
generates type checks and code to dispatch to the specialized routine
without affecting the signature of the generic function. The
intention is to support efforts at evaluating the performance of
specialized code. The performance impact is not guaranteed and is
likely to change with the optimizer. This attribute should only be
used in conjunction with rigorous performance analysis. Eventually,
a similar attribute could be defined in the language, allowing it to be
exposed as part of a function's API. That would allow direct dispatch
to specialized code without type checks, even across modules.


In the future, we can build on this work in several ways:
- cross module dispatch directly to specialized code
- dynamic dispatch directly to specialized code
- automated specialization based on broader hints
- partial specialization
- and so on…

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

Re: [swift-dev] [WIP] New pull request triggers

2016-03-23 Thread Andrew Trick via swift-dev


> On Mar 23, 2016, at 4:26 PM, Mishal Shah via swift-dev  
> wrote:
> 
> I am currently working on adding new pull request triggers to ci.swift.org 
> , you might have already seen few of them as we test 
> them out. 

This is really exciting...

> Following phrases for apple/swift.git will be added:
> 
> Benchmark
> Phrase: @swift-ci Please benchmark 
> Description: Benchmark job will compare the results between targeted branch 
> and pull request. 
> Build config: swift/utils/build-script -R --no-assertions --benchmark
> 
> Test and merge
> Phrase: @swift-ci Please test and merge
> Description: Test and merge job will run tests on Ubuntu 14.04 and OS X 
> platform and merge the pull request if all of the tests pass.
> Build config: 
>   OS X: swift/utils/build-script 
> --preset=buildbot_all_platforms,tools=RA,stdlib=RA
>   Linux: swift/utils/build-script --preset=buildbot_linux_1404 
> install_destdir="${SWIFT_INSTALL_DIR}" 
> installable_package="${SWIFT_INSTALLABLE_PACKAGE}”
> 
> Smoke test and merge
> Phrase: @swift-ci Please smoke test and merge
> Description: Smoke Test and merge job will run limited tests on Ubuntu 14.04 
> and OS X platform and merge the pull request if all of the tests pass.
> Build config: 
>   OS X: swift/utils/build-script 
> --preset=buildbot_all_platforms,tools=RA,stdlib=RA
>   Linux: swift/utils/build-script --preset=buildbot_linux_1404 
> install_destdir="${SWIFT_INSTALL_DIR}" 
> installable_package="${SWIFT_INSTALLABLE_PACKAGE}”

This is the same build-script invocation as non-smoke testing. How can we 
reproduce each of the test configurations locally? Can we reveal that 
information on ci.swift.org  just like the build config?

Will the smoke tests cover everything run by the incremental builders?

> ASAN Testing
> Phrase: @swift-ci Please ASAN test
> Description: ASAN testing job 
> Build config: swift/utils/build-script" 
> --preset=buildbot_incremental_asan,tools=RDA,stdlib=RDA
> 
> Python Lint
> Phrase: @swift-ci Please Python lint 
> Description: Python lint using pep8 rules
> Build config: flake8 | cut -f4- -d: | sort | uniq -c
> 
> These new triggers are a work in progress, I will send out another email once 
> they are available for use.

Great. Please make all of this information visible on ci.swift.org 
, or link directly to the swift.org  
pages that have the info.

Andy

> 
> Please let me know if you have any feedback. 
> 
> Thanks,
> Mishal Shah
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] [WIP] New pull request triggers

2016-03-23 Thread Andrew Trick via swift-dev

> On Mar 23, 2016, at 5:21 PM, Mishal Shah  wrote:
> 
>> Will the smoke tests cover everything run by the incremental builders?
> It will be covered by preset buildbot_incremental,tools=RA,stdlib=RA
> 

Ok. That makes sense. I see that the build preset also invokes the tests, but 
that the incremental build (smoke test) skips all device testing, while the 
normal build runs the simulator.

Thanks for explaining.

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

Re: [swift-dev] isUniquelyReferenced issues

2016-04-01 Thread Andrew Trick via swift-dev


> On Apr 1, 2016, at 8:43 AM, Joe Groff via swift-dev  
> wrote:
> 
> 
>> On Mar 31, 2016, at 11:49 PM, Patrick Pijnappel  
>> wrote:
>> 
>> The modified version doesn't seem to change any of the results (on -O or 
>> -Onone). Note that the problem is that it's not uniquely referenced inside 
>> bar where it actually should be – that would mean that ownership is 
>> currently not directly transferred right?
> 
> You're right, I'm sorry, I misread your original comment. If the ARC 
> optimizer didn't transfer ownership, then it is correct for 
> `isUniquelyReferenced` to be false inside `bar`, since the `foo` inside of 
> `test` and the `foo` parameter to `bar` are semantically independent values. 
> If this weren't the case, then `bar` could modify a COW value type and have 
> its changes be seen back in `test`'s copy.

In other words, to avoid a copy, the COW value must be passed ‘inout’. This is 
normally true anyway for functions that mutate the value.

It would be neat to have a ‘move’ operator that handed ownership of the COW 
value off to the callee. But the memory safety of that would be problematic in 
general.

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

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

2016-05-12 Thread Andrew Trick via swift-dev


> On May 12, 2016, at 9:27 AM, Jordan Rose  wrote:
> 
> On the model itself:

Responding to your feedback on the model (thanks!). 
https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst 

With just one follow up question at the bottom of this email…

> - "thin function, C function, and block function types” <-- block functions 
> are not layout-compatible with C functions, and they are layout-compatible 
> with AnyObject. (I mean, they’re both pointers at the moment, but so are 
> non-weak object references.)

   - pointer types (e.g. ``OpaquePointer``, ``UnsafePointer``)
-  - thin function, C function, and block function types
+  - block function types and ``AnyObject``
+  - thin function and C function types
   - imported C types that have the same layout in C

> - "nonresilient structs” <-- nitpick: the term “nonresilient” is not defined 
> here, and isn’t a formal term in the Library Evolution doc. I guess I would 
> actually prefer “fragile” if you needed a generic term across structs and 
> enums, but either way you should put a small definition somewhere in this doc.

   - imported C types that have the same layout in C
-  - nonresilient structs with one stored property and their stored
+  - fragile structs with one stored property and their stored
 property type
-  - nonresilient enums with one case and their payload type
+  - fragile enums with one case and their payload type
 
 .. note::
 
-   `Library Evolution Support in Swift`__
+   "Fragile" enums and structs have strict layout rules that ensure
+   binary compatibility. `Library Evolution Support in Swift`__
explains the impact of resilience on object layout.

> - "homogeneous tuples, fixed-sized array storage, and homogeneous 
> nonresilient structs in which the element type has no spare bits (structs may 
> be bit packed).” <-- I would leave the structs out of this, even if it’s 
> true. Also, Swift doesn’t have fixed-size arrays at the moment, right?

Hmm, I think we want to say that raw allocated memory, arrays, homogeneous 
tuples and structs are layout compatible with 'strideof'. I'll leave out 
structs for now and this can be hashed out in ABI specs. I want to avoid naming 
specific API's and I think it's ok to be a bit vague in this (non-ABI) document 
as long as the intent is obvious:

  - contiguous array storage and homogeneous tuples which 
have the same number and type of elements.

> - "In particular, they apply to access that originates from stored property 
> getter and setters, reading from and assigning into inout variables, and 
> reading or assigning subscripts (including the Unsafe[Mutable]Pointer pointee 
> property and subscripts).” I’m unhappy with inout variables being called out 
> specially here. An inout variable should be exactly like a local variable 
> that happens to be stack-allocated, rather than just in registers. Closure 
> captures probably figure in here too.

Agreed. I'm not sure what I was thinking.

> - "unsafeBitCast is valid for pointer to integer conversions” <-- we have 
> better APIs to do this now ('init(bitPattern:)’ in both directions).

+``unsafeBitCast`` should generally be avoided on pointer types,
+particularly class types. For pointer to integer conversions,
+``bitPattern`` initializers are available in both
+directions. ``unsafeBitCast`` may be used to convert between
+nondereferenceable pointer types, but as with any conversion to and
+from opaque pointers, this presents an opportunity for type punning
+when converting back to a dereferenceable pointer type.

> - "It is also used internally to convert between nondereferenceable pointer 
> types, which avoids the need to add builtin conversions for all combinations 
> of pointer types.” <-- I’d be happy to get rid of this and just go through 
> Builtin.RawPointer when necessary.

...I do like to get feedback that eliminating unsafeBitCast is a good thing. I 
think it should only be needed for genuine reinterpretation of the bits as 
opposed working around the type system. I'd like to see only a tiny handful of 
occurrences in stdlib. I have a branch where I've cleaned up many 
unsafeBitCasts, which never got checked in, so I can spend some time on that 
again after UnsafePointer changes land. Then maybe we should prohibit it from 
being called on certain pointer types. For starters AnyObject, UnsafePointer, 
and UnsafeBytePointer.

> - On the flip side, I think we do need to preserve the ability to 
> reference-cast in order to send Objective-C messages, at least for now. I 
> don’t know how I want to expose that to users, though. (In general it’s 
> probably worth seeing how unsafeBitCast is used in the wild and what we’d 
> recommend instead.)

Does ``X as Y`` fail for some reason? We have unchecked versions of ``X as Y`` 
for performance reasons: ``unsafeDowncast`` and ``_unsafeReferenceCast``.

-Andy

___

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

2016-05-12 Thread Andrew Trick via swift-dev

> On May 12, 2016, at 9:27 AM, Jordan Rose  wrote:
> 
> Thoughts on the diff:

https://github.com/atrick/swift/tree/unsafeptr_convert 

> - What was the thought behind putting UnsafeBytePointer in PointerTypeKind? 
> OpaquePointer isn’t there, and I’m concerned about places that test if 
> something’s a pointer by checking that the pointee type is non-null (by far 
> the common pattern).

In general I wanted UnsafeBytePointer to stand-in for UnsafePointer 
throughout the type system and handle most of the same implicit conversions. 
Specifically, I wanted getAnyPointerElementType to do the same thing as 
UnsafePointer and return an empty tuple pointee type so that the calling 
code could be reused. Also, I thought that supporting PointerToPointerExpr was 
necessary.

The only extra burden of doing this that I could find was that 
getPointerPointeePropertyDecl may return null. The only code that calls this is 
emitStoreToForeignErrorSlot.

I'm very open to alternate implementations, especially once the proposal is 
accepted.

> - The PrintAsObjC test can’t possibly pass as is—it’s checking that one 
> pointer is const and the other isn’t. I’m guessing there’s actually more work 
> to do here.

That's right. PrintAsObjC is one of several tests that are still failing. 
Before fixing them I want to:

- get reassurance that we really want to replace the the imported type of 
'void*'. Then I'll introduce an UnsafeMutableBytePointer.

- determine precisely which implicit conversions we want to allow and update 
test cases accordingly.

These are the tests that were failing on my branch (last time I succesfully 
rebased):

POSIX.swift - requires String -> UnsafeBytePointer arg conversion
UnsafeBufferPointer.swift - UnsafePointer conversion rules?
UnsafePointer.swift - UnsafePointer conversion rules?
ClangModules/* - UnsafePointer conversion rules?
IRGen/objc_pointer - name mangling
SDK/c_pointers - [Double] to UnsafeBytePointer
SDK/objc_inner_pointer - [UInt8] to UnsafeBytePointer
Parse/pointer_conversion - 'UnsafePointer' to 'UnsafeBytePointer'
PrintAsObjC/classes.swift - void* export
SILGen/objc_currying - name mangling
SILGen/pointer_conversion - String to UnsafeBytePointer
SourceKit/DocSupport - formatting
sil-opt/emit-sib. - mangling
OpenCLSDKOverlay - [Float] to UnsafeBytePointer

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

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

2016-05-13 Thread Andrew Trick via swift-dev


> On May 12, 2016, at 4:03 PM, John McCall via swift-dev  
> wrote:
> 
>> On May 12, 2016, at 3:21 PM, Joe Groff  wrote:
>>> On May 12, 2016, at 11:21 AM, John McCall  wrote:
>>> 
 On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev 
  wrote:
> On May 12, 2016, at 10:44, Joe Groff  wrote:
> 
> 
>> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev 
>>  wrote:
>> 
>> 
>> - I’m uncomfortable with using the term “undefined behavior” as if it’s 
>> universally understood. Up until now we haven't formally had that notion 
>> in Swift, just “type safety” and “memory safety” and 
>> “invariant-preserving” and the like. Maybe we need it now, but I think 
>> it needs to be explicitly defined. (I’d actually talk to Dave about 
>> exactly what terms make the most sense for users.)
> 
> We do have undefined behavior, and use that term in the standard library 
> docs where appropriate:
> 
> stdlib/public/core/Optional.swift-  /// `!` (forced unwrap) operator. 
> However, in optimized builds (`-O`), no
> stdlib/public/core/Optional.swift-  /// check is performed to ensure that 
> the current instance actually has a
> stdlib/public/core/Optional.swift-  /// value. Accessing this property in 
> the case of a `nil` value is a serious
> stdlib/public/core/Optional.swift:  /// programming error and could lead 
> to undefined behavior or a runtime
> stdlib/public/core/Optional.swift-  /// error.
> stdlib/public/core/Optional.swift-  ///
> stdlib/public/core/Optional.swift-  /// In debug builds (`-Onone`), the 
> `unsafelyUnwrapped` property has the same
> --
> stdlib/public/core/StringBridge.swift-  /// The caller of this function 
> guarantees that the closure 'body' does not
> stdlib/public/core/StringBridge.swift-  /// escape the object referenced 
> by the opaque pointer passed to it or
> stdlib/public/core/StringBridge.swift-  /// anything transitively 
> reachable form this object. Doing so
> stdlib/public/core/StringBridge.swift:  /// will result in undefined 
> behavior.
> stdlib/public/core/StringBridge.swift-  
> @_semantics("self_no_escaping_closure")
> stdlib/public/core/StringBridge.swift-  func 
> _unsafeWithNotEscapedSelfPointer(
> stdlib/public/core/StringBridge.swift-_ body: @noescape 
> (OpaquePointer) throws -> Result
> --
> stdlib/public/core/Unmanaged.swift-  /// reference's lifetime fixed for 
> the duration of the
> stdlib/public/core/Unmanaged.swift-  /// '_withUnsafeGuaranteedRef' call.
> stdlib/public/core/Unmanaged.swift-  ///
> stdlib/public/core/Unmanaged.swift:  /// Violation of this will incur 
> undefined behavior.
> stdlib/public/core/Unmanaged.swift-  ///
> stdlib/public/core/Unmanaged.swift-  /// A lifetime of a reference 'the 
> instance' is fixed over a point in the
> stdlib/public/core/Unmanaged.swift-  /// programm if:
 
 Those latter two are in stdlib-internal declarations. I think I have the 
 same objection with using the term for 'unsafelyUnwrapped'.
>>> 
>>> Well, we can say "A program has undefined behavior if it does X or Y", or 
>>> we can say "A program which does X or Y lacks type safety". In all cases we 
>>> are referring to a concept defined elsewhere.  If we say "undefined 
>>> behavior", we are using an easily-googled term whose popular discussions 
>>> will quickly inform the reader of the consequences of the violation.  If we 
>>> say "type safety", we are using a term with that's popularly used in very 
>>> vague, hand-wavey ways and whose consequences aren't usually discussed 
>>> outside of formal contexts.  If we say "memory safety", we're using a term 
>>> that doesn't even have that precedent.  So we can use the latter two terms 
>>> if we want, but that just means we need to have a standard place where we 
>>> define them and describe the consequences of violating them, probably with 
>>> at least a footnote saying "this is analogous to the undefined behavior 
>>> rules of C and C++".
>> 
>> In other places where the standard library intentionally has undefined 
>> behavior, it looks like we use the term "serious programming error", for 
>> instance in the the doc comment for `assert`:
>> 
>> /// * In -Ounchecked builds, `condition` is not evaluated, but the
>> ///   optimizer may assume that it *would* evaluate to `true`. Failure
>> ///   to satisfy that assumption in -Ounchecked builds is a serious
>> ///   programming error.
>> 
>> which feels a bit colloquial to me, and doesn't provide much insight into 
>> the full consequences of UB. I think we're better off using an established 
>> term.
> 
> Agreed.
> 
> Do we have a good place to document common terms?  Preferably one that isn't 
> a book?
> 
> John.


Am I the only one who sees defining "undefined behavior" as a paradox?

I'm not disagreeing with better do

Re: [swift-dev] What do to when stdlib guidelines conflict with proposal?

2016-05-13 Thread Andrew Trick via swift-dev


> On May 12, 2016, at 9:57 PM, Chris Lattner via swift-dev 
>  wrote:
> 
> 
>> On May 12, 2016, at 9:16 PM, Russ Bishop > > wrote:
>> 
>> 
>>> On May 12, 2016, at 8:33 AM, Joe Groff >> > wrote:
>>> 
>>> We might want to wait till we review Andy's UnsafeBytePointer proposal. If 
>>> we accept that, it will separate UnsafePointer into its own type.
>>> 
>>> -Joe
>> 
>> 
>> Fair enough; I can hold off on this branch until then.
> 
> I’d suggest wrapping up this proposal as specified.  When/if Andy’s proposal 
> goes through, we can move these APIs over.  This proposal is progress from 
> the status quo, perfection is the enemy of good after all.

That’s the right call. For the record, I suggested moving to/fromOpaque to 
initializers during the community review and it was immediately shot down by 
Jordan because it’s incorrect for UnsafePointer where T is non-Void.

-Andy

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

Re: [swift-dev] Implementation of swift's value types

2016-07-14 Thread Andrew Trick via swift-dev


> On Jul 14, 2016, at 12:39 PM, Johannes Neubauer via swift-dev 
>  wrote:
> 
> Dear Devs,
> 
> I saw the WWDC 2016 video [Understanding Swift Performance][0] as well as 
> some others regarding value types in swift of WWDC2015. I think there are a 
> few ambiguities which make it hard both to decide which weapon to choose and 
> to give proposition how to evolve this implementations to the better 
> (swift-evolution).
> 
> Is there a place, where low-level decisions in the language are documented? 
> Is there an adequate place/forum where we can ask questions regarding 
> low-level implementations? It would be great if you add a (moderated) comment 
> section to each of the WWDC videos, so that we can discuss the contents (with 
> transcript-like links) as well as an errata section containing a list of 
> Apple-Approved mistakes/ambiguities in a given video/talk.
> 
> # So, here come my questions
> 
> In the talk [Understanding Swift Performance][0] Kyle says, that value types 
> are put stored in the stack and copied. He uses a point and a line which are 
> both copied. Lateron Arnold uses a similar example with protocols. Then the 
> Existential Container is used, which either uses the value buffer (for small 
> values like `Point`) or allocates some memory on the heap and adds a pointer 
> to this value (e.g. for a `Line`):
> 
> 1. If I have an object (instance of a class) in a variable (or a container 
> like an array) of a protocol type, will it be stored into an Existential 
> Container, too? Or are reference types always stored as a reference (storing 
> it in an Existential Container makes more sense to me).

In that case the value stored in the existential container is just the 
reference. There’s no additional heap allocation.

Promoting objects to the stack is a separate thing that I think will only 
happen if the existential container is already optimized away.

> 2. If I use a variable of the concrete type (although it implements a 
> protocol), will it always be copied (no matter its size) or does the compiler 
> choose an existential container if it is greater than some given size (or 
> perhaps even always, because it gives a good tradeoff?)

A value's representation starts off as the representation for whatever type is 
in the declaration. For something declared as a struct, it’s irrelevant whether 
the type also conforms to a protocol. We don’t yet provide a language feature 
or optimization for indirect copy-on-write struct storage.

> 3. Then Arnold says that four existential containers pointing to the same 
> value (greater than the value buffer) use 4 heap allocations. He proposes 
> copy-on-write (using a local storage class), but **does he mean this should 
> be implemented by hand or is this an optimization that the swift compiler 
> does on its own?** The issue here is, that the switch between "swift 
> subscript" for showing an abstraction of internals and real swift code that 
> one should write is sometimes not clear. Doing this by hand has some clear 
> disadvantages as this would add a reference to each usage of `Line` (and 
> reference counting) even in the first examples of Kyle. Doing this as a 
> compiler optimization would allow to use a struct in different scenarios and 
> always the best tradeoff is used. Otherwise, I would perhaps even need to 
> create two different types for different situations and choose it wisely. 
> This would add a big burden on the developer.

It needs be done by hand because the compiler doesn’t do it. The compiler 
*should* do it in the sense that it would make the world a better place.

> 4. If Arnold really means *manually* (see *3.*) and reference types are not 
> stored in existential containers (see *1.*) the slides are wrong, because 
> there a existential container is still used and the instance on the heap is 
> named `Line` instead of `Line._storage`. So what is the case?

I don’t have the slides in front of me, but the instance is always on the heap 
(modulo stack promotion, which doesn’t happen for existentials). The reference 
to the instance is in the container.

> 5. The implementations of `String` and `Array` seem to follow the 
> copy-on-write strategy "manually", but I think they do that because this 
> behavior is wanted even if the values would be copied automatically (if this 
> is true, the answer for *3.* would be *manually*). Or am I wrong here?

There’s no observable behavior to copy-on-write other than the program running 
much faster.

> 6. Is the Value-Witness-Table a (kind of) dictionary for all values of a 
> given value type (bigger than the value buffer), so that you do not store any 
> value twice on the heap, but share the reference? If this is the case the 
> answer of *3.* should be *automatically*. But then again, the "manual" 
> implementation of `String` and `Array` (see *4.*) make no sense anymore, does 
> it? Or are `Array` and `String` implemented only on the lower-level and the 
> copy-on-write imp

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

2016-07-15 Thread Andrew Trick via swift-dev

Does anyone have permission to clear this workspace? If I don’t hear back soon 
I’ll probably have to make a dummy checkin the overlay…

-Andy

> On Jul 15, 2016, at 1:54 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-osx [#5225]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5225/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Fri, 15 Jul 2016 13:49:37 -0700
> Build duration:   4 min 57 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 
> 
> Changes
> 
> Commit 5008f4de3f3a35aaa848862b0f7ad329d68cd1de by atrick:
> Change the SIL Module Format version.
> 
> edit: include/swift/Serialization/ModuleFormat.h

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

Re: [swift-dev] Implementation of swift's value types

2016-07-15 Thread Andrew Trick via swift-dev


> On Jul 15, 2016, at 9:25 AM, Johannes Neubauer via swift-dev 
>  wrote:
> 
> Is there some documentation of the current implementation of Existential 
> Container, Protocol Witness Table, and co.? Where do I find it?

Arnold’s slides are the best I’ve seen!

There are some internal details here:
https://github.com/apple/swift/blob/master/docs/SIL.rst
https://github.com/apple/swift/blob/master/docs/ABI.rst 


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

[swift-dev] 1_stdlib/NSSetAPI.swift fails verifying open archetypes

2016-07-16 Thread Andrew Trick via swift-dev

Roman,

This has been failing since July 14 (although the most recent build hit a 
linker error first). Do you want to try fixing it or can you revert?

1_stdlib/NSSetAPI.swift
SIL verification failed: Opened archetype should be registered in SILFunction: 
Def

https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RDA_test-simulator/1714/changes#ae8b2ba0ded42cdf9c2f4e1d0bd38d2a2f3ea8eb

1.  While verifying SIL function 
@_TTSf4g_g___TF4mainP33_686502F7DC72AADE8272815984E17B6D20compareAnythingAtAllFTPs9AnyObject_1yPS0___O14StdlibUnittest24ExpectedComparisonResult
 for 'compareAnythingAtAll' at 
/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-simulator/swift/test/1_stdlib/NSSetAPI.swift:18:9

 TEST 'Swift :: 1_stdlib/NSSetAPI.swift' FAILED 

Script:
--
rm -rf 
/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-simulator/Ninja-ReleaseAssert/swift-macosx-x86_64/test-macosx-x86_64/1_stdlib/Output/NSSetAPI.swift.tmp
 && mkdir -p 
/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-simulator/Ninja-ReleaseAssert/swift-macosx-x86_64/test-macosx-x86_64/1_stdlib/Output/NSSetAPI.swift.tmp
 && xcrun --toolchain default --sdk 
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
 
/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-simulator/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc
 -target x86_64-apple-macosx10.9  -module-cache-path 
'/var/folders/_8/79jmzf2142z2xydc_01btlx0gn/T/swift-testsuite-clang-module-cacheWJ4Hcy'
 -F 
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/../../../Developer/Library/Frameworks
 -Xlinker -rpath -Xlinker 
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/../../../Developer/Library/Frameworks
   -O -module-cache-path 
'/var/folders/_8/79jmzf2142z2xydc_01btlx0gn/T/swift-testsuite-clang-module-cacheWJ4Hcy'
 
/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-simulator/swift/test/1_stdlib/NSSetAPI.swift
 -o 
/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-simulator/Ninja-ReleaseAssert/swift-macosx-x86_64/test-macosx-x86_64/1_stdlib/Output/NSSetAPI.swift.tmp/a.out
 -module-name main &&  
/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-simulator/Ninja-ReleaseAssert/swift-macosx-x86_64/test-macosx-x86_64/1_stdlib/Output/NSSetAPI.swift.tmp/a.out

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

[swift-dev] OSS Swift CI, test-simulator fails to build

2016-07-16 Thread Andrew Trick via swift-dev

Can someone figure out why this bot is failing to build now?

https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RDA_test-simulator/1737/consoleFull#-1586822805ee1a197b-acac-4b17-83cf-a53b95139a76

ld: library not found for -lswiftCoreMedia for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

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

[swift-dev] swift-ci broken

2016-07-18 Thread Andrew Trick via swift-dev

The swift-ci tests have been regularly failing for the past several days. That 
makes it impossible to make progress for anyone who is trying to gate their own 
changes on pull request testing or even rely on local testing on trunk.

I thunk swift-ci would work if everyone followed some minimal standards for 
pre-commit testing:

- To commit anything nontrivial, use a pull request with @swift-ci Please smoke 
test and merge

- If your change is source breaking or may require updates in other 
repositories, run "utils/build-toolchain local.swift” on linux and darwin. All 
tests should pass and it should generate a tarball. Then use a pull request and 
merge all affected repositories at once.

- Watch the bots after you merge. Revert your change if anything breaks.

Andy

Current swift-ci incremental status:

> linux:
> 
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6593/consoleFull#-1843642957ee1a197b-acac-4b17-83cf-a53b95139a76
> 
> TestFoundation/TestNSString.swift:1094:56: error: incorrect argument label in 
> call (have 'with:isEquivalent:', expected 'with:by:')
>let expectHasPrefix = lhsNFDGraphemeClusters.starts(
>   ^
> TestFoundation/TestNSString.swift:1097:54: error: incorrect argument label in 
> call (have 'with:isEquivalent:', expected 'with:by:')
>lhsNFDGraphemeClusters.lazy.reversed().starts(
> ^
> ---
> darwin:
> 
> https://ci.swift.org/job/oss-swift-incremental-RA-osx/5294/consoleFull#-115900982ee1a197b-acac-4b17-83cf-a53b95139a76
> 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swift/stdlib/private/StdlibUnittestFoundationExtras/StdlibUnittestFoundationExtras.swift:71:19:
>  error: missing argument label 'invoking:' in call
>  autoreleasepool(body)
>  ^
>  invoking: 
> 

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

[swift-dev] Reflection/typeref_lowering.swift' FAILED (but not on Swift CI)

2016-07-21 Thread Andrew Trick via swift-dev

Has anyone else seen this failure on darwin building the latest github/master?
commit d78012b03feaa5c946fd7d5254ff9492457f1874 (HEAD -> master, public/master)

 TEST 'Swift :: Reflection/typeref_lowering.swift' FAILED 

/s/sptr/swift/test/Reflection/typeref_lowering.swift:690:19: error: expected 
string not found in input
// CHECK-64-NEXT: (struct size=81 alignment=8 stride=88 num_extra_inhabitants=0
  ^
:331:1: note: scanning from here
(struct size=0 alignment=1 stride=0 num_extra_inhabitants=0)
^

For some reason, reflection thinks this struct is empty. I've quadruple checked 
that my repo is clean and rebuilt a number of times, so I'm curious if anyone 
else has run into it.

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

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

2016-07-22 Thread Andrew Trick via swift-dev

Slava,

This started failing after your commit:
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6699/ 


Andy

> On Jul 22, 2016, at 4:15 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6702]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6702/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Fri, 22 Jul 2016 16:03:43 -0700
> Build duration:   12 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 1 test(s), Passed: 8142 test(s), Total: 8143 test(s)
> Failed: Swift(linux-x86_64).SILOptimizer.swap_refcnt.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit d4660ad85a416bc6fffe4c7857299b2184529721 by atrick:
> side-effect.sil: Fix a recent bad merge.
> 
> edit: test/SILOptimizer/side-effect.sil
> 
> Commit 0ac23f8a6109c2cbf2a54f3439218e48c3339626 by daniel_dunbar:
> [Utility] Eliminate hacks for checking `git` version.
> 
> edit: Sources/Utility/Git.swift
> 
> Commit e9f297391216522251a353510afc1562962477ef by daniel_dunbar:
> [SourceControl] Add Repository.resolveRevision(tag:).
> 
> edit: Tests/SourceControl/GitRepositoryTests.swift
> edit: Sources/SourceControl/GitRepository.swift
> edit: Sources/SourceControl/Repository.swift

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

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

2016-07-22 Thread Andrew Trick via swift-dev

I disabled the test and filed:
 SILOptimizer/swap_refcnt.swift failes after noreturn 
-> Never changes

-Andy

> On Jul 22, 2016, at 4:27 PM, Andrew Trick via swift-dev  
> wrote:
> 
> Slava,
> 
> This started failing after your commit:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6699/ 
> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6699/>
> 
> Andy
> 
>> On Jul 22, 2016, at 4:15 PM, no-re...@swift.org <mailto:no-re...@swift.org> 
>> wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6702]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6702/ 
>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6702/>
>> Project: oss-swift-incremental-RA-linux-ubuntu-15_10
>> Date of build:   Fri, 22 Jul 2016 16:03:43 -0700
>> Build duration:  12 min
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> <https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-15_10/6702/consoleFull#-297412617ee1a197b-acac-4b17-83cf-a53b95139a76>
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all errors:
>> Indication 1 
>> <https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-15_10/6702/consoleFull#-1950109000fca400bf-2f4a-462e-b517-e058d770b2d7>
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 1 test(s), Passed: 8142 test(s), Total: 8143 test(s)
>> Failed: Swift(linux-x86_64).SILOptimizer.swap_refcnt.swift 
>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6702/testReport/junit/Swift(linux-x86_64)/SILOptimizer/swap_refcnt_swift>
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
>> 
>> Changes
>> 
>> Commit d4660ad85a416bc6fffe4c7857299b2184529721 by atrick:
>> side-effect.sil: Fix a recent bad merge.
>> 
>> edit: test/SILOptimizer/side-effect.sil
>> 
>> Commit 0ac23f8a6109c2cbf2a54f3439218e48c3339626 by daniel_dunbar:
>> [Utility] Eliminate hacks for checking `git` version.
>> 
>> edit: Sources/Utility/Git.swift
>> 
>> Commit e9f297391216522251a353510afc1562962477ef by daniel_dunbar:
>> [SourceControl] Add Repository.resolveRevision(tag:).
>> 
>> edit: Tests/SourceControl/GitRepositoryTests.swift
>> edit: Sources/SourceControl/GitRepository.swift
>> edit: Sources/SourceControl/Repository.swift
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

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

2016-07-23 Thread Andrew Trick via swift-dev

I reverted the test cases changes that caused this, so hopefully Swift CI will 
start to clear up.
-Andy

> On Jul 23, 2016, at 7:17 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-osx [#5442]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5442/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Sat, 23 Jul 2016 18:59:49 -0700
> Build duration:   17 min
> Identified problems:
> 
> Unexpected pass: This build failed because a test marked as XFAIL 
> unexpectedly passes. This could mean that the cause for the XFAIL is fixed, 
> but it warrants investigation in any case.
> Indication 1 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 1 test(s), Passed: 8160 test(s), Total: 8161 test(s)
> Failed: Swift(macosx-x86_64).SILOptimizer.swap_refcnt.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 273 test(s), Total: 273 test(s)
> 
> Changes
> 
> Commit cb508a8a562df7f9dc6f3b5e2e4fae9f14b803cb by anders:
> Move down `fopen()` from `Utility` to `Basic` and make it based on
> 
> add: Tests/Basic/Inputs/regular_text_file
> edit: Tests/Basic/PathShimTests.swift
> edit: Sources/PackageLoading/ManifestLoader.swift
> edit: Sources/Basic/PathShims.swift
> edit: Sources/Utility/Error.swift
> delete: Sources/Utility/File.swift
> edit: Sources/Commands/SwiftTestTool.swift
> edit: Sources/PackageLoading/ModuleMapGeneration.swift
> delete: Tests/Utility/Inputs/empty_file
> edit: Tests/Basic/XCTestManifests.swift
> add: Tests/Basic/Inputs/empty_file
> edit: Sources/Utility/PkgConfig.swift
> delete: Tests/Utility/Inputs/regular_text_file
> delete: Tests/Utility/FileTests.swift
> edit: Sources/SourceControl/CheckoutManager.swift
> 
> Commit 0e927519d4e4c5d005f2c3f36332bd2135c1 by anders:
> Fix Linux-specific build errors
> 
> edit: Sources/Basic/PathShims.swift
> edit: Tests/Utility/XCTestManifests.swift
> edit: Tests/Basic/PathShimTests.swift
> 
> Commit 72b8813a64ba5db154451c1f854719feb005aca3 by atrick:
> Restore operator '+' family for UnsafePointer. (#3719)
> 
> edit: test/1_stdlib/UnicodeScalarDiagnostics.swift
> edit: test/Constraints/bridging.swift
> edit: test/Constraints/diagnostics.swift
> edit: stdlib/public/core/UnsafePointer.swift.gyb
> edit: test/Constraints/closures.swift

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

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

2016-07-26 Thread Andrew Trick via swift-dev

/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swiftpm/Sources/Basic/OutputByteStream.swift:475:47:
 error: adjacent operators are in non-associative precedence group 
'DefaultPrecedence'
stream <<< Format.asJSON(key) <<< ":" <<< Format.asJSON(value)
  ^   ~~~
/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swiftpm/Sources/Basic/JSON.swift:139:24:
 error: adjacent operators are in non-associative precedence group 
'DefaultPrecedence'
stream <<< Format.asJSON(key) <<< ": " <<< contents[key]!
   ^  ~~~
/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swiftpm/Sources/Basic/JSON.swift:139:47:
 error: adjacent operators are in non-associative precedence group 
'DefaultPrecedence'
stream <<< Format.asJSON(key) <<< ": " <<< contents[key]!
  ^~~~

> On Jul 26, 2016, at 2:40 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#5502]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5502/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Tue, 26 Jul 2016 14:25:23 -0700
> Build duration:   15 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit 1621f7e0502e86a1a35dc3295f04d5a475222756 by mren:
> Modules: add command line option fmodules-disable-diagnostic-validation
> 
> edit: lib/Frontend/FrontendActions.cpp
> edit: include/clang/Serialization/ASTReader.h
> edit: test/Driver/modules.m
> edit: test/Modules/Inputs/module.map
> edit: include/clang/Driver/Options.td
> edit: include/clang/Lex/HeaderSearchOptions.h
> add: test/Modules/Inputs/DiagOutOfDate.h
> edit: lib/Frontend/CompilerInvocation.cpp
> add: test/Modules/diagnostic-options-out-of-date.m
> add: test/Modules/Inputs/pch-import-module-out-of-date.pch
> edit: lib/Serialization/ASTReader.cpp
> 
> Commit 0d90f01b7b53742a3ec145aa6477e14ccffaedc9 by mren:
> Modules: follow up to r276769.
> 
> edit: lib/Driver/Tools.cpp
> 
> Commit 2eec5f717893f683c81c03cf81cde5b1ad2951e5 by friss:
> Revert "Modules: follow up to r276769."
> 
> edit: lib/Driver/Tools.cpp
> 
> Commit 5bbc8bcb3843795f0106abaf015d6c77c8b6d28b by friss:
> Revert "Modules: add command line option
> 
> delete: test/Modules/Inputs/pch-import-module-out-of-date.pch
> edit: include/clang/Serialization/ASTReader.h
> edit: lib/Serialization/ASTReader.cpp
> edit: test/Driver/modules.m
> edit: include/clang/Driver/Options.td
> edit: include/clang/Lex/HeaderSearchOptions.h
> delete: test/Modules/diagnostic-options-out-of-date.m
> edit: lib/Frontend/FrontendActions.cpp
> delete: test/Modules/Inputs/DiagOutOfDate.h
> edit: lib/Frontend/CompilerInvocation.cpp
> edit: test/Modules/Inputs/module.map
> 
> Commit e8639fe501bd1d1b0860b5292e11f46b818d8cff by phausler:
> [Foundation] Update UndoManager registerUndo to adopt new naming rules
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> 
> Commit 3cf2692fc11c806031bbaf8052f104589df16680 by phausler:
> Update interperter tests for new naming of registerUndo
> 
> edit: test/Interpreter/SDK/Foundation_test.swift
> 
> Commit 6c03c553aa8ad6052adc1f92b8ed62b657c9a115 by mjmdavis:
> Correct Swift Decimal.divide to call NSDecimalDivide.
> 
> edit: stdlib/public/SDK/Foundation/Decimal.swift
> edit: test/Interpreter/SDK/NSDecimal.swift
> 
> Commit 647c55b40364dcdd81f55482fab07a0a454f60e9 by gottesmm:
> Fill out pull request testing section/multiple repo testing section of
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit 47053c6f7afe8f678f11376f5977545fb207b002 by mgottesman:
> [docs] Fix the ContinuousIntegration.md table of contents.
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit c77a21d1a39c190af59fead1423434621770f8b9 by gottesmm:
> [docs] Small styling change in ContinuousIntegration.
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit c8c41b385c0312e562abe4952fa2d6794dec2e0f by rjmccall:
> Implement SE-0077: precedence group declarations.
> 
> edit: lib/FrontendTool/FrontendTool.cpp
> edit: test/Constraints/generics.swift
> edit: test/Constraints/associated_self_types.swift
> edit: test/Constraints/diagnostics.swift
> edit: test/SIL/Serialization/Inputs/nontransparent.swift
> edit: lib/AST/Decl.cpp
> edit: include/swift/AST/Attr.h
> edit: test/Generics/associated_types.swift
> edit: test/Serialization/Inputs/vtable-function-deserialization-input.swift
> edit: test/SILGen/address_only_types.swift
> edit: lib/AST/ASTPrinter.cpp
> edit: test/IDE/complete_operators.swift
> edit: lib/AST/ASTContext.cpp
> edit: include/swift/AST/Module.h
> edit: lib/I

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

2016-07-26 Thread Andrew Trick via swift-dev

CoreFoundation changes crossed paths with UnsafeRawPointer changes. I’m fixing 
those cases now.
-Andy

> On Jul 26, 2016, at 3:16 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6862]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6862/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Tue, 26 Jul 2016 15:06:05 -0700
> Build duration:   10 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8174 test(s), Total: 8174 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit e8639fe501bd1d1b0860b5292e11f46b818d8cff by phausler:
> [Foundation] Update UndoManager registerUndo to adopt new naming rules
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> 
> Commit 3cf2692fc11c806031bbaf8052f104589df16680 by phausler:
> Update interperter tests for new naming of registerUndo
> 
> edit: test/Interpreter/SDK/Foundation_test.swift
> 
> Commit 6c03c553aa8ad6052adc1f92b8ed62b657c9a115 by mjmdavis:
> Correct Swift Decimal.divide to call NSDecimalDivide.
> 
> edit: stdlib/public/SDK/Foundation/Decimal.swift
> edit: test/Interpreter/SDK/NSDecimal.swift
> 
> Commit c8c41b385c0312e562abe4952fa2d6794dec2e0f by rjmccall:
> Implement SE-0077: precedence group declarations.
> 
> edit: stdlib/internal/SwiftExperimental/SwiftExperimental.swift
> edit: test/SourceKit/CodeComplete/complete_override.swift.response
> edit: test/attr/attr_availability.swift
> edit: test/Parse/conflict_markers.swift
> edit: lib/AST/SourceEntityWalker.cpp
> edit: test/Generics/associated_types.swift
> edit: lib/Sema/CSApply.cpp
> edit: test/SILGen/address_only_types.swift
> edit: test/Parse/builtin_bridge_object.swift
> edit: test/decl/func/arg_rename.swift
> edit: test/Parse/builtin_word.swift
> edit: test/attr/attr_dynamic.swift
> edit: lib/AST/ASTPrinter.cpp
> edit: test/decl/func/operator.swift
> edit: include/swift/Serialization/SerializedModuleLoader.h
> edit: test/IDE/complete_operators.swift
> edit: test/Parse/invalid.swift
> edit: stdlib/public/core/Policy.swift
> edit: test/Parse/try.swift
> edit: test/SILGen/copy_lvalue_peepholes.swift
> edit: include/swift/Parse/Parser.h
> edit: lib/SILGen/SILGen.h
> edit: lib/FrontendTool/FrontendTool.cpp
> edit: lib/Serialization/ModuleFile.cpp
> edit: include/swift/AST/ASTContext.h
> edit: test/SIL/Serialization/Inputs/nontransparent.swift
> edit: include/swift/AST/Module.h
> edit: lib/IDE/REPLCodeCompletion.cpp
> edit: lib/AST/ASTContext.cpp
> edit: test/Constraints/array_literal.swift
> edit: lib/Serialization/Deserialization.cpp
> edit: include/swift/Serialization/ModuleFormat.h
> edit: include/swift/AST/Attr.h
> edit: test/Generics/deduction.swift
> edit: test/DebugInfo/autoclosure.swift
> edit: test/decl/protocol/req/func.swift
> edit: test/Constraints/associated_self_types.swift
> edit: lib/IRGen/GenDecl.cpp
> edit: test/Constraints/generics.swift
> edit: lib/SILGen/SILGenDecl.cpp
> edit: include/swift/AST/DiagnosticsSema.def
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: lib/Parse/ParseDecl.cpp
> edit: test/Serialization/Inputs/vtable-function-deserialization-input.swift
> edit: include/swift/AST/DeclNodes.def
> edit: lib/AST/Module.cpp
> edit: test/Interpreter/SDK/GLKit.swift
> edit: test/Serialization/Inputs/def_operator.swift
> add: test/decl/precedencegroup/circularity.swift
> edit: test/NameBinding/Inputs/tilde_tilde_low_precedence.swift
> edit: include/swift/Serialization/ModuleFile.h
> edit: include/swift/AST/AttrKind.h
> edit: test/Constraints/diagnostics.swift
> edit: include/swift/IDE/CodeCompletion.h
> edit: test/Parse/if_expr.swift
> edit: include/swift/Serialization/DeclTypeRecordNodes.def
> edit: lib/IDE/CodeCompletion.cpp
> edit: lib/AST/ASTDumper.cpp
> edit: test/NameBinding/name-binding.swift
> edit: include/swift/AST/Decl.h
> edit: lib/Serialization/Serialization.cpp
> edit: lib/Sema/TypeChecker.h
> edit: test/Generics/slice_test.swift
> edit: test/Generics/same_type_constraints.swift
> edit: lib/AST/Decl.cpp
> edit: test/expr/expressions.swift
> edit: test/SourceKit/CodeFormat/indent-basic.swift
> edit: test/SILGen/enum.swift
> edit: lib/Sema/TypeCheckExpr.cpp
> edit: test/Parse/operator_decl.swift
> edit: test/Parse/operators.swift
> edit: include/swift/AST/Expr.h
> edit: lib/Sema/CSDiag.cpp
> edit: test/Parse/matching_patterns.swift
> edit: test/attr/accessibility.swift
> edit: test/SILOptimizer/allocbox_to_stack_not_crash.swift
> edit: test/Constraints/diag_ambiguities.swift
> edit: include/swift/AST/KnownId

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

2016-07-26 Thread Andrew Trick via swift-dev

I already checked in a corelibs-foundation fix for this one (conflicting 
simultaneous commits):

Foundation/NSJSONSerialization.swift:164:33: error: cannot invoke initializer 
for type 'UnsafeMutablePointer' with an argument list of type 
'(UnsafeRawPointer)'
return stream.write(UnsafeMutablePointer(jsonNSData.bytes), 
maxLength: jsonNSData.length)


> On Jul 26, 2016, at 3:38 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1776]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1776/ 
> 
> Project:  oss-swift-package-linux-ubuntu-15_10
> Date of build:Tue, 26 Jul 2016 15:20:01 -0700
> Build duration:   18 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit e8639fe501bd1d1b0860b5292e11f46b818d8cff by phausler:
> [Foundation] Update UndoManager registerUndo to adopt new naming rules
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> 
> Commit 3cf2692fc11c806031bbaf8052f104589df16680 by phausler:
> Update interperter tests for new naming of registerUndo
> 
> edit: test/Interpreter/SDK/Foundation_test.swift
> 
> Commit 6c03c553aa8ad6052adc1f92b8ed62b657c9a115 by mjmdavis:
> Correct Swift Decimal.divide to call NSDecimalDivide.
> 
> edit: stdlib/public/SDK/Foundation/Decimal.swift
> edit: test/Interpreter/SDK/NSDecimal.swift
> 
> Commit 804d20d5d608ef5155d7821d7dee083f2eff27cd by mgottesman:
> [docs] Add a quick doc for the CI that initially just contain
> 
> add: docs/CI.md
> 
> Commit b1da6c32fe60d486f001d5983dcb82e91609672b by github:
> Rename CI.md to ContinuousIntegration.md
> 
> delete: docs/CI.md
> add: docs/ContinuousIntegration.md
> 
> Commit 647c55b40364dcdd81f55482fab07a0a454f60e9 by github:
> Fill out pull request testing section/multiple repo testing section of
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit 47053c6f7afe8f678f11376f5977545fb207b002 by mgottesman:
> [docs] Fix the ContinuousIntegration.md table of contents.
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit c77a21d1a39c190af59fead1423434621770f8b9 by github:
> [docs] Small styling change in ContinuousIntegration.
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit c8c41b385c0312e562abe4952fa2d6794dec2e0f by rjmccall:
> Implement SE-0077: precedence group declarations.
> 
> edit: include/swift/AST/KnownIdentifiers.def
> edit: test/Parse/operators.swift
> edit: test/DebugInfo/autoclosure.swift
> edit: include/swift/AST/Module.h
> edit: lib/IDE/SyntaxModel.cpp
> edit: test/Generics/slice_test.swift
> edit: include/swift/AST/DeclNodes.def
> edit: test/SourceKit/CodeComplete/complete_override.swift.response
> edit: test/SourceKit/CodeFormat/indent-basic.swift
> edit: test/Generics/deduction.swift
> edit: test/Constraints/array_literal.swift
> edit: test/Generics/same_type_constraints.swift
> edit: test/attr/attr_dynamic.swift
> edit: test/decl/func/operator.swift
> edit: lib/AST/Module.cpp
> edit: test/Parse/builtin_bridge_object.swift
> edit: include/swift/Serialization/DeclTypeRecordNodes.def
> edit: lib/Serialization/ModuleFile.cpp
> edit: test/decl/func/arg_rename.swift
> edit: lib/AST/Decl.cpp
> edit: test/IDE/coloring.swift
> edit: lib/AST/SourceEntityWalker.cpp
> edit: test/Serialization/Inputs/vtable-function-deserialization-input.swift
> edit: test/expr/expressions.swift
> edit: include/swift/Parse/Tokens.def
> edit: lib/IRGen/GenDecl.cpp
> edit: test/Parse/invalid.swift
> edit: test/Serialization/Inputs/def_operator.swift
> edit: test/Constraints/associated_self_types.swift
> edit: test/IDE/Inputs/foo_swift_module.swift
> edit: test/Parse/conflict_markers.swift
> edit: test/SILGen/copy_lvalue_peepholes.swift
> edit: test/decl/func/functions.swift
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: test/attr/accessibility.swift
> edit: test/IDE/Inputs/foo_swift_module.printed.comments.txt
> edit: test/Constraints/generic_protocol_witness.swift
> add: test/decl/precedencegroup/Inputs/ExternPrecedences.swift
> edit: test/NameBinding/Inputs/tilde_tilde_high_precedence.swift
> edit: test/IRGen/swift3-metadata-coff.swift
> edit: lib/IDE/REPLCodeCompletion.cpp
> edit: test/IDE/print_ast_tc_decls.swift
> edit: test/Constraints/protocols.swift
> edit: lib/Serialization/Serialization.cpp
> edit: test/decl/protocol/protocols.swift
> edit: test/Parse/matching_patterns.swift
> edit: include/swift/AST/TypeMemberVisitor.h
> edit: include/swift/Serialization/SerializedModuleLoader.h
> edit: test/Constraints/diag_ambiguities.swift
> edit: lib/Parse/ParseDecl.cpp
> edit: include/swift/Parse/Parser.h
> edit: test/IDE/complete_operators.swift
> edit: include/swift/AST/DiagnosticsSema.def
> edit: test/Constraints/generi

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

2016-07-26 Thread Andrew Trick via swift-dev

And this should be fixed on the next build.
-Andy

> On Jul 26, 2016, at 3:39 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#6530]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6530/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Tue, 26 Jul 2016 15:27:26 -0700
> Build duration:   12 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit e8639fe501bd1d1b0860b5292e11f46b818d8cff by phausler:
> [Foundation] Update UndoManager registerUndo to adopt new naming rules
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> 
> Commit 3cf2692fc11c806031bbaf8052f104589df16680 by phausler:
> Update interperter tests for new naming of registerUndo
> 
> edit: test/Interpreter/SDK/Foundation_test.swift
> 
> Commit 6c03c553aa8ad6052adc1f92b8ed62b657c9a115 by mjmdavis:
> Correct Swift Decimal.divide to call NSDecimalDivide.
> 
> edit: stdlib/public/SDK/Foundation/Decimal.swift
> edit: test/Interpreter/SDK/NSDecimal.swift
> 
> Commit 804d20d5d608ef5155d7821d7dee083f2eff27cd by mgottesman:
> [docs] Add a quick doc for the CI that initially just contain
> 
> add: docs/CI.md
> 
> Commit b1da6c32fe60d486f001d5983dcb82e91609672b by github:
> Rename CI.md to ContinuousIntegration.md
> 
> add: docs/ContinuousIntegration.md
> delete: docs/CI.md
> 
> Commit 647c55b40364dcdd81f55482fab07a0a454f60e9 by github:
> Fill out pull request testing section/multiple repo testing section of
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit 47053c6f7afe8f678f11376f5977545fb207b002 by mgottesman:
> [docs] Fix the ContinuousIntegration.md table of contents.
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit c77a21d1a39c190af59fead1423434621770f8b9 by github:
> [docs] Small styling change in ContinuousIntegration.
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit c8c41b385c0312e562abe4952fa2d6794dec2e0f by rjmccall:
> Implement SE-0077: precedence group declarations.
> 
> edit: include/swift/AST/DiagnosticsParse.def
> edit: lib/FrontendTool/FrontendTool.cpp
> edit: stdlib/private/StdlibUnittest/StdlibCoreExtras.swift
> edit: include/swift/AST/DiagnosticsSema.def
> edit: test/Parse/if_expr.swift
> edit: test/attr/attr_dynamic.swift
> edit: test/Constraints/generics.swift
> edit: lib/Parse/ParseDecl.cpp
> edit: include/swift/Serialization/ModuleFile.h
> edit: include/swift/IDE/CodeCompletion.h
> edit: lib/IRGen/GenDecl.cpp
> edit: lib/Sema/CSApply.cpp
> edit: test/SILGen/enum.swift
> edit: tools/SourceKit/lib/SwiftLang/SwiftLangSupport.cpp
> edit: include/swift/AST/AttrKind.h
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: test/IDE/Inputs/foo_swift_module.swift
> edit: include/swift/AST/ASTContext.h
> edit: test/SIL/Serialization/Inputs/nontransparent.swift
> edit: lib/IDE/REPLCodeCompletion.cpp
> edit: lib/Serialization/Deserialization.cpp
> edit: stdlib/public/core/Policy.swift
> edit: test/Generics/same_type_constraints.swift
> edit: test/Generics/slice_test.swift
> edit: lib/Serialization/SerializedModuleLoader.cpp
> edit: test/Constraints/protocols.swift
> edit: include/swift/Parse/Tokens.def
> edit: test/attr/accessibility.swift
> edit: include/swift/AST/TypeMemberVisitor.h
> edit: include/swift/AST/DeclNodes.def
> edit: test/NameBinding/Inputs/tilde_tilde_low_precedence.swift
> edit: include/swift/AST/Attr.h
> edit: include/swift/Serialization/DeclTypeRecordNodes.def
> edit: test/Parse/operators.swift
> edit: test/Serialization/Inputs/def_operator.swift
> edit: lib/Sema/TypeCheckExpr.cpp
> edit: test/SILOptimizer/allocbox_to_stack_not_crash.swift
> edit: test/IDE/coloring.swift
> edit: test/expr/expressions.swift
> edit: test/attr/attr_availability.swift
> add: test/decl/precedencegroup/circularity.swift
> edit: test/SILGen/address_only_types.swift
> edit: test/decl/func/functions.swift
> edit: test/decl/protocol/req/func.swift
> edit: test/Generics/associated_types.swift
> edit: test/SourceKit/CodeFormat/indent-basic.swift
> edit: lib/AST/Module.cpp
> edit: lib/Sema/TypeChecker.h
> edit: lib/AST/ASTWalker.cpp
> edit: test/Parse/matching_patterns.swift
> edit: lib/AST/SourceEntityWalker.cpp
> edit: test/Parse/operator_decl.swift
> add: test/decl/precedencegroup/Inputs/ExternPrecedences.swift
> edit: test/SILGen/copy_lvalue_peepholes.swift
> edit: test/decl/func/arg_rename.swift
> edit: test/Parse/conflict_markers.swift
> edit: test/Parse/try.swift
> edit: lib/AST/ASTDumper.cpp
> edit: include/swift/AST/KnownIdentifiers.def
> edit: include/swift/AST/Module.h
> edit: stdlib/public/core/Integers.swift.gyb
> edit: include/swift/Serialization/ModuleFormat.h
> edit: test/Par

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

2016-07-26 Thread Andrew Trick via swift-dev

I can reproduce this one...

/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift/validation-test/stdlib/MicroStdlib/Inputs/Swift.swift:35:10:
 error: broken standard library: missing builtin precedence group 
'AssignmentPrecedence'
self = 0
 ^

But can’t reproduce the IDE failures...

Maybe disable those for now with a bug report?

-Andy

> On Jul 26, 2016, at 3:46 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6863]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6863/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Tue, 26 Jul 2016 15:38:33 -0700
> Build duration:   8 min 2 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 4 test(s), Passed: 8171 test(s), Total: 8175 test(s)
> Failed: Swift(linux-x86_64).IDE.complete_constructor.swift 
> 
> Failed: Swift(linux-x86_64).IDE.complete_expr_postfix_begin.swift 
> 
> Failed: Swift(linux-x86_64).IDE.complete_keywords.swift 
> 
> Failed: Swift(linux-x86_64).stdlib/MicroStdlib.MicroStdlib.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit a499e2ea679221cf00d5372a61048f787e7c30a2 by daniel_dunbar:
> [Swift] Update for another constraint syntax change.
> 
> edit: Tests/SourceControl/GitRepositoryTests.swift
> edit: Tests/Basic/FileSystemTests.swift
> 
> Commit dd9e4385c7f69dd58d55f2618b8970eed1054f5d by atrick:
> Quick fix for conflicting commits.
> 
> edit: Foundation/NSJSONSerialization.swift

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

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

2016-07-26 Thread Andrew Trick via swift-dev

This was a conflicting commit that I fixed.
-Andy

> On Jul 26, 2016, at 5:10 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#1787]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/1787/ 
> 
> Project:  oss-swift-package-linux-ubuntu-14_04
> Date of build:Tue, 26 Jul 2016 16:44:51 -0700
> Build duration:   25 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit e8639fe501bd1d1b0860b5292e11f46b818d8cff by phausler:
> [Foundation] Update UndoManager registerUndo to adopt new naming rules
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> 
> Commit 3cf2692fc11c806031bbaf8052f104589df16680 by phausler:
> Update interperter tests for new naming of registerUndo
> 
> edit: test/Interpreter/SDK/Foundation_test.swift
> 
> Commit 6c03c553aa8ad6052adc1f92b8ed62b657c9a115 by mjmdavis:
> Correct Swift Decimal.divide to call NSDecimalDivide.
> 
> edit: stdlib/public/SDK/Foundation/Decimal.swift
> edit: test/Interpreter/SDK/NSDecimal.swift
> 
> Commit 804d20d5d608ef5155d7821d7dee083f2eff27cd by mgottesman:
> [docs] Add a quick doc for the CI that initially just contain
> 
> add: docs/CI.md
> 
> Commit b1da6c32fe60d486f001d5983dcb82e91609672b by github:
> Rename CI.md to ContinuousIntegration.md
> 
> delete: docs/CI.md
> add: docs/ContinuousIntegration.md
> 
> Commit 647c55b40364dcdd81f55482fab07a0a454f60e9 by github:
> Fill out pull request testing section/multiple repo testing section of
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit 47053c6f7afe8f678f11376f5977545fb207b002 by mgottesman:
> [docs] Fix the ContinuousIntegration.md table of contents.
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit c77a21d1a39c190af59fead1423434621770f8b9 by github:
> [docs] Small styling change in ContinuousIntegration.
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit c8c41b385c0312e562abe4952fa2d6794dec2e0f by rjmccall:
> Implement SE-0077: precedence group declarations.
> 
> edit: test/SILOptimizer/allocbox_to_stack_not_crash.swift
> edit: test/SILOptimizer/mandatory_inlining.swift
> edit: test/NameBinding/Inputs/tilde_tilde_high_precedence.swift
> edit: test/SILGen/enum.swift
> edit: include/swift/AST/DeclNodes.def
> edit: test/IDE/print_ast_tc_decls.swift
> edit: lib/Serialization/SerializedModuleLoader.cpp
> edit: include/swift/AST/DiagnosticsSema.def
> edit: test/SILGen/address_only_types.swift
> edit: stdlib/private/StdlibUnittest/StdlibCoreExtras.swift
> edit: test/SILGen/copy_lvalue_peepholes.swift
> edit: include/swift/Serialization/ModuleFormat.h
> edit: test/IDE/Inputs/foo_swift_module.swift
> edit: lib/IDE/SyntaxModel.cpp
> edit: test/IDE/coloring.swift
> edit: include/swift/Parse/Tokens.def
> edit: lib/Sema/NameBinding.cpp
> edit: lib/AST/SourceEntityWalker.cpp
> edit: test/Generics/same_type_constraints.swift
> edit: test/Parse/invalid.swift
> edit: test/Parse/builtin_word.swift
> edit: test/attr/attr_availability.swift
> edit: test/NameBinding/name-binding.swift
> edit: test/IDE/complete_operators.swift
> edit: include/swift/AST/Decl.h
> edit: include/swift/Serialization/DeclTypeRecordNodes.def
> edit: include/swift/AST/AttrKind.h
> edit: test/Parse/matching_patterns.swift
> edit: lib/Sema/CSApply.cpp
> edit: test/expr/expressions.swift
> edit: lib/AST/ASTWalker.cpp
> edit: test/decl/func/functions.swift
> edit: include/swift/Parse/Parser.h
> edit: test/Constraints/diag_ambiguities.swift
> edit: test/decl/func/arg_rename.swift
> add: test/decl/precedencegroup/Inputs/ExternPrecedences.swift
> edit: test/NameBinding/Inputs/tilde_tilde_low_precedence.swift
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: include/swift/AST/Attr.h
> edit: include/swift/AST/ASTContext.h
> edit: test/Parse/operator_decl.swift
> edit: test/IRGen/swift3-metadata-coff.swift
> edit: stdlib/public/core/Integers.swift.gyb
> edit: lib/IDE/REPLCodeCompletion.cpp
> edit: lib/Sema/CSDiag.cpp
> edit: test/Constraints/operator.swift
> edit: test/Generics/deduction.swift
> edit: test/decl/func/operator.swift
> edit: test/attr/attr_dynamic.swift
> edit: include/swift/AST/Expr.h
> edit: include/swift/AST/KnownIdentifiers.def
> edit: test/Constraints/generics.swift
> edit: test/Constraints/array_literal.swift
> edit: test/Parse/try.swift
> edit: lib/FrontendTool/FrontendTool.cpp
> edit: include/swift/Serialization/SerializedModuleLoader.h
> edit: lib/IRGen/GenDecl.cpp
> edit: test/Parse/operators.swift
> add: test/decl/precedencegroup/circularity.swift
> edit: test/Constraints/generic_protocol_witness.swift
> edit: lib/SILGen/SILGen.h
> edit: test/Parse/if_expr.swift
> edit: test/Serialization/Inputs/def_operator.swift
> edit: lib/IDE/Co

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

2016-07-26 Thread Andrew Trick via swift-dev

Phillipe, do you know if these have been fixed yet?

-Andy

Foundation/NSURLResponse.swift:372:38: error: value of optional type 
'UnicodeScalar?' not unwrapped; did you mean to use '!' or '?'?
case (.nonQuoted(let s), separator):
 ^
  !
Foundation/NSURLResponse.swift:375:38: error: value of optional type 
'UnicodeScalar?' not unwrapped; did you mean to use '!' or '?'?
case (.nonQuoted(let s), escape):
 ^
   !
Foundation/NSURLResponse.swift:377:38: error: value of optional type 
'UnicodeScalar?' not unwrapped; did you mean to use '!' or '?'?
case (.nonQuoted(let s), quote):
 ^
  !
Foundation/NSURLResponse.swift:385:35: error: value of optional type 
'UnicodeScalar?' not unwrapped; did you mean to use '!' or '?'?
case (.quoted(let s), quote):
  ^
   !
Foundation/NSURLResponse.swift:387:35: error: value of optional type 
'UnicodeScalar?' not unwrapped; did you mean to use '!' or '?'?
case (.quoted(let s), escape):
  ^
!

> On Jul 26, 2016, at 5:17 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10-long-test [#599]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10-long-test/599/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10-long-test
> Date of build:Tue, 26 Jul 2016 17:09:11 -0700
> Build duration:   8 min 4 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
> Failed: 0 test(s), Passed: 8062 test(s), Total: 8062 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 226 test(s), Total: 226 test(s)
> 
> Changes
> 
> Commit e8639fe501bd1d1b0860b5292e11f46b818d8cff by phausler:
> [Foundation] Update UndoManager registerUndo to adopt new naming rules
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> 
> Commit 3cf2692fc11c806031bbaf8052f104589df16680 by phausler:
> Update interperter tests for new naming of registerUndo
> 
> edit: test/Interpreter/SDK/Foundation_test.swift
> 
> Commit bbf86865d615ca21bb074f31255a53b3dd9d0c37 by xin_tong:
> Change unicodescalar to failable
> 
> edit: validation-test/stdlib/Unicode.swift.gyb
> edit: validation-test/stdlib/UnicodeUTFEncoders.swift
> edit: test/1_stdlib/PrintInteger.swift
> edit: test/1_stdlib/Character.swift
> edit: test/Constraints/default_literals.swift
> edit: stdlib/public/core/StringCore.swift
> edit: test/1_stdlib/TestCharacterSet.swift
> edit: validation-test/stdlib/String.swift
> edit: stdlib/public/core/Unicode.swift
> edit: stdlib/public/core/StringUnicodeScalarView.swift
> edit: stdlib/public/SDK/Foundation/CharacterSet.swift
> edit: test/Interpreter/SDK/Accelerate.swift
> edit: stdlib/public/core/StaticString.swift
> edit: stdlib/public/core/UnicodeScalar.swift
> edit: test/Prototypes/TextFormatting.swift
> edit: test/Interpreter/simple.swift
> edit: validation-test/stdlib/StringViews.swift
> edit: validation-test/stdlib/UnicodeLongTest.swift
> 
> Commit 6c03c553aa8ad6052adc1f92b8ed62b657c9a115 by mjmdavis:
> Correct Swift Decimal.divide to call NSDecimalDivide.
> 
> edit: stdlib/public/SDK/Foundation/Decimal.swift
> edit: test/Interpreter/SDK/NSDecimal.swift
> 
> Commit 647c55b40364dcdd81f55482fab07a0a454f60e9 by github:
> Fill out pull request testing section/multiple repo testing section of
> 
> edit: docs/ContinuousIntegration.md
> 
> Commit 4356661573e587d2d112dda60ebd20e1d4c574de by jgroff:
> Allow single-element tuples in SIL mode.
> 
> edit: lib/Sema/TypeCheckType.cpp
> 
> Commit e884ab737d9606369afe5347ef78a7324c66e47a by jgroff:
> Foundation: Make AnyHashable bridge to NSObject.
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> edit: lib/AST/ASTContext.cpp
> 
> Commit 1e8dd0e34b6ec30e8c33f47dbdcb7ae558bf9636 by jgroff:
> ClangImporter: Import unbounded NSSets and NSDictionaries using
> 
> edit: stdlib/public/SDK/Foundation/NSStringAPI.swift
> edit: test/ClangModules/objc_bridging.swift
> edit: lib/ClangImporter/ImportType.cpp
> edit: test/DebugInfo/test-foundation.swift
> edit: test/IDE/print_clang_foundation.swift
> edit: test/SILGen/objc_bridged_results.swift
> edit: test/1_stdlib/ErrorBridged.swift
> edit: test/IDE/print_omit_needless_words.swift
> edit: stdlib/public/SDK/Foundation/NSError.swift
> edit: stdlib/public/SDK/Foundatio

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (master) #1777

2016-07-26 Thread Andrew Trick via swift-dev

This is Xin’s.
-Andy

> On Jul 26, 2016, at 5:38 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1777]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1777/ 
> 
> Project:  oss-swift-package-linux-ubuntu-15_10
> Date of build:Tue, 26 Jul 2016 17:23:29 -0700
> Build duration:   14 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit bbf86865d615ca21bb074f31255a53b3dd9d0c37 by xin_tong:
> Change unicodescalar to failable
> 
> edit: test/Interpreter/simple.swift
> edit: validation-test/stdlib/String.swift
> edit: stdlib/public/core/StringCore.swift
> edit: validation-test/stdlib/UnicodeUTFEncoders.swift
> edit: stdlib/public/SDK/Foundation/CharacterSet.swift
> edit: test/1_stdlib/TestCharacterSet.swift
> edit: test/Prototypes/TextFormatting.swift
> edit: stdlib/public/core/StringUnicodeScalarView.swift
> edit: test/1_stdlib/Character.swift
> edit: test/Interpreter/SDK/Accelerate.swift
> edit: stdlib/public/core/UnicodeScalar.swift
> edit: validation-test/stdlib/StringViews.swift
> edit: validation-test/stdlib/Unicode.swift.gyb
> edit: validation-test/stdlib/UnicodeLongTest.swift
> edit: stdlib/public/core/Unicode.swift
> edit: stdlib/public/core/StaticString.swift
> edit: test/Constraints/default_literals.swift
> edit: test/1_stdlib/PrintInteger.swift
> 
> Commit 4356661573e587d2d112dda60ebd20e1d4c574de by jgroff:
> Allow single-element tuples in SIL mode.
> 
> edit: lib/Sema/TypeCheckType.cpp
> 
> Commit e884ab737d9606369afe5347ef78a7324c66e47a by jgroff:
> Foundation: Make AnyHashable bridge to NSObject.
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> edit: lib/AST/ASTContext.cpp
> 
> Commit 1e8dd0e34b6ec30e8c33f47dbdcb7ae558bf9636 by jgroff:
> ClangImporter: Import unbounded NSSets and NSDictionaries using
> 
> edit: test/ClangModules/objc_bridging_generics.swift
> edit: test/SILGen/objc_bridged_results.swift
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> edit: stdlib/public/SDK/Foundation/NSStringAPI.swift
> edit: test/SILGen/Inputs/Foundation.swift
> edit: lib/ClangImporter/ImportType.cpp
> edit: stdlib/public/SDK/Foundation/NSError.swift
> edit: test/IDE/print_clang_foundation.swift
> edit: lib/AST/ASTContext.cpp
> edit: stdlib/public/SDK/CoreImage/CoreImage.swift
> edit: test/1_stdlib/NSError.swift
> edit: lib/ClangImporter/ImporterImpl.h
> edit: test/DebugInfo/test-foundation.swift
> edit: test/IDE/print_omit_needless_words.swift
> edit: include/swift/AST/ASTContext.h
> edit: test/1_stdlib/ErrorBridged.swift
> edit: test/1_stdlib/NSEnumeratorAPI.swift
> edit: test/ClangModules/objc_bridging.swift
> 
> Commit 1874bf01c66196ba506b965132ab5a1500138a4a by jgroff:
> SIL: Relax linkage assertion in SILModule::getOrCreateFunction.
> 
> edit: lib/SIL/SILModule.cpp
> 
> Commit 5111a42d6d962c1098e38be5cfc54953c012fd3a by jgroff:
> Update changelog for SE-0131.
> 
> edit: CHANGELOG.md
> 
> Commit cac313d145fdafff76b79e8eace196cbf3f29807 by jgroff:
> Disable cast optimization for address-only types.
> 
> edit: include/swift/SIL/SILBuilder.h
> edit: lib/SILOptimizer/Utils/Local.cpp
> 
> Commit d1106c07826fd8d66e7c707cc478d022c09b9147 by github:
> Fixes typos in OptimizationTips.rst
> 
> edit: docs/OptimizationTips.rst
> 
> Commit 4560bac57c7cdd60910aecdd82d8b1b96f4729ef by jordan_rose:
> Fix misuses of llvm::StringSwitch.
> 
> edit: lib/SILOptimizer/PassManager/PassManager.cpp
> edit: lib/IRGen/GenBuiltin.cpp
> 
> Commit 14601babe9b4888a35e16034259be8bcd175ddad by Mishal Shah:
> [uitls] Add support for swift-3.0-preview-5-branch to update checkout
> 
> edit: utils/update-checkout-config.json
> 
> Commit e14baf7b65ef775d7118df2ec055cf6f7897cebb by ankit.spd:
> [Tests] Remove surplus functional tests
> 
> delete: Fixtures/InvalidLayouts/MultipleRoots2/Package.swift
> delete: Fixtures/InvalidLayouts/MultipleRoots1/Foo.swift
> delete: Fixtures/InvalidLayouts/Generic3/Package.swift
> delete: Fixtures/InvalidLayouts/MultipleRoots2/src/FooBarLib/FooBar.swift
> delete: Fixtures/InvalidLayouts/Generic1/Sources/Foo.swift
> delete: Fixtures/InvalidLayouts/Generic2/main.swift
> delete: Fixtures/InvalidLayouts/MultipleRoots2/Sources/BarExec/Bar.swift
> edit: Tests/Functional/XCTestManifests.swift
> delete: Fixtures/InvalidLayouts/Generic3/Sources/main.swift
> delete: Fixtures/ValidLayouts/SingleModule/CustomizedName/Foo.swift
> delete: Fixtures/InvalidLayouts/Generic5/Foo/Foo.swift
> delete: Fixtures/InvalidLayouts/Generic3/Sources/Bar/Foo.swift
> delete: Fixtures/InvalidLayouts/Generic5/Package.swift
> delete: Fixtures/InvalidLayouts/MultipleRoots1/main.swift
> delete: Fixture

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

2016-07-27 Thread Andrew Trick via swift-dev

Mishal,

Can you tell me what happened here?

-Andy

> On Jul 27, 2016, at 9:57 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#5519]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5519/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Wed, 27 Jul 2016 09:49:36 -0700
> Build duration:   7 min 53 sec
> 
> Changes
> 
> Commit 37c084bbebdcf6a46ae1e96369b95d4f4d9dac17 by atrick:
> Use UnsafeMutableRawPointer in HashedCollection
> 
> edit: stdlib/public/core/HashedCollections.swift.gyb
> 
> Commit c12552860019984c75c44dc0bd3617bce650b706 by atrick:
> Use a `UnsafeMutableRawPointer` in SwiftNativeNSArray.getObjects()
> 
> edit: stdlib/public/core/SwiftNativeNSArray.swift
> 
> Commit 2e0dd7b046486934abe024668ea7fdb34dde7ea8 by atrick:
> Use UnsafeRawPointer in withArrayOfCStrings.
> 
> edit: stdlib/private/SwiftPrivate/SwiftPrivate.swift
> 
> Commit 3e2372b6a381c09af040752746e47bba4f30f77a by atrick:
> Use UnsafeRawPointer in GLKit _indexHomogeneousValue.
> 
> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
> 
> Commit 9886e4ef54e1b50f95d18a27908196658c0ff97c by atrick:
> Use UnsafeRawPointer in StringCore.
> 
> edit: stdlib/public/core/StringBuffer.swift
> edit: stdlib/public/core/StringCore.swift
> edit: stdlib/public/core/StringUnicodeScalarView.swift
> edit: stdlib/public/core/String.swift
> edit: stdlib/public/core/StringUTF8.swift
> edit: stdlib/public/core/StringBridge.swift
> edit: test/1_stdlib/NewStringAppending.swift
> edit: test/1_stdlib/NewString.swift
> edit: stdlib/public/core/Character.swift
> edit: stdlib/public/core/Runtime.swift.gyb
> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
> edit: stdlib/public/core/UnsafePointer.swift.gyb

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

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

2016-07-27 Thread Andrew Trick via swift-dev

FYI: Swift CI just passed on this commit minutes before this crash (it was 
automerged). Of course validation tests also pass for me locally on linux and 
darwin.

-Andy

> On Jul 27, 2016, at 10:11 AM, Erik Eckstein  wrote:
> 
> I just reproduced it locally. It's a swift compiler crash
> 
> 
>> On Jul 27, 2016, at 9:59 AM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> Mishal,
>> 
>> Can you tell me what happened here?
>> 
>> -Andy
>> 
>>> On Jul 27, 2016, at 9:57 AM, no-re...@swift.org <mailto:no-re...@swift.org> 
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-osx [#5519]
>>> 
>>> Build URL:  https://ci.swift.org/job/oss-swift-incremental-RA-osx/5519/ 
>>> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/5519/>
>>> Project:oss-swift-incremental-RA-osx
>>> Date of build:  Wed, 27 Jul 2016 09:49:36 -0700
>>> Build duration: 7 min 53 sec
>>> 
>>> Changes
>>> 
>>> Commit 37c084bbebdcf6a46ae1e96369b95d4f4d9dac17 by atrick:
>>> Use UnsafeMutableRawPointer in HashedCollection
>>> 
>>> edit: stdlib/public/core/HashedCollections.swift.gyb
>>> 
>>> Commit c12552860019984c75c44dc0bd3617bce650b706 by atrick:
>>> Use a `UnsafeMutableRawPointer` in SwiftNativeNSArray.getObjects()
>>> 
>>> edit: stdlib/public/core/SwiftNativeNSArray.swift
>>> 
>>> Commit 2e0dd7b046486934abe024668ea7fdb34dde7ea8 by atrick:
>>> Use UnsafeRawPointer in withArrayOfCStrings.
>>> 
>>> edit: stdlib/private/SwiftPrivate/SwiftPrivate.swift
>>> 
>>> Commit 3e2372b6a381c09af040752746e47bba4f30f77a by atrick:
>>> Use UnsafeRawPointer in GLKit _indexHomogeneousValue.
>>> 
>>> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
>>> 
>>> Commit 9886e4ef54e1b50f95d18a27908196658c0ff97c by atrick:
>>> Use UnsafeRawPointer in StringCore.
>>> 
>>> edit: stdlib/public/core/StringBuffer.swift
>>> edit: stdlib/public/core/StringCore.swift
>>> edit: stdlib/public/core/StringUnicodeScalarView.swift
>>> edit: stdlib/public/core/String.swift
>>> edit: stdlib/public/core/StringUTF8.swift
>>> edit: stdlib/public/core/StringBridge.swift
>>> edit: test/1_stdlib/NewStringAppending.swift
>>> edit: test/1_stdlib/NewString.swift
>>> edit: stdlib/public/core/Character.swift
>>> edit: stdlib/public/core/Runtime.swift.gyb
>>> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
>>> edit: stdlib/public/core/UnsafePointer.swift.gyb
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 

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

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

2016-07-27 Thread Andrew Trick via swift-dev

This was a CI infrastructure problem. Error copying a file.

That’s why I directed to question to Mishal. The bot’s job coincided with 
locking the branch.

-Andy

> On Jul 27, 2016, at 10:23 AM, Andrew Trick via swift-dev 
>  wrote:
> 
> FYI: Swift CI just passed on this commit minutes before this crash (it was 
> automerged). Of course validation tests also pass for me locally on linux and 
> darwin.
> 
> -Andy
> 
>> On Jul 27, 2016, at 10:11 AM, Erik Eckstein > <mailto:eeckst...@apple.com>> wrote:
>> 
>> I just reproduced it locally. It's a swift compiler crash
>> 
>> 
>>> On Jul 27, 2016, at 9:59 AM, Andrew Trick via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Mishal,
>>> 
>>> Can you tell me what happened here?
>>> 
>>> -Andy
>>> 
>>>> On Jul 27, 2016, at 9:57 AM, no-re...@swift.org 
>>>> <mailto:no-re...@swift.org> wrote:
>>>> 
>>>> [FAILURE] oss-swift-incremental-RA-osx [#5519]
>>>> 
>>>> Build URL: https://ci.swift.org/job/oss-swift-incremental-RA-osx/5519/ 
>>>> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/5519/>
>>>> Project:   oss-swift-incremental-RA-osx
>>>> Date of build: Wed, 27 Jul 2016 09:49:36 -0700
>>>> Build duration:7 min 53 sec
>>>> 
>>>> Changes
>>>> 
>>>> Commit 37c084bbebdcf6a46ae1e96369b95d4f4d9dac17 by atrick:
>>>> Use UnsafeMutableRawPointer in HashedCollection
>>>> 
>>>> edit: stdlib/public/core/HashedCollections.swift.gyb
>>>> 
>>>> Commit c12552860019984c75c44dc0bd3617bce650b706 by atrick:
>>>> Use a `UnsafeMutableRawPointer` in SwiftNativeNSArray.getObjects()
>>>> 
>>>> edit: stdlib/public/core/SwiftNativeNSArray.swift
>>>> 
>>>> Commit 2e0dd7b046486934abe024668ea7fdb34dde7ea8 by atrick:
>>>> Use UnsafeRawPointer in withArrayOfCStrings.
>>>> 
>>>> edit: stdlib/private/SwiftPrivate/SwiftPrivate.swift
>>>> 
>>>> Commit 3e2372b6a381c09af040752746e47bba4f30f77a by atrick:
>>>> Use UnsafeRawPointer in GLKit _indexHomogeneousValue.
>>>> 
>>>> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
>>>> 
>>>> Commit 9886e4ef54e1b50f95d18a27908196658c0ff97c by atrick:
>>>> Use UnsafeRawPointer in StringCore.
>>>> 
>>>> edit: stdlib/public/core/StringBuffer.swift
>>>> edit: stdlib/public/core/StringCore.swift
>>>> edit: stdlib/public/core/StringUnicodeScalarView.swift
>>>> edit: stdlib/public/core/String.swift
>>>> edit: stdlib/public/core/StringUTF8.swift
>>>> edit: stdlib/public/core/StringBridge.swift
>>>> edit: test/1_stdlib/NewStringAppending.swift
>>>> edit: test/1_stdlib/NewString.swift
>>>> edit: stdlib/public/core/Character.swift
>>>> edit: stdlib/public/core/Runtime.swift.gyb
>>>> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
>>>> edit: stdlib/public/core/UnsafePointer.swift.gyb
>>> 
>>> ___
>>> swift-dev mailing list
>>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev 
>>> <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

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

2016-07-27 Thread Andrew Trick via swift-dev

This fails periodically:

[TestIndirectEnumVariables.py FAILED]

It’s definitely not my commit, which passed linux CI multiple times.
-Andy

> On Jul 27, 2016, at 11:13 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1783]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1783/ 
> 
> Project:  oss-swift-package-linux-ubuntu-15_10
> Date of build:Wed, 27 Jul 2016 10:43:15 -0700
> Build duration:   30 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit ea693dd8d1fcf699f9bd2237562aa7e27990f8da by gribozavr:
> Add AnyHashable support for Foundation.Decimal
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> add: validation-test/stdlib/NSDecimalNumberBridging.swift.gyb
> edit: stdlib/public/SDK/Foundation/TypePreservingNSNumber.mm
> 
> Commit 37b789007de381e533de104d80fcb637e59ece89 by aschwaighofer:
> Disable Dictionary/Set.swift tests that fail in optimize mode
> 
> edit: validation-test/stdlib/Dictionary.swift
> edit: validation-test/stdlib/Set.swift
> 
> Commit 37c084bbebdcf6a46ae1e96369b95d4f4d9dac17 by atrick:
> Use UnsafeMutableRawPointer in HashedCollection
> 
> edit: stdlib/public/core/HashedCollections.swift.gyb
> 
> Commit c12552860019984c75c44dc0bd3617bce650b706 by atrick:
> Use a `UnsafeMutableRawPointer` in SwiftNativeNSArray.getObjects()
> 
> edit: stdlib/public/core/SwiftNativeNSArray.swift
> 
> Commit 2e0dd7b046486934abe024668ea7fdb34dde7ea8 by atrick:
> Use UnsafeRawPointer in withArrayOfCStrings.
> 
> edit: stdlib/private/SwiftPrivate/SwiftPrivate.swift
> 
> Commit 3e2372b6a381c09af040752746e47bba4f30f77a by atrick:
> Use UnsafeRawPointer in GLKit _indexHomogeneousValue.
> 
> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
> 
> Commit 108c102c54ff7ca5480881df969030d80c4aebd6 by rjmccall:
> Fix test for precedence groups.
> 
> edit: validation-test/stdlib/MicroStdlib/Inputs/Swift.swift
> edit: validation-test/stdlib/MicroStdlib/MicroStdlib.swift
> 
> Commit 9886e4ef54e1b50f95d18a27908196658c0ff97c by atrick:
> Use UnsafeRawPointer in StringCore.
> 
> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
> edit: test/1_stdlib/NewString.swift
> edit: test/1_stdlib/NewStringAppending.swift
> edit: stdlib/public/core/String.swift
> edit: stdlib/public/core/Character.swift
> edit: stdlib/public/core/StringUnicodeScalarView.swift
> edit: stdlib/public/core/Runtime.swift.gyb
> edit: stdlib/public/core/UnsafePointer.swift.gyb
> edit: stdlib/public/core/StringCore.swift
> edit: stdlib/public/core/StringUTF8.swift
> edit: stdlib/public/core/StringBuffer.swift
> edit: stdlib/public/core/StringBridge.swift
> 
> Commit 3e0f922d9a50bce663d01e4d702cd242557d7021 by ankit.spd:
> [PackageModel] Change ClangModule baseclass to Module
> 
> edit: Sources/Build/Buildable.swift
> edit: Sources/Build/Command.compile(ClangModule).swift
> edit: Sources/PackageGraph/PackageGraphLoader.swift
> edit: Sources/PackageModel/Module.swift
> edit: Sources/Build/describe().swift
> edit: Sources/Xcodeproj/Module+PBXProj.swift
> edit: Sources/PackageLoading/ModuleMapGeneration.swift
> 
> Commit 790d4b5e78fadbcc54011f4dc35de2a42ccc1497 by ankit.spd:
> [PackageLoading] Remove unnecessary if condition
> 
> edit: Sources/PackageLoading/PackageBuilder.swift
> 
> Commit 7eeb64a3360475c0c9e4231f9b4f3c7f4174c0d1 by ankit.spd:
> [PackageLoadingTests] Increase PackageBuilder unit test coverage
> 
> edit: Tests/PackageLoading/ConventionTests.swift
> 
> Commit 23d8c74abf1e6bb8c76b3a85d23358e985328474 by ankit.spd:
> [PackageModel] Make product type equatable
> 
> edit: Sources/PackageModel/Product.swift
> 
> Commit 41e4f5642ef4aa2d118c8790b2e7c583ada7bcbb by ankit.spd:
> [PackageBuilderTests] Test products
> 
> edit: Tests/PackageLoading/ConventionTests.swift
> 
> Commit 77ef84bbd1eb80c6477f2a6c3940f6edbd06031c by ankit.spd:
> [PackageBuilderTests] Add a missing target dependency testcase
> 
> edit: Tests/PackageLoading/ConventionTests.swift
> 
> Commit 0621ebc77d8ee6991e63b3d4934ba42de1b41a02 by github:
> Update tests for SE-0025 ('private' and 'fileprivate') (#37)
> 
> edit: 
> packages/Python/lldbsuite/test/lang/swift/partially_generic_func/continuations/main.swift
> edit: packages/Python/lldbsuite/test/lang/swift/private_self/main.swift
> edit: packages/Python/lldbsuite/test/lang/swift/private_typealias/main.swift
> edit: 
> packages/Python/lldbsuite/test/lang/swift/cross_module_extension/moda.swift
> edit: packages/Python/lldbsuite/test/lang/swift/private_decl_name/a.swift
> edit: 
> packages/Python/lldbsuite/test/lang/swift/cross_module_extension/modb.swift
> edit: packages/Python/lldbsuite/test/lang/swift/resilienc

Re: [swift-dev] End of source-breaking changes for Swift 3

2016-07-27 Thread Andrew Trick via swift-dev

> On Jul 27, 2016, at 1:21 PM, Jordan Rose via swift-dev  
> wrote:
> 
>> SE-0107 - UnsafeRawPointer API 
>> Andy
>>  has been working on this.

I still need to land one major source-breaking for UnsafePointer conversion, 
along with a sweeping stdlib update. However, I can’t land those until I’ve 
updated corelibs and other repositories.

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

[swift-dev] Anyone running build-toolchain on linux?

2016-07-28 Thread Andrew Trick via swift-dev

I need to push corelibs changes in today but I’m running into problems testing 
the full Swift toolchain on linux. build-toolchain stops after attempting to 
run swiftpm tests and hitting the failure shown below.

Anyone else seeing issues running build-toolchain?

As of:

commit cb0b4588a6a8bf80dc0efa52857df62f361e81d5 (HEAD -> master, origin/master, 
origin/HEAD)
Merge: 9bb96ee 77ef84b
Author: Daniel Dunbar 
Date:   Wed Jul 27 08:47:50 2016

Merge branch 'more-convention-tests' of 
https://github.com/aciidb0mb3r/swift-package-manager

---
Test Case 'ClangModulesTestCase.testCUsingCDep2' started at 10:23:02.222
Building Debug
 FAILURE EXECUTING SUBPROCESS 
command: 
/home/atrick/s/build/buildbot_linux/swiftpm-linux-x86_64/debug/swift-build 
--chdir /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Bar 
--configuration debug
SWIFT_EXEC: nil
output: Cloning /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Foo
HEAD is now at f42e04e msg
Resolved version: 1.2.3
Compile Foo Foo.c
Linking Foo
Compile SeaLover Sea.c
Compile Swift Module 'SwiftExec' (1 sources)
/tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Bar/Sources/SeaLover/Sea.c:1:10:
 fatal error: could not acquire lock file for module 'Foo'
#include 
 ^
1 error generated.
:0: error: build had 1 command failures
swift-build: error: exit(1): 
/home/atrick/s/build/buildbot_linux/swiftpm-linux-x86_64/debug/swift-build-tool 
-f /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Bar/.build/debug.yaml

/home/atrick/s/swiftpm/Tests/Functional/ClangModuleTests.swift:96: error: 
ClangModulesTestCase.testCUsingCDep2 : failed - `swift build -c Debug' failed:

exit(1): 
/home/atrick/s/build/buildbot_linux/swiftpm-linux-x86_64/debug/swift-build 
--chdir /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Bar 
--configuration debug

--- bootstrap: error: tests failed with exit status 1
./utils/build-script: fatal error: command terminated with a non-zero exit 
status 1, aborting

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

Re: [swift-dev] Anyone running build-toolchain on linux?

2016-07-28 Thread Andrew Trick via swift-dev

Thanks Ben.

Daniel’s command works for me:
build-script -R --llbuild --foundation --xctest -t

But doesn’t build all the projects.

-Andy

> On Jul 28, 2016, at 9:39 AM, Ben Langmuir  wrote:
> 
> That error indicates some kind of filesystem issue in the module cache 
> directory - no permissions, out of space, the directory has been removed by 
> some other process, etc.  +Bruno who was looking at making this error more 
> specific.
> 
> Ben
> 
>> On Jul 28, 2016, at 9:29 AM, Daniel Dunbar  wrote:
>> 
>> I don't run build toolchain myself (I have my own scripts for assembling 
>> one), but I run `build-script -R --llbuild --foundation --xctest -t` without 
>> issue.
>> 
>> +Jordan, Ben for what situations could cause the actual error we are hitting 
>> there.
>> 
>> - Daniel
>> 
>>> On Jul 28, 2016, at 9:27 AM, Andrew Trick  wrote:
>>> 
>>> I need to push corelibs changes in today but I’m running into problems 
>>> testing the full Swift toolchain on linux. build-toolchain stops after 
>>> attempting to run swiftpm tests and hitting the failure shown below.
>>> 
>>> Anyone else seeing issues running build-toolchain?
>>> 
>>> As of:
>>> 
>>> commit cb0b4588a6a8bf80dc0efa52857df62f361e81d5 (HEAD -> master, 
>>> origin/master, origin/HEAD)
>>> Merge: 9bb96ee 77ef84b
>>> Author: Daniel Dunbar 
>>> Date:   Wed Jul 27 08:47:50 2016
>>> 
>>>  Merge branch 'more-convention-tests' of 
>>> https://github.com/aciidb0mb3r/swift-package-manager
>>> 
>>> ---
>>> Test Case 'ClangModulesTestCase.testCUsingCDep2' started at 10:23:02.222
>>>  Building Debug
>>>  FAILURE EXECUTING SUBPROCESS 
>>> command: 
>>> /home/atrick/s/build/buildbot_linux/swiftpm-linux-x86_64/debug/swift-build 
>>> --chdir /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Bar 
>>> --configuration debug
>>> SWIFT_EXEC: nil
>>> output: Cloning /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Foo
>>> HEAD is now at f42e04e msg
>>> Resolved version: 1.2.3
>>> Compile Foo Foo.c
>>> Linking Foo
>>> Compile SeaLover Sea.c
>>> Compile Swift Module 'SwiftExec' (1 sources)
>>> /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Bar/Sources/SeaLover/Sea.c:1:10:
>>>  fatal error: could not acquire lock file for module 'Foo'
>>> #include 
>>>   ^
>>> 1 error generated.
>>> :0: error: build had 1 command failures
>>> swift-build: error: exit(1): 
>>> /home/atrick/s/build/buildbot_linux/swiftpm-linux-x86_64/debug/swift-build-tool
>>>  -f 
>>> /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Bar/.build/debug.yaml
>>> 
>>> /home/atrick/s/swiftpm/Tests/Functional/ClangModuleTests.swift:96: error: 
>>> ClangModulesTestCase.testCUsingCDep2 : failed - `swift build -c Debug' 
>>> failed:
>>> 
>>> exit(1): 
>>> /home/atrick/s/build/buildbot_linux/swiftpm-linux-x86_64/debug/swift-build 
>>> --chdir /tmp/DependencyResolution_External_CUsingCDep2.5dXdqO/Bar 
>>> --configuration debug
>>> 
>>> --- bootstrap: error: tests failed with exit status 1
>>> ./utils/build-script: fatal error: command terminated with a non-zero exit 
>>> status 1, aborting
>>> 
>> 
> 

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

[swift-dev] Anyone fixing TestNSJSONSerialization?

2016-07-28 Thread Andrew Trick via swift-dev

Is anyone looking at this failure that’s blocking CI?

https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6576/

TestFoundation/TestNSJSONSerialization.swift:301: error: 
TestNSJSONSerialization.test_deserialize_unicodeEscapeSequence : XCTAssertEqual 
failed: ("Optional("â¨")") is not equal to 
("Optional("Optional(\"\\u{2728}\")")") - 

After
[stdlib] Rename flatten() to joined() (SE-0133) — jacob 
 / detail 

Add benchmark for iterating Data — kevin.ballard 
 / detail 

Implement a custom Data.Iterator — kevin.ballard 
 / detail 

[stdlib] Update doc comments for SE-0133 — jacob 
 / detail 

[stdlib][SE-0089] Finish off Lossless String Conversion (#3761) — kremenek 
 / detail 

Cleanup validation tests after SE-0089 — devteam.codafi 
 / detail 

vim: add support for 'fileprivate' — gribozavr 
 / detail 

Revert "Implement a custom Data.Iterator" (#3848) — github 
 / detail 

Keep cleaning up — devteam.codafi  / 
detail 

Updates for SE-0089 — devteam.codafi 
 / detail 

Updates for SE-0089 — devteam.codafi 
 / detail 

Minor update for SE-0089 — devteam.codafi 
 / detail 


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

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

2016-07-29 Thread Andrew Trick via swift-dev

This turned out to be a spurious system failure. I unnecessarily reverted and 
reapplied my patch.

-Andy

> On Jul 29, 2016, at 12:37 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6946]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6946/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Fri, 29 Jul 2016 00:30:31 -0700
> Build duration:   7 min 4 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 1 test(s), Passed: 8180 test(s), Total: 8181 test(s)
> Failed: Swift(linux-x86_64).AutolinkExtract.import_archive.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit fbf8f362114788412a011dfe5a2cd5442d43ed4b by atrick:
> UnsafePointer conversion fixes.
> 
> edit: Foundation/String.swift
> edit: TestFoundation/TestNSKeyedArchiver.swift
> edit: TestFoundation/TestNSValue.swift
> edit: TestFoundation/TestNSJSONSerialization.swift
> edit: Foundation/Data.swift
> edit: Foundation/NSRegularExpression.swift
> edit: Foundation/NSURL.swift
> edit: TestFoundation/TestNSTask.swift
> edit: Foundation/NSXMLElement.swift
> edit: Foundation/NSXMLParser.swift
> edit: Foundation/NSFileManager.swift
> edit: TestFoundation/TestNSData.swift
> edit: TestFoundation/TestNSStream.swift
> edit: Foundation/NSString.swift
> edit: Foundation/NSJSONSerialization.swift
> edit: TestFoundation/TestNSFileManager.swift

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

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

2016-07-29 Thread Andrew Trick via swift-dev

I must be building differently from the CI bot, because I’m hitting these 
failures trying to build playground support. I tried to fix the CI just by 
looking at the build log...

/s/sptr/swift-xcode-playground-support/PlaygroundLogger/PlaygroundLogger_TestDriver/main.swift:19:1:
 error: use of unresolved identifier 'playground_logger_test'
playground_logger_test()
^~
:0: error: type 'CTFontManagerError' does not conform to protocol 
'__BridgedNSError'
Foundation.__BridgedNSError:4:23: note: protocol requires property 
'_nsErrorDomain' with type 'String'; do you want to add a stub?
public static var _nsErrorDomain: String { get }
  ^
:0: error: type 'CTFontManagerError' does not conform to protocol 
'Equatable'
Swift.Equatable:149:24: note: protocol requires function '==' with type 
'(CTFontManagerError, CTFontManagerError) -> Bool'; do you want to add a stub?
public static func ==(lhs: Self, rhs: Self) -> Bool
   ^

> On Jul 29, 2016, at 2:11 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#5575]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5575/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Fri, 29 Jul 2016 01:59:37 -0700
> Build duration:   11 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit 3f890081a73a57aa6d16c1e22d0545def1d01cd6 by atrick:
> Disallow illegal UnsafePointer conversions. (#3858)
> 
> edit: stdlib/public/core/UnsafePointer.swift.gyb

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

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

2016-07-29 Thread Andrew Trick via swift-dev

I fixed this playground logger build error, but it looks like this run didn’t 
pickup the fix yet.
-Andy

> On Jul 29, 2016, at 3:03 AM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-osx [#5577]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5577/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Fri, 29 Jul 2016 02:35:27 -0700
> Build duration:   28 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit a4eaaca9fe394a82719a0613e8951bdd4b390fe7 by atrick:
> Speculative update for UnsafeRawPointer.
> 
> edit: PlaygroundLogger/PlaygroundLogger/ExtensionFloat.swift
> edit: PlaygroundLogger/PlaygroundLogger/BytesStorage.swift
> edit: PlaygroundLogger/PlaygroundLogger/ExtensionDouble.swift
> edit: PlaygroundLogger/PlaygroundLogger/ExtensionUInt64.swift
> 
> Commit ca440c615f01a1f2067cdd4f10327f3da81b2b96 by dgregor:
> [SE-0111] Disallow function types with argument labels.
> 
> edit: test/Sema/suppress-argument-labels-in-types.swift
> add: test/type/tuple/labels.swift
> edit: test/IDE/complete_type.swift
> edit: include/swift/AST/DiagnosticsParse.def
> add: test/type/function/labels.swift
> edit: lib/Parse/ParseType.cpp
> 
> Commit 34791770844b97cab80b6ac6432d9100b72719d3 by dgregor:
> [SE-0111] Propagate function reference kinds when building member
> 
> edit: test/Sema/suppress-argument-labels-in-types.swift
> edit: lib/Sema/CSApply.cpp
> edit: test/SILGen/protocol_extensions.swift
> 
> Commit f82f9fb7a2c236448b5bdb87ff17f34521d09d4d by dgregor:
> [SE-0111 SILGen] Dropping labels can make TupleTypes disappear; deal
> 
> edit: lib/SILGen/SILGenPoly.cpp
> edit: test/SILGen/partial_apply_init.swift
> edit: test/SILGen/generic_closures.swift

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

Re: [swift-dev] What exactly does it mean for a Swift pointer to be initialized?

2016-08-05 Thread Andrew Trick via swift-dev

> On Aug 5, 2016, at 12:43 PM, Jens Persson  wrote:
> 
> I'm trying to understand the new Swift 3 (4?) pointer API and Swift's memory 
> model.
> 
> More specifically, I'd like to know more about what exactly it means for a 
> pointer to be initialized or not.
> 
> For example, I suppose the following code example doesn't satisfy the 
> precondition in the subscript documentation (ie floatsPtr not being 
> initialized when using its subscript):
> 
> let numFloats = 123
> let floatsPtr = UnsafeMutablePointer.allocate(capacity: numFloats)
> for i in 0 ..< numFloats { floatsPtr[i] = Float(i) * 0.1 } // Setting values
> for i in 0 ..< numFloats { print(floatsPtr[i]) } // Getting values
> floatsPtr.deallocate(capacity: numFloats)
> 
> I'd like to understand why/how this could lead to undefined behavior, and 
> what exactly it means for a pointer to be initialized or not.
> 
> I've read 
> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
>  
> 
> 
> But I don't feel that I fully understand what it means for a pointer to be 
> initialized, or bound, and if the preconditions and rules for undef behavior 
> are the same no matter if Pointee is a trivial type or a class type. 

I think it’s common practice to initialize trivial types via subscript 
assignment. Earlier versions of the proposal actually showed examples of this 
and claimed that it was valid pattern. However, during review those examples 
were removed because it encouraged bad practice and complicated the issue.

The fact is, code like this is not going to break anything in the compiler and 
it’s common enough that any model model verifier is going to need to 
special-case trivial types. I think it would be fine to rewrite the subscript 
precondition as follows:

/// - Precondition: the pointee at `self + i` is initialized.
should read
/// - Precondition: either the pointee at `self + i` is initialized
///   or `Pointee` is a trivial type.

https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#trivial-types

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

Re: [swift-dev] What exactly does it mean for a Swift pointer to be initialized?

2016-08-06 Thread Andrew Trick via swift-dev


> On Aug 5, 2016, at 10:42 PM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> on Fri Aug 05 2016, Andrew Trick  > wrote:
> 
>>> On Aug 5, 2016, at 12:43 PM, Jens Persson  wrote:
>>> 
>>> I'm trying to understand the new Swift 3 (4?) pointer API and Swift's 
>>> memory model.
>>> 
>>> More specifically, I'd like to know more about what exactly it means
>> 
>>> for a pointer to be initialized or not.
>>> 
>>> For example, I suppose the following code example doesn't satisfy
>>> the precondition in the subscript documentation (ie floatsPtr not
>>> being initialized when using its subscript):
>>> 
>>> let numFloats = 123
>>> let floatsPtr = UnsafeMutablePointer.allocate(capacity: numFloats)
>>> for i in 0 ..< numFloats { floatsPtr[i] = Float(i) * 0.1 } // Setting values
>>> for i in 0 ..< numFloats { print(floatsPtr[i]) } // Getting values
>>> floatsPtr.deallocate(capacity: numFloats)
>>> 
>>> I'd like to understand why/how this could lead to undefined
>>> behavior, and what exactly it means for a pointer to be initialized
>>> or not.
>>> 
>>> I've read
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
>>> >>  
>>> >
>>> 
>>> But I don't feel that I fully understand what it means for a pointer
>>> to be initialized, or bound, and if the preconditions and rules for
>>> undef behavior are the same no matter if Pointee is a trivial type
>>> or a class type.
>> 
>> I think it’s common practice to initialize trivial types via subscript
>> assignment. Earlier versions of the proposal actually showed examples
>> of this and claimed that it was valid pattern. However, during review
>> those examples were removed because it encouraged bad practice and
>> complicated the issue.
>> 
>> The fact is, code like this is not going to break anything in the
>> compiler and it’s common enough that any model model verifier is going
>> to need to special-case trivial types. I think it would be fine to
>> rewrite the subscript precondition as follows:
>> 
>> /// - Precondition: the pointee at `self + i` is initialized.
>> should read
>> /// - Precondition: either the pointee at `self + i` is initialized
>> ///   or `Pointee` is a trivial type.
> 
> Depending on where you intend to make this change, you may be implicitly
> adding the requirement that every possible bit pattern is a valid
> representation of a trivial type.  It's fine if you're just changing the
> setters for pointee and subscript, but it shouldn't apply to the
> getters, IMO.

We do not want to allow reading trivial values from uninitialized memory.
I took a crack at the comments:
https://github.com/apple/swift/pull/4070 


-Andy

>> 
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#trivial-types
>>  
>> 
>> 
>> -Andy
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
>> 
> 
> -- 
> -Dave
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Rebinding UnsafePointer makes it mutable

2016-09-19 Thread Andrew Trick via swift-dev


> On Sep 19, 2016, at 1:24 AM, Martin R via swift-dev  
> wrote:
> 
> I noticed that both UnsafePointer and UnsafeMutablePointer have the identical 
> method
> 
>public func withMemoryRebound(to: T.Type, capacity count: Int, 
> _ body: (UnsafeMutablePointer) throws -> Result) rethrows -> Result
> 
> so that rebinding an immutable pointer gives you a _mutable_ pointer. That is 
> different from what
> 
>Unsafe[Mutable]Pointer {
>  func withMemoryRebound(to: T.Type, capacity count: Int,
>_ body: (Unsafe[Mutable]Pointer) throws -> ()) rethrows
>}
> 
> in 
> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
>  indicates. Perhaps I am misunderstanding something. Shouldn't rebinding an 
> UnsafePointer result in an UnsafePointer again?
> 
> Martin

You’re right. There is an inconsistency between the proposal and Swift 3 
implementation. I’ve been thinking about whether it makes more sense to correct 
this sooner or later. I responded in more detail on swift-evolution.

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

Re: [swift-dev] Representing "address-only" values in SIL

2016-10-03 Thread Andrew Trick via swift-dev


> On Oct 3, 2016, at 12:10 PM, Alexis via swift-dev  wrote:
> 
> When I first started reading this proposal, my primary objection was going to 
> be that SSA doesn’t seem to really jive well with the idea of values becoming 
> (in)valid at some point in the future (due to moves). You can see this in the 
> definite-init pass, which it works entirely with addresses to handle the idea 
> of a value which becomes assigned “eventually”. But if SIL’s notion of SSA 
> can be extended to handle these problems, this sounds great!
> 
> It’s not clear to me how this would work though. How does an optimization 
> pass reason about an SSA register becoming invalid because it was moved out 
> of? Or rather: in what ways do the interesting properties of SSA survive 
> passes needing to handle this? Is this a standard extension that’s been 
> researched/implemented before?

I think that’s why John claimed that we need to enforce “pseudo-linear” SIL 
values types. Moving out of an SSA value must be the last use of that value. 
SIL will enforce this single-consumer property throughout.

-Andy

> 
>> On Oct 1, 2016, at 4:32 AM, John McCall via swift-dev > > wrote:
>> 
>> Andy Trick and I had this conversation Thursday, and I thought I'd capture 
>> it here.
>> 
>> The Problem
>> 
>> It's a longstanding complaint that SIL uses drastically different code 
>> patterns for the same sequence of operations based on whether the types of 
>> the values involved are loadable or "address-only".  For example, suppose I 
>> have Swift code like this:
>>   let x, y : T
>>   let z = x + y
>> 
>> If T is a loadable type, this will generate SIL somewhat like this:
>>  // %x and %y are values of type $T
>> %lhs = copy_value %x
>> %rhs = copy_value %y
>>  %operator = function_ref T.+
>>  %result = apply %operator(%lhs, %rhs)
>>  %z = %result
>> 
>> (copy_value doesn't currently exist, but it's easier to understand, and as 
>> it happens we're thinking of adding it back.)
>> 
>> If T is an address-only type, this will generate SIL somewhat like this:
>>   // %x and %y are values of type $*T
>>   %z = alloc_stack $T
>>   %lhs = alloc_stack $T
>>   copy_addr %x to [initialization] %lhs
>>   %rhs = alloc_stack $T
>>   copy_addr %y to [initialization] %rhs
>>   %operator = function_ref T.+
>>   apply %operator(%z, %lhs, %rhs)
>>   dealloc_stack %rhs
>>   dealloc_stack %lhs
>> 
>> Notably, we're explicitly modeling the memory in which values are stored, 
>> which is both very verbose and — more importantly — loses any interesting 
>> SSA properties for tracking actual values around.  And this has a bunch of 
>> secondary effects where various high-level operations like dynamic casts end 
>> up needing two different instructions based on whether the value is stored 
>> in memory.  This is pretty dumb, and it's a major contributor to the reality 
>> that generic code is currently very poorly optimized.
>> 
>> It does, however, have some significant advantages: since the memory 
>> allocation is explicit, it's quite natural to express optimizations that 
>> e.g. hoist or sink those allocations, and the next level of lowering (IRGen) 
>> can be very simple.
>> 
>> Addresses and address-only types
>> 
>> Swift is an imperative language, and imperative languages make formal memory 
>> locations part of the high-level semantics.  DI and SSA formation allow us 
>> to eliminate formal memory locations for most local variables, but class 
>> properties, global variables, escaped local variables, and pointers are all 
>> fundamentally un-SSA-able.  Therefore we will always have some concept of an 
>> address.
>> 
>> But most values of address-only type aren't really being stored in that sort 
>> of formal memory location; we're just representing them that way in SIL.  
>> Why do we do this?  What is it about a type that makes it address-only?
>> 
>> Well, some types are inherently "memory-pinned": something about their 
>> representation only makes sense, or is only implementable, if the value is 
>> always kept in memory:
>>   - The representation of the value may involve interior pointers, as with 
>> LLVM's SmallVector.  This isn't currently a thing in Swift, but it's a 
>> possibility someday with the import of non-POD C++ types.
>>   - The address of the value may need to be registered elsewhere, as with 
>> weak references.
>>   - The value may allow internal mutation even from a shared reference, like 
>> a C++ class with a mutable field or a Rust atomic type; you can see weak 
>> references as analogous to this.
>> Such types are necessarily address-only at a low level.
>> 
>> Other types are address-only by abstraction: their representation isn't 
>> (fully) known, and so they have to be kept in memory (1) in case that 
>> representation includes another address-only value and (2) because there's 
>> no way to store a unbounded amount of data except in memory anyway.
>> 
>> But this sense of address-only types that we're

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

2016-10-07 Thread Andrew Trick via swift-dev

> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
>> I wonder whether it might make more sense for load [borrow] to be a 
>> different instruction.
>> There's a couple reasons for that first.  The first is that it's the only 
>> load which introduces
>> a scope, which is a really big difference structurally.  The second is that 
>> it's the only load
>> which returns a non-owned value, which will be a typing difference when we 
>> record
>> ownership in the type system.
> 
> I am fine with a load_borrow. If this is the only change left that you want 
> can I just send out a proposal with that small change and start implementing. 
> I am nervous about perfection being the enemy of the good (and I want to 
> start implementing this weekend if possible *evil smile*).

There’s a lot in the proposal that makes sense to discuss for completeness but 
isn’t motivated by a particular need. Please separate functionality. We only 
need load [copy] at first right? When do those need to be promoted to 
load_borrow? load [trivial] is an optimization, so that should follow a 
functionally complete implementation.  load [take] should definitely not exist 
until there’s some motivation.

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

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

2016-10-07 Thread Andrew Trick via swift-dev


> On Oct 7, 2016, at 10:08 PM, Michael Gottesman  wrote:
> 
>> 
>> On Oct 7, 2016, at 9:25 PM, Andrew Trick > > wrote:
>> 
>> 
>>> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
 I wonder whether it might make more sense for load [borrow] to be a 
 different instruction.
 There's a couple reasons for that first.  The first is that it's the only 
 load which introduces
 a scope, which is a really big difference structurally.  The second is 
 that it's the only load
 which returns a non-owned value, which will be a typing difference when we 
 record
 ownership in the type system.
>>> 
>>> I am fine with a load_borrow. If this is the only change left that you want 
>>> can I just send out a proposal with that small change and start 
>>> implementing. I am nervous about perfection being the enemy of the good 
>>> (and I want to start implementing this weekend if possible *evil smile*).
>> 
>> There’s a lot in the proposal that makes sense to discuss for completeness 
>> but isn’t motivated by a particular need. Please separate functionality. We 
>> only need load [copy] at first right? When do those need to be promoted to 
>> load_borrow?
> 
> These are needed for the ARC optimizer to eliminate retain, release 
> operations, i.e. a:
> 
> %0 = load [copy] %x_ptr
> 
> destroy_value %1
> 
> =>
> 
> %0 = load [borrow] %x_ptr
> 
> borrow_end(%0, %x_ptr)
> 
> These constructs will be needed by engineers to update passes like ARC. By 
> implementing such modifiers now, we can begin to implement support in the 
> various passes for these new instructions via sil-opt/etc in parallel to 
> other semantic ARC work.
> 
>> load [trivial] is an optimization, so that should follow a functionally 
>> complete implementation. 
> 
> Yes you are correct that given that we are exploding the load [copy] in the 
> eliminator, the trivial load is not *strictly* needed. But as soon as we 
> start upgrading passes, we are going to want this. Again assuming that 
> parallel work can be done, it makes sense to set the stage for optimizer work 
> that will occur in parallel to further semantic ARC work.
> 
>>  load [take] should definitely not exist until there’s some motivation.
> 
> If you look at the frontend, there are places where the frontend wants to 
> emit a take. Unless we are willing to use unqualified loads for those cases 
> (which we can not if we are trying to prove that no unqualified loads are 
> emitted by the frontend), then we must have a load [take].
> 
> Did I provide the motivation that you requested?

Yes. My general request is for each commit to be easy to review and the 
functionality obvious to test. I’m convinced we’ll eventually want the 
variants. Although I still want to understand better when we need to [take] 
values out of memory.

I also want to prove that my understanding of the model is accurate by seeing 
everything work with load [copy].

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

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

2016-10-07 Thread Andrew Trick via swift-dev


> On Oct 7, 2016, at 10:36 PM, Michael Gottesman  wrote:
> 
>> 
>> On Oct 7, 2016, at 10:26 PM, Andrew Trick > > wrote:
>> 
>> 
>>> On Oct 7, 2016, at 10:08 PM, Michael Gottesman >> > wrote:
>>> 
 
 On Oct 7, 2016, at 9:25 PM, Andrew Trick >>> > wrote:
 
 
> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> 
>> I wonder whether it might make more sense for load [borrow] to be a 
>> different instruction.
>> There's a couple reasons for that first.  The first is that it's the 
>> only load which introduces
>> a scope, which is a really big difference structurally.  The second is 
>> that it's the only load
>> which returns a non-owned value, which will be a typing difference when 
>> we record
>> ownership in the type system.
> 
> I am fine with a load_borrow. If this is the only change left that you 
> want can I just send out a proposal with that small change and start 
> implementing. I am nervous about perfection being the enemy of the good 
> (and I want to start implementing this weekend if possible *evil smile*).
 
 There’s a lot in the proposal that makes sense to discuss for completeness 
 but isn’t motivated by a particular need. Please separate functionality. 
 We only need load [copy] at first right? When do those need to be promoted 
 to load_borrow?
>>> 
>>> These are needed for the ARC optimizer to eliminate retain, release 
>>> operations, i.e. a:
>>> 
>>> %0 = load [copy] %x_ptr
>>> 
>>> destroy_value %1
>>> 
>>> =>
>>> 
>>> %0 = load [borrow] %x_ptr
>>> 
>>> borrow_end(%0, %x_ptr)
>>> 
>>> These constructs will be needed by engineers to update passes like ARC. By 
>>> implementing such modifiers now, we can begin to implement support in the 
>>> various passes for these new instructions via sil-opt/etc in parallel to 
>>> other semantic ARC work.
>>> 
 load [trivial] is an optimization, so that should follow a functionally 
 complete implementation. 
>>> 
>>> Yes you are correct that given that we are exploding the load [copy] in the 
>>> eliminator, the trivial load is not *strictly* needed. But as soon as we 
>>> start upgrading passes, we are going to want this. Again assuming that 
>>> parallel work can be done, it makes sense to set the stage for optimizer 
>>> work that will occur in parallel to further semantic ARC work.
>>> 
  load [take] should definitely not exist until there’s some motivation.
>>> 
>>> If you look at the frontend, there are places where the frontend wants to 
>>> emit a take. Unless we are willing to use unqualified loads for those cases 
>>> (which we can not if we are trying to prove that no unqualified loads are 
>>> emitted by the frontend), then we must have a load [take].
>>> 
>>> Did I provide the motivation that you requested?
>> 
>> Yes. My general request is for each commit to be easy to review and the 
>> functionality obvious to test. I’m convinced we’ll eventually want the 
>> variants. Although I still want to understand better when we need to [take] 
>> values out of memory.
> 
> Just as a quick example, the API for emitLoad in SILGenFunction:
> 
>   ManagedValue emitLoad(SILLocation loc, SILValue addr,
> const TypeLowering &rvalueTL,
> SGFContext C, IsTake_t isTake,
> bool isGuaranteedValid = false);
> 
> Notice the IsTake_t parameter. I see that code path used in several locations 
> in SILGenFunction.

I guess it’s doing this to forward locals variables at their last use, avoiding 
a copy. Although probably not theoretically necessary, I guess it would be 
silly not to do this.
-Andy

>> 
>> I also want to prove that my understanding of the model is accurate by 
>> seeing everything work with load [copy].
> 
> I am fine doing everything initially with load [copy] (and when SILGen 
> requires load [take]). The other things can wait until we need them. I just 
> don't want to have to do another proposal at that point ; ).
> 
>> 
>> -Andy

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

[swift-dev] [discussion notes] SIL address types and borrowing

2016-10-07 Thread Andrew Trick via swift-dev

On swift-dev, John already sent out a great writeup on SIL SSA:
Representing "address-only" values in SIL.

While talking to John I also picked up a lot of insight into how
address types relate to SIL ownership and borrow checking. I finally
organized the information into these notes. This is not a
proposal. It's background information for those of us writing and
reviewing proposals. Just take it as a strawman for future
discussions. (There's also a good chance I'm getting something
wrong).

[My commentary in brackets.]

** Recap of address-only.

Divide address-only types into two categories:
1. By abstraction (compiler doesn't know the size).
2. The type is "memory-linked". i.e. the address is significant at runtime.
   - weak references (anything that registers its address).
   - C++ this.
   - Anything with interior pointers.
   - Any shared-borrowed value of a type with "nonmutating" properties.
 ["nonmutating" properties allow mutation of state attached to a value.
  Rust atomics are an example.]

Address-only will not be reflected in SIL types. SIL addresses should
only be used for formal memory (pointers, globals, class
properties, captures). We'll get to inout arguments later...

As with opaque types, when IRGen lowers a memory-linked borrowed type,
it needs to allocate storage.

Concern: SILGen has built-in tracking of managed values that automates
insertion of cleanups. Lowering address-only types after SILOpt would
require rediscovering that information based on CFG analysis. Is this
too heroic?

This was already described by John. Briefly recapping:

e.g. Constructung Optional

We want initialization should be in-place as such:

%0 = struct_element_addr .. #S.any
%1 = init_existential_addr %0, $*Any, $Optional
%2 = inject_enum_data_addr %1, $Optional.Some
apply @initX(%2)

SILValue initialization would look something like:

%0 = apply @initX()
%1 = enum #Optional.Some, %0 : $X
%2 = existential %1 : $Any

[I'm not sure we actually want to represent an existential container
this way, but enum, yes.]

Lowering now requires discovering the storage structure, bottom-up,
hoisting allocation, inserting cleanups as John explained.

Side note: Before lowering, something like alloc_box would directly
take its initial value.

** SILFunction calling convention.

For ownership analysis, there's effectively no difference between the
value/address forms of argument ownership:

@owned  / @in
@guaranteed / @in_guaranteed
return  / @out
@owned arg
+ @owned return / @inout

Regardless of the representation we choose for @inout, @in/@out will
now be scalar types. SILFunction will maintain the distinction between
@owned/@in etc. based on whether the type is address-only. We need
this for reabstraction, but it only affects the function type, not the
calling convention.

Rather than building a tuple, John prefers SIL support for anonymous
aggregate as "exploded values".

[I'm guessing because tuples are a distinct formal type with their own
convention and common ownership. This may need some discussion though.]

Example SIL function type:

$(@in P, @owned Q) -> (@owned R, @owned S, @out T, @out U)

%p = apply f: $() -> P
%q = apply g: $() -> Q
%exploded = apply h(%p, %q)
%r = project_exploded %exploded, #0 : $R
%s = project_exploded %exploded, #1 : $S
%t = project_exploded %exploded, #2 : $T
%u = project_exploded %exploded, #3 : $U

Exploded types requires all their elements to be projected with their
own independent ownership.

** Ownership terminology.

Swift "owned"= Rust values   = SIL @owned  = implicitly consumed
Swift "borrowed" = Rust immutable borrow = SIL @guaranteed = shared
Swift "inout"= Rust mutable borrow   = SIL @inout  = unique

Swift "inout" syntax is already (nearly) sufficient.

"borrowed" may not need syntax on the caller side, just a way to
qualify parameters. Swift still needs syntax for returning a borrowed
value.

** Representation of borrowed values.

Borrowed values represent some shared storage location.

We want some borrowed value references to be passed as SIL values, not SIL 
addresses:
- Borrowed class references should not be indirected.
- Optimize borrowing other small non-memory linked types.
- Support capture promotion, and other SSA optimizations.
- Borrow CoW values directly.

[Address-only borrowed types will still be passed as SIL addresses (why not?)]

Borrowed types with potentially mutating properties must be passed by
SIL address because they are not actually immutable and their storage
location is significant.

Borrowed references have a scope and need an end-of-borrow marker.

[The end-of-borrow marker semantically changes the memory state, and
statically enforces non-overlapping memory states. It does not
semantically write-back a value. Borrowed values with mutating fields
are semantically modified in-place.]

[Regardless of whether borrowed references are represented as SIL
values or addresses, they must be associat

Re: [swift-dev] [discussion notes] SIL address types and borrowing

2016-10-08 Thread Andrew Trick via swift-dev


> On Oct 8, 2016, at 10:09 AM, Karl  wrote:
> 
> Could you add this (and John’s previous writeup) to the docs in the repo?

Yeah, it’s unfortunate that design discussions are buried in a flood of email. 
On the flip side, I’ve checked in some premature design docs that are probably 
nonsense now. I’m currently preparing a type safe memory model design doc to 
checkin. After that I’ll probably work on a document for SIL SSA with 
address-only types, which should cover John’s writeup. I’ll have to work with 
Michael Gottesman and John McCall to get a SIL ownership docs checked in.

> I was reasonably along the way to adding unowned optionals a while back but 
> got totally lost in SILGen.
> This info looks really valuable, but personally I find that with the mailing 
> list format it’s hard to ever find this kind of stuff when I need it.
> 
> Thanks
> 
> Karl
> 
> P.S. going to pick up that unowned optional stuff soon, once I have time to 
> read the docs about SILGen

There are SILGen docs somewhere?

-Andy

> 
>> On 8 Oct 2016, at 08:10, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> On swift-dev, John already sent out a great writeup on SIL SSA:
>> Representing "address-only" values in SIL.
>> 
>> While talking to John I also picked up a lot of insight into how
>> address types relate to SIL ownership and borrow checking. I finally
>> organized the information into these notes. This is not a
>> proposal. It's background information for those of us writing and
>> reviewing proposals. Just take it as a strawman for future
>> discussions. (There's also a good chance I'm getting something
>> wrong).
>> 
>> [My commentary in brackets.]
>> 
>> ** Recap of address-only.
>> 
>> Divide address-only types into two categories:
>> 1. By abstraction (compiler doesn't know the size).
>> 2. The type is "memory-linked". i.e. the address is significant at runtime.
>>- weak references (anything that registers its address).
>>- C++ this.
>>- Anything with interior pointers.
>>- Any shared-borrowed value of a type with "nonmutating" properties.
>>  ["nonmutating" properties allow mutation of state attached to a value.
>>   Rust atomics are an example.]
>> 
>> Address-only will not be reflected in SIL types. SIL addresses should
>> only be used for formal memory (pointers, globals, class
>> properties, captures). We'll get to inout arguments later...
>> 
>> As with opaque types, when IRGen lowers a memory-linked borrowed type,
>> it needs to allocate storage.
>> 
>> Concern: SILGen has built-in tracking of managed values that automates
>> insertion of cleanups. Lowering address-only types after SILOpt would
>> require rediscovering that information based on CFG analysis. Is this
>> too heroic?
>> 
>> This was already described by John. Briefly recapping:
>> 
>> e.g. Constructung Optional
>> 
>> We want initialization should be in-place as such:
>> 
>> %0 = struct_element_addr .. #S.any
>> %1 = init_existential_addr %0, $*Any, $Optional
>> %2 = inject_enum_data_addr %1, $Optional.Some
>> apply @initX(%2)
>> 
>> SILValue initialization would look something like:
>> 
>> %0 = apply @initX()
>> %1 = enum #Optional.Some, %0 : $X
>> %2 = existential %1 : $Any
>> 
>> [I'm not sure we actually want to represent an existential container
>> this way, but enum, yes.]
>> 
>> Lowering now requires discovering the storage structure, bottom-up,
>> hoisting allocation, inserting cleanups as John explained.
>> 
>> Side note: Before lowering, something like alloc_box would directly
>> take its initial value.
>> 
>> ** SILFunction calling convention.
>> 
>> For ownership analysis, there's effectively no difference between the
>> value/address forms of argument ownership:
>> 
>> @owned  / @in
>> @guaranteed / @in_guaranteed
>> return  / @out
>> @owned arg
>> + @owned return / @inout
>> 
>> Regardless of the representation we choose for @inout, @in/@out will
>> now be scalar types. SILFunction will maintain the distinction between
>> @owned/@in etc. based on whether the type is address-only. We need
>> this for reabstraction, but it only affects the function type, not the
>> calling convention.
>> 
>> Rather than building a tuple, John prefers SIL support for anonymous
>> aggregate as "exploded values".
>> 
>> [I'm guessing be

Re: [swift-dev] [discussion notes] SIL address types and borrowing

2016-10-08 Thread Andrew Trick via swift-dev


> On Oct 8, 2016, at 12:39 AM, John McCall  wrote:
> 
>> %a = alloc_stack
>> 
>> begin_exclusive %a
>> apply foo(%a) // must be marked an initializer?
>> end_exclusive %a
>> 
>> begin_shared %a
>> apply bar(%a) // immutable access
>> end_shared %a
>> 
>> dealloc_stack %a
> 
> I think alloc_stack returns an owned (but uninitialized) address and there's
> general scoped operation to turn an owned address into a borrow.  Or it could
> be implicit in the operation that needs a borrowed value, as you suggest 
> below.

I should have decorated the code with transitions to get the point across:

%a = alloc_stack   // -> owned/uninitialized

begin_exclusive %a // -> exclusive/uninitialized
apply foo(%a)  // -> exclusive/initialized
end_exclusive %a   // -> owned/initialized

begin_shared %a// -> shared (implies initialized)
apply bar(%a)  // immutable access
end_shared %a  // -> owned/initialized

dealloc_stack %a   // -> invalid

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

Re: [swift-dev] [discussion notes] SIL address types and borrowing

2016-10-10 Thread Andrew Trick via swift-dev


> On Oct 10, 2016, at 6:23 PM, Joe Groff  wrote:
> 
> 
>> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev 
>>  wrote:
>> ** World 1: SSA @inout
>> 
>> Projecting an element produces a new SILValue. Does this SILValue have
>> it's own ownership associated with it's lifetime, or is it derived
>> from it's parent object by looking through projections?
>> 
>> Either way, projecting any subelement requires reconstructing the
>> entire aggregate in SIL, through all nesting levels. This will
>> generate a massive amount of SILValues. Superficially they all need
>> their own storage.
>> 
>> [We could claim that projections don't need storage, but that only
>> solves one side of the problem.]
>> 
>> [I argue that this actually obscures the producer/consumer
>> relationship, which is the opposite of the intention of moving to
>> SSA. Projecting subelements for mutation fundamentally doesn't make
>> sense. It does make sense to borrow a subelement (not for
>> mutation). It also makes sense to project a mutable storage
>> location. The natural way to project a storage location is by
>> projecting an address...]
> 
> I think there's a size threshold at which SSA @inout is manageable, and might 
> lead to overall better register-oriented code, if the aggregates can be 
> exploded into a small number of individual values. The cost of reconstructing 
> the aggregate could be mitigated somewhat by introducing 'insert' 
> instructions for aggregates to pair with the projection instructions, similar 
> to how LLVM has insert/extractelement. "%x = project_value %y.field; %x' = 
> transform(%x); %y' = insert %y.field, %x" isn't too terrible compared to the 
> address-oriented formulation. Tracking ownership state through projections 
> and insertions might tricky; haven't thought about that aspect.
> 
> -Joe

We would have to make sure SROA+mem2reg could still kick in. If that happens, I 
don’t think we need to worry about inout ownership semantics anymore. A 
struct_extract is then essentially a borrow. It’s parent’s lifetime needs to be 
guaranteed, but I don’t know if the subobject needs explicit scoping in SIL 
since there’s no inout scopes to worry about and nothing for the runtime to do 
when the scope ends .

(Incidentally, this would never happen to a CoW type that has a uniqueness 
check—to mutate a CoW type, it’s value needs to be in memory). 

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

Re: [swift-dev] [discussion notes] SIL address types and borrowing

2016-10-11 Thread Andrew Trick via swift-dev


> On Oct 11, 2016, at 10:10 AM, Joe Groff  wrote:
> 
> 
>> On Oct 10, 2016, at 6:58 PM, Andrew Trick  wrote:
>> 
>> 
>>> On Oct 10, 2016, at 6:23 PM, Joe Groff  wrote:
>>> 
>>> 
>>>> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev 
>>>>  wrote:
>>>> ** World 1: SSA @inout
>>>> 
>>>> Projecting an element produces a new SILValue. Does this SILValue have
>>>> it's own ownership associated with it's lifetime, or is it derived
>>>> from it's parent object by looking through projections?
>>>> 
>>>> Either way, projecting any subelement requires reconstructing the
>>>> entire aggregate in SIL, through all nesting levels. This will
>>>> generate a massive amount of SILValues. Superficially they all need
>>>> their own storage.
>>>> 
>>>> [We could claim that projections don't need storage, but that only
>>>> solves one side of the problem.]
>>>> 
>>>> [I argue that this actually obscures the producer/consumer
>>>> relationship, which is the opposite of the intention of moving to
>>>> SSA. Projecting subelements for mutation fundamentally doesn't make
>>>> sense. It does make sense to borrow a subelement (not for
>>>> mutation). It also makes sense to project a mutable storage
>>>> location. The natural way to project a storage location is by
>>>> projecting an address...]
>>> 
>>> I think there's a size threshold at which SSA @inout is manageable, and 
>>> might lead to overall better register-oriented code, if the aggregates can 
>>> be exploded into a small number of individual values. The cost of 
>>> reconstructing the aggregate could be mitigated somewhat by introducing 
>>> 'insert' instructions for aggregates to pair with the projection 
>>> instructions, similar to how LLVM has insert/extractelement. "%x = 
>>> project_value %y.field; %x' = transform(%x); %y' = insert %y.field, %x" 
>>> isn't too terrible compared to the address-oriented formulation. Tracking 
>>> ownership state through projections and insertions might tricky; haven't 
>>> thought about that aspect.
>>> 
>>> -Joe
>> 
>> We would have to make sure SROA+mem2reg could still kick in. If that 
>> happens, I don’t think we need to worry about inout ownership semantics 
>> anymore. A struct_extract is then essentially a borrow. It’s parent’s 
>> lifetime needs to be guaranteed, but I don’t know if the subobject needs 
>> explicit scoping in SIL since there’s no inout scopes to worry about and 
>> nothing for the runtime to do when the scope ends .
>> 
>> (Incidentally, this would never happen to a CoW type that has a uniqueness 
>> check—to mutate a CoW type, it’s value needs to be in memory). 
> 
> Does a uniqueness check still need to be associated with a memory location 
> once we associate ownership with SSA values? It seems to me like it wouldn't 
> necessarily need to be. One thing I'd like us to work toward is being able to 
> reliably apply uniqueness checks to rvalues, so that code in a "pure 
> functional" style gets the same optimization benefits as code that explicitly 
> uses inouts.
> 
> -Joe

We could have an is_unique instruction that returns a “new” reference to 
storage. But our model for CoW data types relies mutating methods so I don't 
really know what you have in mind.

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

Re: [swift-dev] [discussion notes] SIL address types and borrowing

2016-10-11 Thread Andrew Trick via swift-dev


> On Oct 11, 2016, at 11:02 AM, Joe Groff  wrote:
> 
> 
>> On Oct 11, 2016, at 10:50 AM, John McCall  wrote:
>> 
>>> On Oct 11, 2016, at 10:10 AM, Joe Groff via swift-dev  
>>> wrote:
>>>> On Oct 10, 2016, at 6:58 PM, Andrew Trick  wrote:
>>>> 
>>>> 
>>>>> On Oct 10, 2016, at 6:23 PM, Joe Groff  wrote:
>>>>> 
>>>>> 
>>>>>> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev 
>>>>>>  wrote:
>>>>>> ** World 1: SSA @inout
>>>>>> 
>>>>>> Projecting an element produces a new SILValue. Does this SILValue have
>>>>>> it's own ownership associated with it's lifetime, or is it derived
>>>>>> from it's parent object by looking through projections?
>>>>>> 
>>>>>> Either way, projecting any subelement requires reconstructing the
>>>>>> entire aggregate in SIL, through all nesting levels. This will
>>>>>> generate a massive amount of SILValues. Superficially they all need
>>>>>> their own storage.
>>>>>> 
>>>>>> [We could claim that projections don't need storage, but that only
>>>>>> solves one side of the problem.]
>>>>>> 
>>>>>> [I argue that this actually obscures the producer/consumer
>>>>>> relationship, which is the opposite of the intention of moving to
>>>>>> SSA. Projecting subelements for mutation fundamentally doesn't make
>>>>>> sense. It does make sense to borrow a subelement (not for
>>>>>> mutation). It also makes sense to project a mutable storage
>>>>>> location. The natural way to project a storage location is by
>>>>>> projecting an address...]
>>>>> 
>>>>> I think there's a size threshold at which SSA @inout is manageable, and 
>>>>> might lead to overall better register-oriented code, if the aggregates 
>>>>> can be exploded into a small number of individual values. The cost of 
>>>>> reconstructing the aggregate could be mitigated somewhat by introducing 
>>>>> 'insert' instructions for aggregates to pair with the projection 
>>>>> instructions, similar to how LLVM has insert/extractelement. "%x = 
>>>>> project_value %y.field; %x' = transform(%x); %y' = insert %y.field, %x" 
>>>>> isn't too terrible compared to the address-oriented formulation. Tracking 
>>>>> ownership state through projections and insertions might tricky; haven't 
>>>>> thought about that aspect.
>>>>> 
>>>>> -Joe
>>>> 
>>>> We would have to make sure SROA+mem2reg could still kick in. If that 
>>>> happens, I don’t think we need to worry about inout ownership semantics 
>>>> anymore. A struct_extract is then essentially a borrow. It’s parent’s 
>>>> lifetime needs to be guaranteed, but I don’t know if the subobject needs 
>>>> explicit scoping in SIL since there’s no inout scopes to worry about and 
>>>> nothing for the runtime to do when the scope ends .
>>>> 
>>>> (Incidentally, this would never happen to a CoW type that has a uniqueness 
>>>> check—to mutate a CoW type, it’s value needs to be in memory). 
>>> 
>>> Does a uniqueness check still need to be associated with a memory location 
>>> once we associate ownership with SSA values? It seems to me like it 
>>> wouldn't necessarily need to be. One thing I'd like us to work toward is 
>>> being able to reliably apply uniqueness checks to rvalues, so that code in 
>>> a "pure functional" style gets the same optimization benefits as code that 
>>> explicitly uses inouts.
>> 
>> As I've pointed out in the past, this doesn't make any semantic sense.  
>> Projecting out a buffer reference as a true r-value creates an independent 
>> value and therefore requires bumping the reference count.  The only query 
>> that makes semantic sense is "does this value hold a unique reference to its 
>> buffer", which requires some sort of language tool for talking abstractly 
>> about values without creating new, independent values.  Our only existing 
>> language tool for that is inout, which allows you to talk about the value 
>> stored in a specific mutable variable.  Ownership will give us a second and 
>> more general tool, borrowing, which allows you abstractly refer to immutable 
>> existing values.
> 
> If we have @owned values, then we also have the ability to do a uniqueness 
> check on that value, don't we? This would necessarily consume the value, but 
> we could conditionally produce a new known-unique value on the path where the 
> uniqueness check succeeds.
> 
> entry(%1: @owned $X):
>  is_uniquely_referenced %1, yes, no
> yes(%2: /*unique*/ @owned $X):
>  // %2 is unique, until copied at least
> no(%3: @owned %X):
>  // %3 is not
> 
> -Joe

You had to copy $X to make it @owned. You could check uniqueness of @borrowed 
$X, but then you’d need to copy to create a new array (mutation) before 
destroying the original that you borrowed from.

-Andy

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

Re: [swift-dev] [discussion notes] SIL address types and borrowing

2016-10-11 Thread Andrew Trick via swift-dev


> On Oct 11, 2016, at 2:14 PM, John McCall  wrote:
> 
>> On Oct 11, 2016, at 11:49 AM, Joe Groff  wrote:
>>> On Oct 11, 2016, at 11:44 AM, John McCall  wrote:
>>> 
>>>> On Oct 11, 2016, at 11:22 AM, Joe Groff  wrote:
>>>>> On Oct 11, 2016, at 11:19 AM, Andrew Trick  wrote:
>>>>> 
>>>>> 
>>>>>> On Oct 11, 2016, at 11:02 AM, Joe Groff  wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Oct 11, 2016, at 10:50 AM, John McCall  wrote:
>>>>>>> 
>>>>>>>> On Oct 11, 2016, at 10:10 AM, Joe Groff via swift-dev 
>>>>>>>>  wrote:
>>>>>>>>> On Oct 10, 2016, at 6:58 PM, Andrew Trick  wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Oct 10, 2016, at 6:23 PM, Joe Groff  wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev 
>>>>>>>>>>>  wrote:
>>>>>>>>>>> ** World 1: SSA @inout
>>>>>>>>>>> 
>>>>>>>>>>> Projecting an element produces a new SILValue. Does this SILValue 
>>>>>>>>>>> have
>>>>>>>>>>> it's own ownership associated with it's lifetime, or is it derived
>>>>>>>>>>> from it's parent object by looking through projections?
>>>>>>>>>>> 
>>>>>>>>>>> Either way, projecting any subelement requires reconstructing the
>>>>>>>>>>> entire aggregate in SIL, through all nesting levels. This will
>>>>>>>>>>> generate a massive amount of SILValues. Superficially they all need
>>>>>>>>>>> their own storage.
>>>>>>>>>>> 
>>>>>>>>>>> [We could claim that projections don't need storage, but that only
>>>>>>>>>>> solves one side of the problem.]
>>>>>>>>>>> 
>>>>>>>>>>> [I argue that this actually obscures the producer/consumer
>>>>>>>>>>> relationship, which is the opposite of the intention of moving to
>>>>>>>>>>> SSA. Projecting subelements for mutation fundamentally doesn't make
>>>>>>>>>>> sense. It does make sense to borrow a subelement (not for
>>>>>>>>>>> mutation). It also makes sense to project a mutable storage
>>>>>>>>>>> location. The natural way to project a storage location is by
>>>>>>>>>>> projecting an address...]
>>>>>>>>>> 
>>>>>>>>>> I think there's a size threshold at which SSA @inout is manageable, 
>>>>>>>>>> and might lead to overall better register-oriented code, if the 
>>>>>>>>>> aggregates can be exploded into a small number of individual values. 
>>>>>>>>>> The cost of reconstructing the aggregate could be mitigated somewhat 
>>>>>>>>>> by introducing 'insert' instructions for aggregates to pair with the 
>>>>>>>>>> projection instructions, similar to how LLVM has 
>>>>>>>>>> insert/extractelement. "%x = project_value %y.field; %x' = 
>>>>>>>>>> transform(%x); %y' = insert %y.field, %x" isn't too terrible 
>>>>>>>>>> compared to the address-oriented formulation. Tracking ownership 
>>>>>>>>>> state through projections and insertions might tricky; haven't 
>>>>>>>>>> thought about that aspect.
>>>>>>>>>> 
>>>>>>>>>> -Joe
>>>>>>>>> 
>>>>>>>>> We would have to make sure SROA+mem2reg could still kick in. If that 
>>>>>>>>> happens, I don’t think we need to worry about inout ownership 
>>>>>>>>> semantics anymore. A struct_extract is then essentially a borrow. 
>>>>>>>>> It’s parent’s lifetime needs to be guaranteed, but I don’t know if 
>>>>>>>>> the subobject needs explici

Re: [swift-dev] copy-on-write proposal

2016-10-12 Thread Andrew Trick via swift-dev

> On Oct 12, 2016, at 11:19 AM, Alexis via swift-dev  
> wrote:
> 
> I’m having trouble figuring something out: is all of this contingent on all 
> of the relevant operations being completely inlined into a single function at 
> the SIL level? Could failing to inline a standard library function lead to 
> performance cliffs? I understand this is generally true of inlining and 
> dead-code elimination; but I’m wondering how this affects the abstractions we 
> expose. Can we know that some things will “always” work, even if parts aren’t 
> inlined?

Well, actually there are two basic approaches that you see within the SIL 
optimizer. One relies on being able to analyze all instructions between two 
points in the CFG. That depends on full inlining or deep IPA. The other 
approach relies on knowledge about aliasing, uniqueness, immutability, and so 
on reach a conclusion about some opaque region of code.

Some of our optimizations rely on full inlining and conservative analysis, but 
the more we can capture semantics in SIL, the more we can employ the second 
approach, which improves the power and robustness of the optimizer.

Erik proposed redundant-load elimination and ARC optimizations that both need 
to prove the absence of a store to a particular memory location within some 
region. With the proposed copy-on-write attribute, we can now prove the absence 
of a store without analyzing any of the instructions in that region. I think 
this is an good example of the second approach where we can optimize around 
opaque regions of code. So it’s worth making sure our representation supports 
that.

It is still true though that enough inlining needs to take place such that we 
can see a load of the Array storage and access to that storage all in the same 
function scope.

-Andy

>> On Oct 11, 2016, at 7:48 PM, Erik Eckstein via swift-dev 
>>  wrote:
>> 
>> This is a proposal for representing copy-on-write buffers in SIL. Actually 
>> it’s still a draft for a proposal. It also heavily depends on how we move 
>> forward with SIL ownership.
>> 
>> If you have any comments, please let me know.
>> 
>> Erik
>> 
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

2016-10-14 Thread Andrew Trick via swift-dev

This seems fine to me… at a high level!
-Andy

> On Oct 14, 2016, at 2:44 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
> Attached below is a final version of the proposal. I am going to commit it to 
> the repo if there are no further questions/changes/etc.
> 
>> https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html 
>> 
> Michael
> 
> 
> 
> # Summary
> 
> This document proposes:
> 
> 1. adding the following ownership qualifiers to `load`: `[take]`, `[copy]`,
>`[trivial]`.
> 2. adding the following ownership qualifiers to `store`: `[init]`, `[assign]`,
>`[trivial]`.
> 3. adding the `load_borrow` instruction and the `end_borrow` instruction.
> 3. requiring all `load` and `store` operations to have ownership qualifiers.
> 4. banning the use of `load [trivial]`, `store [trivial]` on memory locations 
> of
>`non-trivial` type.
> 
> This will allow for:
> 
> 1. eliminating optimizer miscompiles that occur due to releases being moved 
> into
>the region in between a `load`/`retain`, `load`/`release`,
>`store`/`release`. (For a specific example, see the appendix).
> 2. explicitly modeling `load [trivial]`/`store [trivial]` as having `unsafe
>unowned` ownership semantics. This will be enforced via the verifier.
> 3. more aggressive ARC code motion.
> 
> # Definitions
> 
> ## ownership qualified load
> 
> We propose three different ownership qualifiers for load. Define `load 
> [trivial]`
> as:
> 
> %x = load [trivial] %x_ptr : $*Int
> 
>   =>
> 
> %x = load %x_ptr : $*Int
> 
> A `load [trivial]` can not be used to load values of non-trivial type. Define
> `load [copy]` as:
> 
> %x = load [copy] %x_ptr : $*C
> 
>   =>
> 
> %x = load %x_ptr : $*C
> retain_value %x : $C
> 
> Then define `load [take]` as:
> 
> %x = load [take] %x_ptr : $*Builtin.NativeObject
> 
>   =>
> 
> %x = load %x_ptr : $*Builtin.NativeObject
> 
> **NOTE** `load [take]` implies that the loaded from memory location no longer
> owns the result object (i.e. a take is a move). Loading from the memory 
> location
> again without reinitialization is illegal.
> 
> ## load_borrow and end_borrow
> 
> Next we provide `load_borrow` and `end_borrow`:
> 
> %x = load_borrow %x_ptr : $*Builtin.NativeObject
> ...
> end_borrow %x, %x_ptr : $*Builtin.NativeObject
> 
>   =>
> 
> %x = load %x_ptr : $*Builtin.NativeObject
> ...
> endLifetime %x : $Builtin.NativeObject
> fixLifetime %x_ptr : $*Builtin.NativeObject
> 
> `load [borrow]` implies that in the region between the `load` and the
> `end_borrow`, the loaded object must semantically remain alive. The 
> `end_borrow`
> communicates to the optimizer:
> 
> 1. that the value in `%x_ptr` should not be destroyed before endBorrow.
> 2. uses of `%x` should not be sunk past endBorrow since `%x` is only a shallow
>copy of the value in `%x_ptr` and past that point `%x_ptr` may not remain
>alive.
> 
> An example of where this construct is useful is when one has a let binding to 
> a
> class instance `c` that contains a let field `f`. In that case `c`'s lifetime
> guarantees `f`'s lifetime meaning that returning `f` over the function call
> boundary is safe.
> 
> *NOTE* since the SILOwnershipModelEliminator will not process these
> instructions, endLifetime is just a strawman instruction that will not be
> implemented. In practice though, IRGen will need to create a suitable barrier 
> to
> ensure that LLVM does not move any uses of `%x` past the `fixLifetime`
> instruction of `%x_ptr` once we begin creating such instructions as a result 
> of
> ARC optimization.
> 
> ## ownership qualified store
> 
> First define a `store [trivial]` as:
> 
> store %x to [trivial] %x_ptr : $*Int
> 
>   =>
> 
> store %x to %x_ptr : $*Int
> 
> The verifier will prevent this instruction from being used on types with
> non-trivial ownership. Define a `store [assign]` as follows:
> 
> store %x to [assign] %x_ptr : $*C
> 
>=>
> 
> %old_x = load %x_ptr : $*C
> store %new_x to %x_ptr : $*C
> release_value %old_x : $C
> 
> *NOTE* `store` is defined as a consuming operation. We also provide
> `store [init]` in the case where we know statically that there is no
> previous value in the memory location:
> 
> store %x to [init] %x_ptr : $*C
> 
>=>
> 
> store %new_x to %x_ptr : $*C
> 
> # Implementation
> 
> ## Goals
> 
> Our implementation strategy goals are:
> 
> 1. zero impact on other compiler developers until the feature is fully
>developed. This implies all work will be done behind a flag.
> 2. separation of feature implementation from updating passes.
> 
> Goal 2 will be implemented via a pass that transforms ownership qualified
> `load`/`store` instructions into unqualified `load`/`store` right after 
> SILGen.
> 
> ## Plan
> 
> We begin by adding initial infrastructure for our developme

Re: [swift-dev] copy-on-write proposal

2016-10-19 Thread Andrew Trick via swift-dev


> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> on Tue Oct 18 2016, Erik Eckstein  > wrote:
> 
>>> On Oct 17, 2016, at 10:21 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Mon Oct 17 2016, Erik Eckstein  wrote:
>>> 
>> 
 On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev 
  wrote:
 
> on Thu Oct 13 2016, Joe Groff  > wrote:
> 
>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
>>>  wrote:
>>> 
>>> This is a proposal for representing copy-on-write buffers in
>>> SIL. Actually it’s still a draft for a proposal. It also heavily
>>> depends on how we move forward with SIL ownership.
>>> 
>>> If you have any comments, please let me know.
>> 
>> The SIL-level design seems sensible to me at a glance. At the language
>> level, I think it would make more sense to treat this as an attribute
>> on class types rather than on properties in structs using the class. I
>> don't think many people reuse class definitions as both shared
>> reference types and as value type payloads, 
> 
> Foundation does, or would if they could.
> 
>> but beyond that, I think that making it an attribute of classes would
>> put us into a better position to leverage the borrow model to enforce
>> the "mutable-only-when-unique" aspect of COW implementations. John
>> alluded to this in the "SIL address types and borrowing" thread:
>> 
>>> I wonder if it would make more sense to make copy-on-write buffer
>>> references a move-only type, so that as long as you were just
>>> working with the raw reference (as opposed to the CoW aggregate,
>>> which would remain copyable) it wouldn't get implicitly copied
>>> anymore.  You could have mutable and immutable buffer reference
>>> types, both move-only, and there could be a consuming checkUnique
>>> operation on the immutable one that, I dunno, returned an Either of
>>> the mutable and immutable versions.
>>> 
>>> For CoW aggregates, you'd need some @copied attribute on the field
>>> to make sure that the CoW attribute was still copyable.  Within the
>>> implementation of the type, though, you would be projecting out the
>>> reference immediately, and thereafter you'd be certain that you were
>>> borrowing / moving it around as appropriate.
>> 
>> If 'copy-on-write' were a trait on classes, then we could distinguish
>> unique and nonunique references to the class. A unique reference would
>> act like a move-only type to prevent accidental loss of uniqueness. 
> 
> +1
> 
>> We can also allow a copy-on-write class to have "mutating" methods,
>> and only allow mutation on unique references. It seems to me like,
>> exploring this direction, we could also come up with a way for the
>> high-level value-semantics operations on the struct to statically
>> indicate which methods are known to leave the value's buffers in a
>> unique state, or which return values that are uniquely owned, which
>> would give the optimizer more ability to avoid uniqueness checks
>> across calls without relying on inlining and IPO.
> 
> That's pretty cool.  However, I think there's nothing to prevent any
> mutating method from storing a copy of self in a global, so I think we'd
> need some participation from the programmer (either an agreement not to
> do that, or an explicit claim of uniqueness on exit) in order to
> identify operations that create/preserve uniqueness.
 
 If a mutating reference (like self in a mutating method) is move-only
 then you would not be able to “copy” it to a global.
>>> 
>>> Yes, a reference to a move-only type would work for this purpose.
>>> 
>>> 
> On Oct 16, 2016, at 2:01 PM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> on Tue Oct 11 2016, Erik Eckstein  wrote:
> 
>> This is a proposal for representing copy-on-write buffers in
>> SIL. Actually it’s still a draft for a proposal. It also heavily
>> depends on how we move forward with SIL ownership.
>> 
>> :orphan:
>> 
>> .. highlight:: sil
>> 
>> ===
>> Copy-On-Write Representation in SIL
>> ===
>> 
>> .. contents::
>> 
>> Overview
>> 
>> 
>> This document proposes:
>> 
>> - An ownership attribute to define copy-on-write (COW) buffers in Swift 
>> data
>> types.
>> 
>> - A representation of COW buffers in SIL so that optimizations can take 
>> benefit
>> of it.
>> 
>> The basic idea is to enable the SIL optimizer to reason about COW data 
>> types
>> in the same way as a programmer can do.
>> This means: a COW buffer can only be modified by its owning SIL value, 
>>

Re: [swift-dev] copy-on-write proposal

2016-10-20 Thread Andrew Trick via swift-dev

> On Oct 20, 2016, at 8:41 AM, Erik Eckstein  wrote:
> 
>> To clarify: I proposed an alternate approach in which the @sil_cow reference 
>> is only mutable during the Array’s @inout scope—to be automatically enforced 
>> by the compiler once @inout scopes are enforced. But the text in question is 
>> not referring to that approach, so your comments are on target.
> 
> After thinking about Joe’s suggestion (having the cow attribute on the class 
> type and make a reference to that type move-only), I’m more inclined to go 
> with the isUnique builtin. If such a reference can only be returned by 
> isUnique, it is really guaranteed that only a uniquely referenced buffer can 
> be mutated. With the inout approach, the programmer is not forced to make the 
> uniqueness check before modifying the buffer.

In my mind, relying on a move-only reference type is exactly what I was 
advocating for, but relies on a language feature rather than a “special” 
compiler verification. This all still needs to work with an ‘inout’ Array. The 
compiler will effectively be doing the same verification that I was proposing 
but as a side effect of move-only semantics (type system support makes it much 
easier). The isUnique builtin would just be a mechanism to get the mutable 
type, and the endUnique builtin is the mechanism to move the type back. As Dave 
pointed out, we could provide additional mechanisms for mutation that don’t 
depend on uniqueness. But the SIL optimizer doesn’t need to be explicitly 
taught about any of those builtin mechanisms for correctness. More importantly, 
the user is no longer responsible for some easy-to-violate, unverified property 
of the data type as a whole.

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

Re: [swift-dev] Casting shadow protocols

2016-11-08 Thread Andrew Trick via swift-dev


> On Nov 7, 2016, at 12:15 PM, Alexis via swift-dev  wrote:
> 
> Does _unsafeReferenceCast at least verify that the types in question could 
> theoretically be cast into each other? That is, one is derived from the 
> other? If so, that would probably be an acceptable improvement. (the best we 
> could ever hope to do?)

This is what I call lying about types. _unsafeReferenceCast does not and should 
not support that. It *should* actually have sanity checks to catch such 
incorrect usage. The checks aren’t implemented yet. Instead you may end up with 
a crash in the runtime.

unsafeBitCast is the way to lie about a type. It only works when 
- dealing with a @objc class protocol
- we guarantee that the mistyped reference will never be dynamically cast or 
accessed in any way other than msgSend

Those conditions make it immune from struct aliasing based on a technicality. 
It does encourage bad practice, and our memory model documentation now needs to 
make exceptions for this special, confusing case.

I like JoeG’s idea of a msgSend builtin. I’m just not sure that would 
completely obsolete shadow protocols. Are we also using them to satisfy 
protocol requirements?

-Andy

>> On Nov 7, 2016, at 2:30 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Mon Nov 07 2016, Alexis  wrote:
>> 
 On Nov 4, 2016, at 11:55 PM, Dave Abrahams via swift-dev 
  wrote:
 
 
 on Fri Nov 04 2016, Slava Pestov >>> > wrote:
 
> If the casts are always in one direction, can you make one protocol
> refine another?
 
 Yeah, I am shocked if they don't do that already.
>>> 
>>> They do; _NSFoo: _NSFooCore
>>> 
>>> But the problem is that we have _NSFooCores and want _NSFoos.
>> 
>> Right.  Then you need type punning without any dynamic checks,
>> a.k.a. _unsafeReferenceCast
>> 
>>> 
 
> Also note that @objc protocols are self-conforming as long as they
> don’t contain initializers or static methods, but I’m not sure if that
> helps.
 
 Doesn't; we're not using these in a generic context; they're just
 existentials.
 
> 
> 
>> On Nov 4, 2016, at 4:29 PM, Alexis via swift-dev  
>> wrote:
>> 
>> The swift standard library has this nasty little pattern/problem in it:
>> 
>> The types in the core library want to know about several types
>> defined in foundation: NSString, NSArray, NSDictionary, etc. But
>> core is imported by Foundation, so it can’t (circular references
>> between modules). Thankfully, everything in ObjC is pretty opaquely
>> defined and uniform, and Swift knows how to hook into that uniform
>> layout. So the core library defines Shadow Protocols which provide
>> whatever subset of that type’s API is considered interesting. These
>> protocols are then used in place of the ObjC types. There’s also
>> some magic compiler hooks so core lib types can subclass those
>> foundation types.
>> 
>> However there’s sometimes two Shadow Protocols: one that defines the
>> APIs the stdlib should provide (_NSFooCore), and one that extends
>> that with extra APIs the stdlib wants to consume (_NSFoo). This
>> leads to an awkward situation: as far as the runtime is concerned,
>> the stdlib’s _NSFooCores don’t conform to _NSFoo! We know they do
>> because it’s all just a big lie to hook into ObjC message passing
>> with a bit of type safety, but the runtime doesn’t. So if you try to
>> do a safe type cast, it will fail. This leads to a situation where
>> we sprinkle code with unsafeBitCast’s to _NSFoo which is a massive
>> refactoring hazard.
>> 
>> For instance, there was a struct-containing-a-class that was being
>> cast to _NSFoo in HashedCollections. This happened to work (but was
>> probably still a violation of strict aliasing?) because the struct’s
>> only field was the class. However the struct was later changed to a
>> class, which silently made the cast completely incorrect, banishing
>> the real _NSFoo to the shadow (protocol) realm.
>> 
>> Can we do anything better here? Note that there’s a few places where
>> we also cast an AnyObject into an _NSFoo, but there’s some chance
>> this is all legacy junk that can be updated to at least use
>> _NSFooCore, if not _NSFoo itself.
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev
>>> 
> 
 
 -- 
 -Dave
 
 ___
 swift-dev mailing list
 swift-dev@swift.org 
 https://lis

Re: [swift-dev] -Onone @inline(__always)?

2016-12-01 Thread Andrew Trick via swift-dev

Responding on swift-dev to what turned into an interesting discussion…

> On Dec 1, 2016, at 11:19 AM, Joe Groff  wrote:
> 
>> 
>> On Dec 1, 2016, at 11:18 AM, Joe Groff  wrote:
>> 
>>> 
>>> On Dec 1, 2016, at 11:16 AM, Andrew Trick  wrote:
>>> 
>>> 
 On Dec 1, 2016, at 10:34 AM, Jordan Rose  wrote:
 
> 
> On Nov 30, 2016, at 18:16, Joe Groff  wrote:
> 
>> 
>> On Nov 30, 2016, at 6:10 PM, Andrew Trick  wrote:
>> 
>> We definitely want an inline-at-Onone, but I assumed we were treating 
>> "@inline(__always)" as a normal heuristic because:
>> - @transparent already does inline-at-Onone.
>> - @inline(__always) without @transparent negatively affects the debug 
>> experience.
>> - @inline(__always) isn't useful if no optimizations are run after 
>> inlining.
>> 
>> That said, if the common expectation is for @inline(__always) to kick in 
>> independent of optimization, then we should honor that.
>> 
>> It's easy for me to add an inlining pass to runSILPassesForOnone. I'm 
>> just not sure that will have the effect people are looking for. It's 
>> unlikely to help performance since nothing is going to run after the 
>> inlining (no capture promotion or alloc box-to-stack). The only 
>> optimization we currently run at Onone after diagnostics is 
>> prespecialization.

Actually, the inliner specializes as it goes, so inlining after mandatory SIL 
passes would still be quite useful.

My concern is really that the user may expect inline(__always) to be as 
effective a performance tool as @transparent, while preserving debug line 
locations.
If it runs late, it doesn’t expose capture promotion, box-to-stack, guaranteed 
ARC optimization, etc.

>> If someone is using inline(__always) for -Onone performance reasons, I 
>> think they really need to use @transparent.
>> 
>> An alternative is to have @inline(__always) be another way to spell 
>> @transparent. People would need to implicitly know that this would 
>> affect diagnostics of the inlined method.
>> 
>> Any thoughts?
> 
> `@transparent` doesn't just mean "inline-at-Onone", it also allows 
> diagnostic passes to constant-fold through the implementation and 
> actively eliminates debug information. It was never intended to be used 
> for performance, but only for the limited set of things that need it. I 
> imagine that the specialization you get by inlining some things is pretty 
> important by itself. I suspect closure inlining would also be helpful for 
> a lot of low-level "with*" combinators; doesn't transparent inlining do 
> that, and could inline-always-inlining do the same?
 
 For reference: 
 https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst
>>> 
>>> The only remaining question: is it ok for a non-transparent function to be 
>>> inlined prior to running some dataflow diagnostics?
>> 
>> Doing so changes the set of programs that are accepted, since it may expose 
>> more code to diagnostic passes. We don't want diagnostics to depend on 
>> optimizations.
> 
> Perhaps we could avoid this by changing the diagnostic passes to 
> intentionally ignore instructions with inlined source locations, though that 
> seems brittle.
> 
> -Joe

Well, inline(__always) would be mandatory, not an optimization. But I think 
your point is that the user does not expect that attribute to affect program 
legality. Having data-flow diagnostics “ignore” certain instructions sounds 
horrible. Is there an obvious problem, or is this hypothetical? i.e. is there 
some diagnostic that is currently enforced at the function boundary but would 
be considered legal code after inlining?

-Andy


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

Re: [swift-dev] -Onone @inline(__always)?

2016-12-01 Thread Andrew Trick via swift-dev


> On Dec 1, 2016, at 11:48 AM, Andrew Trick  wrote:
> 
> Responding on swift-dev to what turned into an interesting discussion…
> 
>> On Dec 1, 2016, at 11:19 AM, Joe Groff > > wrote:
>> 
>>> 
>>> On Dec 1, 2016, at 11:18 AM, Joe Groff >> > wrote:
>>> 
 
 On Dec 1, 2016, at 11:16 AM, Andrew Trick >>> > wrote:
 
 
> On Dec 1, 2016, at 10:34 AM, Jordan Rose  > wrote:
> 
>> 
>> On Nov 30, 2016, at 18:16, Joe Groff > > wrote:
>> 
>>> 
>>> On Nov 30, 2016, at 6:10 PM, Andrew Trick >> > wrote:
>>> 
>>> We definitely want an inline-at-Onone, but I assumed we were treating 
>>> "@inline(__always)" as a normal heuristic because:
>>> - @transparent already does inline-at-Onone.
>>> - @inline(__always) without @transparent negatively affects the debug 
>>> experience.
>>> - @inline(__always) isn't useful if no optimizations are run after 
>>> inlining.
>>> 
>>> That said, if the common expectation is for @inline(__always) to kick 
>>> in independent of optimization, then we should honor that.
>>> 
>>> It's easy for me to add an inlining pass to runSILPassesForOnone. I'm 
>>> just not sure that will have the effect people are looking for. It's 
>>> unlikely to help performance since nothing is going to run after the 
>>> inlining (no capture promotion or alloc box-to-stack). The only 
>>> optimization we currently run at Onone after diagnostics is 
>>> prespecialization.
> 
> Actually, the inliner specializes as it goes, so inlining after mandatory SIL 
> passes would still be quite useful.
> 
> My concern is really that the user may expect inline(__always) to be as 
> effective a performance tool as @transparent, while preserving debug line 
> locations.
> If it runs late, it doesn’t expose capture promotion, box-to-stack, 
> guaranteed ARC optimization, etc.
> 
>>> If someone is using inline(__always) for -Onone performance reasons, I 
>>> think they really need to use @transparent.
>>> 
>>> An alternative is to have @inline(__always) be another way to spell 
>>> @transparent. People would need to implicitly know that this would 
>>> affect diagnostics of the inlined method.
>>> 
>>> Any thoughts?
>> 
>> `@transparent` doesn't just mean "inline-at-Onone", it also allows 
>> diagnostic passes to constant-fold through the implementation and 
>> actively eliminates debug information. It was never intended to be used 
>> for performance, but only for the limited set of things that need it. I 
>> imagine that the specialization you get by inlining some things is 
>> pretty important by itself. I suspect closure inlining would also be 
>> helpful for a lot of low-level "with*" combinators; doesn't transparent 
>> inlining do that, and could inline-always-inlining do the same?
> 
> For reference: 
> https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst 
> 
 
 The only remaining question: is it ok for a non-transparent function to be 
 inlined prior to running some dataflow diagnostics?
>>> 
>>> Doing so changes the set of programs that are accepted, since it may expose 
>>> more code to diagnostic passes. We don't want diagnostics to depend on 
>>> optimizations.
>> 
>> Perhaps we could avoid this by changing the diagnostic passes to 
>> intentionally ignore instructions with inlined source locations, though that 
>> seems brittle.
>> 
>> -Joe
> 
> Well, inline(__always) would be mandatory, not an optimization. But I think 
> your point is that the user does not expect that attribute to affect program 
> legality. Having data-flow diagnostics “ignore” certain instructions sounds 
> horrible. Is there an obvious problem, or is this hypothetical? i.e. is there 
> some diagnostic that is currently enforced at the function boundary but would 
> be considered legal code after inlining?
> 
> -Andy

I guess initialization of @inout arguments would be the obvious problem.
-Andy___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] -Onone @inline(__always)?

2016-12-01 Thread Andrew Trick via swift-dev


> On Dec 1, 2016, at 11:55 AM, Joe Groff  wrote:
> 
> 
>> On Dec 1, 2016, at 11:48 AM, Andrew Trick > > wrote:
>> 
>> Responding on swift-dev to what turned into an interesting discussion…
>> 
>>> On Dec 1, 2016, at 11:19 AM, Joe Groff >> > wrote:
>>> 
 
 On Dec 1, 2016, at 11:18 AM, Joe Groff  wrote:
 
> 
> On Dec 1, 2016, at 11:16 AM, Andrew Trick  wrote:
> 
> 
>> On Dec 1, 2016, at 10:34 AM, Jordan Rose  wrote:
>> 
>>> 
>>> On Nov 30, 2016, at 18:16, Joe Groff  wrote:
>>> 
 
 On Nov 30, 2016, at 6:10 PM, Andrew Trick  wrote:
 
 We definitely want an inline-at-Onone, but I assumed we were treating 
 "@inline(__always)" as a normal heuristic because:
 - @transparent already does inline-at-Onone.
 - @inline(__always) without @transparent negatively affects the debug 
 experience.
 - @inline(__always) isn't useful if no optimizations are run after 
 inlining.
 
 That said, if the common expectation is for @inline(__always) to kick 
 in independent of optimization, then we should honor that.
 
 It's easy for me to add an inlining pass to runSILPassesForOnone. I'm 
 just not sure that will have the effect people are looking for. It's 
 unlikely to help performance since nothing is going to run after the 
 inlining (no capture promotion or alloc box-to-stack). The only 
 optimization we currently run at Onone after diagnostics is 
 prespecialization.
>> 
>> Actually, the inliner specializes as it goes, so inlining after mandatory 
>> SIL passes would still be quite useful.
>> 
>> My concern is really that the user may expect inline(__always) to be as 
>> effective a performance tool as @transparent, while preserving debug line 
>> locations.
>> If it runs late, it doesn’t expose capture promotion, box-to-stack, 
>> guaranteed ARC optimization, etc.
>> 
 If someone is using inline(__always) for -Onone performance reasons, I 
 think they really need to use @transparent.
 
 An alternative is to have @inline(__always) be another way to spell 
 @transparent. People would need to implicitly know that this would 
 affect diagnostics of the inlined method.
 
 Any thoughts?
>>> 
>>> `@transparent` doesn't just mean "inline-at-Onone", it also allows 
>>> diagnostic passes to constant-fold through the implementation and 
>>> actively eliminates debug information. It was never intended to be used 
>>> for performance, but only for the limited set of things that need it. I 
>>> imagine that the specialization you get by inlining some things is 
>>> pretty important by itself. I suspect closure inlining would also be 
>>> helpful for a lot of low-level "with*" combinators; doesn't transparent 
>>> inlining do that, and could inline-always-inlining do the same?
>> 
>> For reference: 
>> https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst 
>> 
> 
> The only remaining question: is it ok for a non-transparent function to 
> be inlined prior to running some dataflow diagnostics?
 
 Doing so changes the set of programs that are accepted, since it may 
 expose more code to diagnostic passes. We don't want diagnostics to depend 
 on optimizations.
>>> 
>>> Perhaps we could avoid this by changing the diagnostic passes to 
>>> intentionally ignore instructions with inlined source locations, though 
>>> that seems brittle.
>>> 
>>> -Joe
>> 
>> Well, inline(__always) would be mandatory, not an optimization. But I think 
>> your point is that the user does not expect that attribute to affect program 
>> legality. Having data-flow diagnostics “ignore” certain instructions sounds 
>> horrible. Is there an obvious problem, or is this hypothetical? i.e. is 
>> there some diagnostic that is currently enforced at the function boundary 
>> but would be considered legal code after inlining?
> 
> An example of something that depends on dataflow diagnostics would be 
> something that's constant-foldable causing static overflow diagnostics:
> 
> func double(_ x: UInt8) -> UInt8 {
>   return x + x
> }
> 
> _ = double(128)
> 
> Making `double` transparent causes the compiler to statically reject the call:
> 
> /Users/jgroff/bar.swift:6:5: error: arithmetic operation '128 + 128' (on 
> unsigned 8-bit integer type) results in an overflow
> _ = double(128)
> ^
> 
> -Joe

Right. In fact, constant propagation appears to be the only diagnostic that 
needs to run after mandatory inlining (I was misremembering SILDiagnostic 
pipeline):

  PM.addCapturePromotion();
  PM.addAllocBoxToStack();
  PM.addNoReturnFolding();
  PM.addDefiniteInitialization();

  PM.addMandatoryInlini

Re: [swift-dev] Proposal: SILValue SSA Instructions

2016-12-07 Thread Andrew Trick via swift-dev


> On Dec 6, 2016, at 2:23 PM, John McCall via swift-dev  
> wrote:
> 
>> On Dec 6, 2016, at 11:35 AM, Joe Groff > > wrote:
>>> On Dec 6, 2016, at 11:29 AM, John McCall >> > wrote:
>>> 
 On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev >>> > wrote:
> On Dec 5, 2016, at 4:24 PM, Michael Gottesman via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> 
> Hello everyone!
> 
> This is a proposal for 2 instructions needed to express borrowing via SSA 
> at the SIL level. The need for these were discovered while I was 
> prototyping a SIL ownership verifier.
> 
> A html version of the proposal:
> 
> https://gottesmm.github.io/proposals/sil-ownership-value-ssa-operations.html
>  
> 
> 
> And inline:
> 
> 
> 
> # Summary
> 
> This document proposes the addition of the following new SIL instructions:
> 
> 1. `store_borrow`
> 2. `begin_borrow`
> 
> These enable the expression of the following operations in Semantic SIL:
> 
> 1. Passing an `@guaranteed` value to an `@in_guaranteed` argument without
> performing a copy. (`store_borrow`)
> 2. Copying a field from an `@owned` aggregate without consuming or 
> copying the entire
> aggregate. (`begin_borrow`)
> 3. Passing an `@owned` value as an `@guaranteed` argument parameter.
> 
> # Definitions
> 
> ## store_borrow
> 
> Define `store_borrow` as:
> 
>  store_borrow %x to %y : $*T
>  ...
>  end_borrow %y from %x : $*T, $T
> 
>=>
> 
>  store %x to %y
> 
> `store_borrow` is needed to convert `@guaranteed` values to 
> `@in_guaranteed`
> arguments. Without a `store_borrow`, this can only be expressed via an
> inefficient `copy_value` + `store` + `load` + `destroy_value` sequence:
> 
>  sil @g : $@convention(thin) (@in_guaranteed Foo) -> ()
> 
>  sil @f : $@convention(thin) (@guaranteed Foo) -> () {
>  bb0(%0 : $Foo):
>%1 = function_ref @g : $@convention(thin) (@in_guaranteed Foo) -> ()
>%2 = alloc_stack $Foo
>%3 = copy_value %0 : $Foo
>store %3 to [init] %2 : $Foo
>apply %1(%2) : $@convention(thin) (@in_guaranteed Foo) -> ()
>%4 = load [take] %2 : $*Foo
>destroy_value %4 : $Foo
>dealloc_stack %2 : $Foo
>...
>  }
> 
> `store_borrow` allows us to express this in a more efficient and 
> expressive SIL:
> 
>  sil @f : $@convention(thin) (@guaranteed Foo) -> () {
>  bb0(%0 : $Foo):
>%1 = function_ref @g : $@convention(thin) (@in_guaranteed Foo) -> ()
>%2 = alloc_stack $Foo
>store_borrow %0 to %2 : $*T
>apply %1(%2) : $@convention(thin) (@in_guaranteed Foo) -> ()
>end_borrow %2 from %0 : $*T, $T
>dealloc_stack %2 : $Foo
>...
>  }
> 
> **NOTE** Once `@in_guaranteed` arguments become passed as values, 
> `store_borrow`
> will no longer be necessary.
> 
> ## begin_borrow
> 
> Define a `begin_borrow` instruction as:
> 
>  %borrowed_x = begin_borrow %x : $T
>  %borrow_x_field = struct_extract %borrowed_x : $T, #T.field
>  apply %f(%borrowed_x) : $@convention(thin) (@guaranteed T) -> ()
>  end_borrow %borrowed_x from %x : $T, $T
> 
>=>
> 
>  %x_field = struct_extract %x : $T, #T.field
>  apply %f(%x_field) : $@convention(thin) (@guaranteed T) -> ()
> 
> A `begin_borrow` instruction explicitly converts an `@owned` value to a
> `@guaranteed` value. The result of the `begin_borrow` is paired with an
> `end_borrow` instruction that explicitly represents the end scope of the
> `begin_borrow`.
> 
> `begin_borrow` also allows for the explicit borrowing of an `@owned` 
> value for
> the purpose of passing the value off to an `@guaranteed` parameter.
> 
> *NOTE* Alternatively, we could make it so that *_extract operations 
> started
> borrow scopes, but this would make SIL less explicit from an ownership
> perspective since one wouldn't be able to visually identify the first
> `struct_extract` in a chain of `struct_extract`. In the case of 
> `begin_borrow`,
> there is no question and it is completely explicit.
 
 begin_borrow SGTM. Does end_borrow need to be explicit, or could we leave 
 it implicit and rely on dataflow diagnostics to ensure the borrowed 
 value's lifetime is dominated by the owner's? It seems to me like, even if 
 end_borrow is explicit, we'd want a lifetime-shortening pass to shrinkwrap 
 end_borrows to the precise lifetime of the borrowed value's uses.
>>> 
>>> I definitely think it should be explicit, as Michael has it.
>> 
>> Would you be able to elabo

Re: [swift-dev] Proposal: SILValue SSA Instructions

2016-12-07 Thread Andrew Trick via swift-dev


> On Dec 7, 2016, at 3:16 PM, Michael Gottesman  wrote:
> 
>> 
>> On Dec 7, 2016, at 2:52 PM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> 
>>> On Dec 6, 2016, at 2:23 PM, John McCall via swift-dev >> <mailto:swift-dev@swift.org>> wrote:
>>> 
>>>> On Dec 6, 2016, at 11:35 AM, Joe Groff >>> <mailto:jgr...@apple.com>> wrote:
>>>>> On Dec 6, 2016, at 11:29 AM, John McCall >>>> <mailto:rjmcc...@apple.com>> wrote:
>>>>> 
>>>>>> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev 
>>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>>>> On Dec 5, 2016, at 4:24 PM, Michael Gottesman via swift-dev 
>>>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>>>> 
>>>>>>> Hello everyone!
>>>>>>> 
>>>>>>> This is a proposal for 2 instructions needed to express borrowing via 
>>>>>>> SSA at the SIL level. The need for these were discovered while I was 
>>>>>>> prototyping a SIL ownership verifier.
>>>>>>> 
>>>>>>> A html version of the proposal:
>>>>>>> 
>>>>>>> https://gottesmm.github.io/proposals/sil-ownership-value-ssa-operations.html
>>>>>>>  
>>>>>>> <https://gottesmm.github.io/proposals/sil-ownership-value-ssa-operations.html>
>>>>>>> 
>>>>>>> And inline:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> # Summary
>>>>>>> 
>>>>>>> This document proposes the addition of the following new SIL 
>>>>>>> instructions:
>>>>>>> 
>>>>>>> 1. `store_borrow`
>>>>>>> 2. `begin_borrow`
>>>>>>> 
>>>>>>> These enable the expression of the following operations in Semantic SIL:
>>>>>>> 
>>>>>>> 1. Passing an `@guaranteed` value to an `@in_guaranteed` argument 
>>>>>>> without
>>>>>>> performing a copy. (`store_borrow`)
>>>>>>> 2. Copying a field from an `@owned` aggregate without consuming or 
>>>>>>> copying the entire
>>>>>>> aggregate. (`begin_borrow`)
>>>>>>> 3. Passing an `@owned` value as an `@guaranteed` argument parameter.
>>>>>>> 
>>>>>>> # Definitions
>>>>>>> 
>>>>>>> ## store_borrow
>>>>>>> 
>>>>>>> Define `store_borrow` as:
>>>>>>> 
>>>>>>>  store_borrow %x to %y : $*T
>>>>>>>  ...
>>>>>>>  end_borrow %y from %x : $*T, $T
>>>>>>> 
>>>>>>>=>
>>>>>>> 
>>>>>>>  store %x to %y
>>>>>>> 
>>>>>>> `store_borrow` is needed to convert `@guaranteed` values to 
>>>>>>> `@in_guaranteed`
>>>>>>> arguments. Without a `store_borrow`, this can only be expressed via an
>>>>>>> inefficient `copy_value` + `store` + `load` + `destroy_value` sequence:
>>>>>>> 
>>>>>>>  sil @g : $@convention(thin) (@in_guaranteed Foo) -> ()
>>>>>>> 
>>>>>>>  sil @f : $@convention(thin) (@guaranteed Foo) -> () {
>>>>>>>  bb0(%0 : $Foo):
>>>>>>>%1 = function_ref @g : $@convention(thin) (@in_guaranteed Foo) -> ()
>>>>>>>%2 = alloc_stack $Foo
>>>>>>>%3 = copy_value %0 : $Foo
>>>>>>>store %3 to [init] %2 : $Foo
>>>>>>>apply %1(%2) : $@convention(thin) (@in_guaranteed Foo) -> ()
>>>>>>>%4 = load [take] %2 : $*Foo
>>>>>>>destroy_value %4 : $Foo
>>>>>>>dealloc_stack %2 : $Foo
>>>>>>>...
>>>>>>>  }
>>>>>>> 
>>>>>>> `store_borrow` allows us to express this in a more efficient and 
>>>>>>> expressive SIL:
>>>>>>> 
>>>>>>>  sil @f : $@convention(thin) (@guaranteed Foo) -> () {
>>>>>>>  bb0(%0 : $Foo):
>>>>>>>%1 =

Re: [swift-dev] Proposal: SIL Ownership Model + Verifier

2016-12-08 Thread Andrew Trick via swift-dev

> On Dec 7, 2016, at 11:25 PM, John McCall via swift-dev  
> wrote:
> 
>> 
>> On Dec 7, 2016, at 2:13 PM, Michael Gottesman via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> This is a proposal for a new SIL Ownership Model and verifier. An online 
>> HTML version of the document is available here:
>> 
>> https://gottesmm.github.io/proposals/sil-ownership-model.html 
>> 
>> 
>> and inline below.
>> 
>> Michael
>> 
>> 
>> 
>> # Summary
>> 
>> This document defines a SIL ownership model and a compile time static 
>> verifier
>> for the model. This will allow for static compile time verification that a 
>> SIL
>> program satisfies all ownership model constraints.
>> 
>> The proposed SIL ownership model embeds ownership into SIL's SSA def-use
>> edges. This is accomplished by:
>> 
>> 1. Formalizing into SIL API's the distinction in between defs
>>(e.g. `SILInstruction` and `SILArgument`) and the values produced by defs
>>(e.g. `SILValue`). This is needed to model values as having ownership and
>>defs as not having ownership. The main implication here is that the two 
>> can
>>no longer be implicitly convertible and the API must enforce this.

This proposal is simultaneously proposing some specific API details
while avoiding both the motivation behind it and the eventual features
that it will support.

I think the ValueBase/Def renaming is a little
misunderstanding. "ValueDef" in the proposal was a placeholder (not a
perfect name) for some perceived need to have a common
SILArgument/SILInstruction base class. That's probably not necessary
in which case there's nothing to disagree about.

John's counter proposal solves that problem by repurposing ValueBase
to serve as a base class for value definitions (and then goes into
some detail on implementing multi-result instructions).

> We currently have two kinds of def: instructions and arguments.  Arguments
> always define a single value, and I don't see anything in your proposal that
> changes that.  And the idea that an instruction produces exactly one value is
> already problematic, because many don't produce a meaningful value at all.
> All that changes in your proposal is that certain instructions need to be able
> to produce multiple values.

That’s an obvious way of looking at it. I personally am most
interested in putting an end to the chronic problem of conflating
instructions and values which literally makes it impossible to have a
sane discussion about ownership. I insisted that SILInstruction not
derive from ValueBase, which probably led to the proposed
renaming. This probably comes across as confusing because the proposal
is deliberately side-stepping the issue of multi-result instructions.

What I really want to see at the proposal level is agreement on core concepts:
- A value has a type, ownership, one def, and 0..n uses
- Ownership rules are guaranteed simply by evaluating those 0..n uses.
- A value’s def/use is the point at which it is produced/consumed.
- Use/def points are demarcated by instructions or block boundaries
- An instruction produces values via results or consumes them via operands.

There shouldn't be any debate about these concepts, so why is there so
much confusion? I think caused by some bad choices in the SIL
interface, particularly as SILInstruction : ValueBase.

So we should define a SIL interface that reflects those core
concepts. We should be able to reimplement multi-result instructions
without affecting those interfaces and without rewritting SIL passes.

-Andy

> 
> Moreover, the word "def" clearly suggests that it refers to the definition of 
> a
> value that can be used, and that's how the term is employed basically 
> everywhere.
> 
> So allow me to suggest that a much clearer way of saying what you're trying to
> say is that we need to distinguish between defs and instructions.  An 
> instruction
> may have an arbitrary number of defs, possibly zero, and each def is a value
> that can be used.  (But the number of defs per instruction is known statically
> for most instructions, which is something we can use to make working with
> defs much less annoying.)
> 
> Also this stuff you're saying about values having ownership and defs not 
> having
> ownership is, let's say, misleading; it only works if you're using a 
> meaninglessly
> broad definition of ownership.  It would be better to simply say that the 
> verification
> we want to do for ownership strongly encourages us to allow instructions to 
> introduce multiple defs whose properties can be verified independently.
> 
>> 2. Specifying a set of ownership kinds and specifying a method for mapping a
>>`SILValue` to an ownership kind.
>> 3. Specifying ownership constraints on all `SILInstruction`s and 
>> `SILArgument`s
>>that constrain what ownership kinds their operands and incoming values
>>respectively can possess.
>> 4. Implementing a verifier to ensure that all

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

2017-01-09 Thread Andrew Trick via swift-dev

> On Jan 8, 2017, at 11:15 PM, Slava Pestov  wrote:
> 
> Assertion failed: (hasVal), function getValue, file 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/llvm/include/llvm/ADT/Optional.h,
>  line 122.
> 
> This has been failing on and off all day… has anyone tried reproducing it 
> locally?
> 
> Slava

No, I don’t know what started this either.
Filed  Public CI build bot failures: Assert 
ADT/Optional.h, line 122: LSValue::reduceInner.
-Andy

> 
>> On Jan 8, 2017, at 11:11 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#7835]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-RA-osx/7835/ 
>> 
>> Project: oss-swift-incremental-RA-osx
>> Date of build:   Sun, 08 Jan 2017 23:05:01 -0800
>> Build duration:  6 min 4 sec
>> Identified problems:
>> 
>> Assertion failure: This build failed because of an assertion failure. Below 
>> is a list of all errors in the build log:
>> Indication 1 
>> 
>> Changes
>> 
>> Commit 844765b2fc7217d49712e85b8dec5e92e1492db7 by spestov:
>> SILOptimizer: Clean up hasDynamicSelfTypes() and
>> 
>> edit: include/swift/SILOptimizer/Utils/Local.h
>> edit: lib/SILOptimizer/Transforms/PerformanceInliner.cpp
>> edit: lib/SILOptimizer/IPO/UsePrespecialized.cpp
>> edit: lib/SILOptimizer/Utils/Generics.cpp
>> edit: lib/SILOptimizer/Utils/Local.cpp
>> 
>> Commit 7731d4c6cb406f808a3ea1c2519e2481e858e7fd by spestov:
>> Sema: Remove some unnecessary calls to getCanonicalType()
>> 
>> edit: lib/IDE/CodeCompletion.cpp
>> edit: lib/Sema/ConstraintSystem.cpp
>> edit: lib/AST/GenericSignature.cpp
>> edit: lib/AST/Availability.cpp
>> edit: lib/AST/ProtocolConformance.cpp
>> edit: lib/Sema/TypeCheckAttr.cpp
>> edit: lib/Sema/PlaygroundTransform.cpp
>> edit: lib/Sema/TypeCheckStmt.cpp
>> edit: lib/Sema/CSApply.cpp
>> edit: lib/Sema/CSDiag.cpp
>> edit: lib/Sema/TypeCheckProtocol.cpp
>> edit: lib/IDE/TypeReconstruction.cpp
>> edit: lib/AST/Substitution.cpp
>> edit: lib/AST/DiagnosticEngine.cpp
>> edit: lib/AST/ASTVerifier.cpp
>> edit: lib/Sema/CSGen.cpp
>> 
>> Commit 208dec74d01621880895d7b05fb1b38a69c68d2f by spestov:
>> Sema: Validate addressors when an AbstractStorageDecl is validated
>> 
>> edit: lib/Sema/CodeSynthesis.cpp
>> edit: lib/Sema/TypeCheckDecl.cpp
>> 
>> Commit 02185c30ee361118f457663d4fb0211bd24abfbb by spestov:
>> Sema: When validating members for layout, skip certain members
>> 
>> edit: lib/Sema/TypeChecker.cpp
>> add: validation-test/compiler_scale/enum_members.gyb
>> add: validation-test/compiler_scale/struct_members.gyb
>> 
>> Commit 6c75bf8dc5072d65f204b5724930523376366c20 by spestov:
>> Update source-stability test
>> 
>> edit: test/api-digester/source-stability.swift.expected
> 

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

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

2017-01-09 Thread Andrew Trick via swift-dev


> On Jan 9, 2017, at 12:00 AM, Andrew Trick via swift-dev  
> wrote:
> 
>> On Jan 8, 2017, at 11:15 PM, Slava Pestov > <mailto:spes...@apple.com>> wrote:
>> 
>> Assertion failed: (hasVal), function getValue, file 
>> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/llvm/include/llvm/ADT/Optional.h,
>>  line 122.
>> 
>> This has been failing on and off all day… has anyone tried reproducing it 
>> locally?
>> 
>> Slava
> 
> No, I don’t know what started this either.
> Filed > Public CI build bot 
> failures: Assert ADT/Optional.h, line 122: LSValue::reduceInner.
> -Andy

The first occurrence I found was a stdlib commit, which isn’t very revealing:
https://ci.swift.org/job/oss-swift-incremental-RA-osx/7822/consoleFull#1440893218c38edd5a-00f9-40a2-abac-1db59f7a90ca
 
<https://ci.swift.org/job/oss-swift-incremental-RA-osx/7822/consoleFull#1440893218c38edd5a-00f9-40a2-abac-1db59f7a90ca>

-Andy

> 
>> 
>>> On Jan 8, 2017, at 11:11 PM, no-re...@swift.org <mailto:no-re...@swift.org> 
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-osx [#7835]
>>> 
>>> Build URL:  https://ci.swift.org/job/oss-swift-incremental-RA-osx/7835/ 
>>> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/7835/>
>>> Project:oss-swift-incremental-RA-osx
>>> Date of build:  Sun, 08 Jan 2017 23:05:01 -0800
>>> Build duration: 6 min 4 sec
>>> Identified problems:
>>> 
>>> Assertion failure: This build failed because of an assertion failure. Below 
>>> is a list of all errors in the build log:
>>> Indication 1 
>>> <https://ci.swift.org//job/oss-swift-incremental-RA-osx/7835/consoleFull#1440893218c38edd5a-00f9-40a2-abac-1db59f7a90ca>
>>> Changes
>>> 
>>> Commit 844765b2fc7217d49712e85b8dec5e92e1492db7 by spestov:
>>> SILOptimizer: Clean up hasDynamicSelfTypes() and
>>> 
>>> edit: include/swift/SILOptimizer/Utils/Local.h
>>> edit: lib/SILOptimizer/Transforms/PerformanceInliner.cpp
>>> edit: lib/SILOptimizer/IPO/UsePrespecialized.cpp
>>> edit: lib/SILOptimizer/Utils/Generics.cpp
>>> edit: lib/SILOptimizer/Utils/Local.cpp
>>> 
>>> Commit 7731d4c6cb406f808a3ea1c2519e2481e858e7fd by spestov:
>>> Sema: Remove some unnecessary calls to getCanonicalType()
>>> 
>>> edit: lib/IDE/CodeCompletion.cpp
>>> edit: lib/Sema/ConstraintSystem.cpp
>>> edit: lib/AST/GenericSignature.cpp
>>> edit: lib/AST/Availability.cpp
>>> edit: lib/AST/ProtocolConformance.cpp
>>> edit: lib/Sema/TypeCheckAttr.cpp
>>> edit: lib/Sema/PlaygroundTransform.cpp
>>> edit: lib/Sema/TypeCheckStmt.cpp
>>> edit: lib/Sema/CSApply.cpp
>>> edit: lib/Sema/CSDiag.cpp
>>> edit: lib/Sema/TypeCheckProtocol.cpp
>>> edit: lib/IDE/TypeReconstruction.cpp
>>> edit: lib/AST/Substitution.cpp
>>> edit: lib/AST/DiagnosticEngine.cpp
>>> edit: lib/AST/ASTVerifier.cpp
>>> edit: lib/Sema/CSGen.cpp
>>> 
>>> Commit 208dec74d01621880895d7b05fb1b38a69c68d2f by spestov:
>>> Sema: Validate addressors when an AbstractStorageDecl is validated
>>> 
>>> edit: lib/Sema/CodeSynthesis.cpp
>>> edit: lib/Sema/TypeCheckDecl.cpp
>>> 
>>> Commit 02185c30ee361118f457663d4fb0211bd24abfbb by spestov:
>>> Sema: When validating members for layout, skip certain members
>>> 
>>> edit: lib/Sema/TypeChecker.cpp
>>> add: validation-test/compiler_scale/enum_members.gyb
>>> add: validation-test/compiler_scale/struct_members.gyb
>>> 
>>> Commit 6c75bf8dc5072d65f204b5724930523376366c20 by spestov:
>>> Update source-stability test
>>> 
>>> edit: test/api-digester/source-stability.swift.expected
>> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org <mailto:swift-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev 
> <https://lists.swift.org/mailman/listinfo/swift-dev>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

2017-01-09 Thread Andrew Trick via swift-dev

This crasher is still failing to crash on Ubuntu 14.04 (crashes as expected on 
16). I can’t imagine why the test would behave differently with the same target 
triple (x86_64-unknown-linux-gnu). Does anyone know how to REQUIRES: some-host? 
If not, I can lump this into deterministic-behavior.
-Andy

> On Jan 9, 2017, at 5:31 AM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#489]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/489/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Mon, 09 Jan 2017 04:59:29 -0800
> Build duration:   31 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 ed36d8f7e5d35b079f2bac3baf0e1818d44c8d32 by practicalswift:
> [swiftc (53 vs. 5396)] Add crasher in swift::TupleType::get
> 
> add: 
> validation-test/compiler_crashers/28637-swift-tupletype-get-llvm-arrayref-swift-tupletypeelt-swift-astcontext-const.swift

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

[swift-dev] Proposal: Opaque SIL values

2017-01-24 Thread Andrew Trick via swift-dev

I’m sending out a proposal for fundamentally changing SIL. This work feeds into generic code optimization, resilience, semantic ARC, and SIL ownership. This was discussed at length back in October—some info went out on swift-dev—but I realized there hasn’t been a formal proposal. So here it is. I want to make sure enough people have seen this before pushing my PR that puts the infrastructure in place: https://github.com/apple/swift/pull/6922.Rendered Proposal: https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7Markdown:# SIL Opaque Values

# Introduction

A SIL type is either loadable or address-only. A loadable type is one
whose object size and layout can be determined by the compiler *and*
whose values are not "pinned" to a memory address. Types are most
commonly address-only because their layout is opaque by
abstraction. Generic type parameters are address-only because their
concrete type not statically identified. Resilient types are
statically identified, but have opaque layout for binary
compatibility.

Compiled code must access and pass address-only objects via their
memory addresses. We refer to this as "physical" access, as expressed
by LLVM IR. Currently, SIL also reflects physical access. For example,
SIL for a generic function relies on address types:
```
sil @identity : $ (@in T) -> @out T {
bb0(%0 : $*T, %1 : $*T):
  copy_addr %1 to [initialization] %0 : $*T
  destroy_addr %1 : $*T
  %4 = tuple ()
  return %4 : $()
}
```

If the generic type is bound to a loadable type, then the SIL values
are promoted to value types:
```
// generic specialization  of identity  (T) -> T
sil @identity : $(Int) -> Int {
bb0(%0 : $Int):
  return %0 : $Int
}
```

This leads to drastically different SIL patterns in code that is
semantically almost identical. A key aspect of optimizing SIL is
converting values from an in-memory form to an SSA value. Being
address-only currently prevents opaque values from taking part in
normal optimization. Naturally, opaque types must limit some
optimizations, such as inlining. However, an important feature of the
SIL optimizer is copy elimination and by extension ARC operations,
which applies equally to opaque and loadable types.

This SIL code creates an unnecessary local copy:
```
%copy = alloc_stack $T
copy_addr %arg to [initialization] %copy : $*T
...
%ret = apply %callee(%copy) : $@convention(thin) <Ï_0_0> (@in Ï_0_0) -> ()
...
dealloc_stack %copy : $*T
destroy_addr %arg : $*T
```

The same code expressed in SSA reveals that the copy is redundant:
```
%copy = copy_value %arg : $T
...
%ret = apply %callee(%copy) : $@convention(thin) <Ï_0_0> (@in Ï_0_0) -> ()
...
destroy_value %arg : $T
```
Redundancy can be inferred from these facts: `%arg` by definition cannot mutate, it is consumed in-scope by a `destroy_value`, and `%arg` is not copied again after `%copy` has been consumed:
 
The address-only property of arguments determines physical calling
conventions in LLVM IR. These conventions cannot be complete hidden
from SIL code. In particular, SIL is responsible for handling
reabstraction of function types. If the caller and callee have
different views of an argument type, then a SIL-level thunk is
required to bridge between the two conventions.

For example, a concrete function may satisfy a protocol with generic
constraints. A protocol witness thunk will be generated to load the
address-only arguments and store address-only results. An extra copy
is also generated to convert a guaranteed self argument to owned:
```
sil @foo : $@convention(method) (Int, S) -> Int {
bb0(%0 : $Int, %1 : $S):
  return %0 : $Int
}

// protocol witness for P.foo (A.T) -> A.T in conformance S : P
sil [thunk] @_TTWV1t1SS_1PS_FS1_3foofwx1TwxS2_
  : $@convention(witness_method) (@in Int, @in_guaranteed S) -> @out Int {
bb0(%0 : $*Int, %1 : $*Int, %2 : $*S):
  %3 = load [trivial] %1 : $*Int
  %4 = load [trivial] %2 : $*S
  %5 = function_ref @foo : $@convention(method) (Int, S) -> Int
  %6 = apply %5(%3, %4) : $@convention(method) (Int, S) -> Int
  store %6 to [trivial] %0 : $*Int
  %8 = tuple ()
  return %8 : $()
}
```

Conceivably, the address-only types in the thunk could be expressed as SSA values. However, the `@in`, `@in_guaranteed` parameter conventions must remain to communicate indirection to the SIL compiler:
```
// protocol witness for P.foo (A.T) -> A.T in conformance S : P
sil [thunk] @_TTWV1t1SS_1PS_FS1_3foofwx1TwxS2_
  : $@convention(witness_method) (@in Int, @in_guaranteed S) -> @out Int {
bb0(%0 : $Int, %1 : $*S):
  %2 = function_ref @foo : $@convention(method) (Int, S) -> Int
  %3 = apply %2(%0, %1) : $@convention(method) (Int, S) -> Int
  return %3 : $Int
}
```

This proposal argues that address-only SIL values should be
represented within SIL function bodies as SSA values, unless SIL
semantics would otherwise require an address even if the value's type
were loadable. SIL parameter and result conventions will continue to
reflect argument indirection. Two SIL function sig

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

2017-01-24 Thread Andrew Trick via swift-dev

I’m trying to revert this now: https://github.com/apple/swift/pull/7022 

-Andy

> On Jan 24, 2017, at 8:22 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#1474]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/1474/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Tue, 24 Jan 2017 19:23:39 -0800
> Build duration:   58 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 1 test(s), Passed: 8860 test(s), Total: 8861 test(s)
> Failed: Swift(linux-x86_64).SILOptimizer.swap_refcnt.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 305 test(s), Total: 305 test(s)
> 
> Changes
> 
> Commit fa834e2f803a6233ca2092b162820a372768b63a by springsupport:
> [ClangImporter] Teach the importer about more infix operators between
> 
> edit: lib/ClangImporter/ImportMacro.cpp
> add: test/ClangImporter/macro_literals.swift
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: test/ClangImporter/macros.swift
> edit: test/Inputs/clang-importer-sdk/usr/include/macros.h
> 
> Commit 6bdbcb2bfceaad6439ec0a4dab8c6fd7e25487d4 by springsupport:
> Update CHANGELOG
> 
> edit: CHANGELOG.md
> 
> Commit 02441e4e69614a8790475ac7d04d4f87df913ed5 by nmersethcook:
> Add a short delay before cleaning a build
> 
> edit: utils/build-script
> 
> Commit 27e676614fcb78d35f40ab94ea98e533b5d0855d by atrick:
> Reenable swap_refcnt.swift test.
> 
> edit: test/SILOptimizer/swap_refcnt.swift
> 
> Commit 21ff1ba378aad0677c198a133e8ae6421af199db by eeckstein:
> Mangling: fix wrong re-mangling of identifier-like node substitutions.
> 
> edit: lib/Basic/Remangler.cpp
> edit: test/Demangle/Inputs/manglings.txt
> 
> Commit f15075f88b977f27a06f37925a3912b59f2f2521 by eeckstein:
> Mangling: fix the check if a new mangled name contains an old mangled
> 
> edit: lib/Basic/Mangler.cpp
> 
> Commit 8ad5504fe0f1a86950a10163b169043a549e846d by spestov:
> SILGen: Relax assertion in tuple-to-optional function result conversion
> 
> edit: test/SILGen/function_conversion.swift
> edit: lib/SILGen/SILGenPoly.cpp
> add: validation-test/compiler_crashers_2_fixed/0065-sr3706.swift
> 
> Commit e45720b29106bcd512651f08cbcbf4c18cbe6e5b by seergy_pro:
> [Documentation] Add doc comments for NSCoder
> 
> edit: Foundation/NSCoder.swift

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

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

2017-01-24 Thread Andrew Trick via swift-dev

Mishal,

I don’t see a failure here do you? What’s the magic string to search for in the 
console output?

-Andy

> On Jan 24, 2017, at 9:43 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1549]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1549/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Tue, 24 Jan 2017 21:34:36 -0800
> Build duration:   8 min 56 sec
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8863 test(s), Total: 8863 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 305 test(s), Total: 305 test(s)
> 
> Changes
> 
> Commit cd18eea38b24cf905a7863f558d07f3ef7d0ca78 by atrick:
> Revert "Reenable swap_refcnt.swift test."
> 
> edit: test/SILOptimizer/swap_refcnt.swift

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

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

2017-01-24 Thread Andrew Trick via swift-dev


> On Jan 24, 2017, at 10:21 PM, Mishal Shah  wrote:
> 
> Hi Andy, 
> 
> Test Case 'TestNSData.testInitializationWithArray' started at 23:43:08.786
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>  symbol lookup error: 
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>  undefined symbol: 
> _TFesRxs17_MutableIndexablewx5Indexs10StrideableWxS0_6Stride_s13SignedIntegerrS_g9subscriptFGVs14CountableRangewxS0__wx11SubSequence
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 127, aborting
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 1, aborting
> Build step 'Execute shell' marked build as failure
> 
> Mishal Shah

Thanks :) — For some reason I thought the fatal script error was just triggered 
by a much earlier test case.

So it looks like the Foundation tests haven’t been run for a few builds. Taking 
a wild guess, could this have something to do with mangling Erik?

Mishal, this bot looks full-on “Incremental” and Jenkins won’t let me login to 
clean the workspace. Can you do that?

-Andy

> On Tue, Jan 24, 2017 at 9:46 PM, Andrew Trick via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> Mishal,
> 
> I don’t see a failure here do you? What’s the magic string to search for in 
> the console output?
> 
> -Andy
> 
>> On Jan 24, 2017, at 9:43 PM, no-re...@swift.org <mailto:no-re...@swift.org> 
>> wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1549]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1549/ 
>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1549/>
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Tue, 24 Jan 2017 21:34:36 -0800
>> Build duration:  8 min 56 sec
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8863 test(s), Total: 8863 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 305 test(s), Total: 305 test(s)
>> 
>> Changes
>> 
>> Commit cd18eea38b24cf905a7863f558d07f3ef7d0ca78 by atrick:
>> Revert "Reenable swap_refcnt.swift test."
>> 
>> edit: test/SILOptimizer/swap_refcnt.swift
> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org <mailto:swift-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev 
> <https://lists.swift.org/mailman/listinfo/swift-dev>
> 
> 

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

Re: [swift-dev] Proposal: Opaque SIL values

2017-01-24 Thread Andrew Trick via swift-dev

> On Jan 24, 2017, at 8:56 PM, Chris Lattner  wrote:
> 
> 
>> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> I’m sending out a proposal for fundamentally changing SIL. This work feeds 
>> into generic code optimization, resilience, semantic ARC, and SIL ownership. 
>> This was discussed at length back in October—some info went out on 
>> swift-dev—but I realized there hasn’t been a formal proposal. So here it is. 
>> I want to make sure enough people have seen this before pushing my PR that 
>> puts the infrastructure in place: https://github.com/apple/swift/pull/6922 
>> <https://github.com/apple/swift/pull/6922>.
>> 
>> Rendered Proposal: 
>> https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7' 
>> <https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7'>
> This is great Andy, thanks for pushing it forward.  One question: are you 
> concerned at all that the SSA representation of address only values will make 
> it “too easy” for the optimizer to reorder instruction such that a lot more 
> temporary values will been needed in lowering?
> 
> -Chris
> 

That would come about when the program wants to use the same lvalue for 
multiple real values. I don't expect many problems with simple opaque types. 
The only way to mutate them is either passing them @inout or returning them 
@out. We could introduce a copy by sinking a use below one of these calls. But 
the uses are also likely to be calls.

It could happen. The typically annoying case with copy coalescing in general is 
induction variables that are both modified in the loop and live out of the 
loop. I wasn't even able to force a scenario like this with Swift opaque values 
that didn't already generate a copy up front.

There's definitely an issue with all the temporaries needed to inject opaque 
values into aggregates. Address lowering needs to be smart about this, but I 
have a straightforward storage allocation algortihm in mind that should take 
care of the expected cases. I'm anxious to try out a prototype and get some 
data.

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

Re: [swift-dev] Proposal: Opaque SIL values

2017-01-26 Thread Andrew Trick via swift-dev

> On Jan 25, 2017, at 6:13 PM, Joe Groff  wrote:
> 
>> Naturally, opaque types must limit some optimizations, such as inlining.
> 
> I don't see how opaque types by themselves prevent inlining. You can inline a 
> generic into another generic, or a function using a resilient type into 
> another function.

Good point. I was just hand-waving here about resilient types, which we can’t 
inline by design, and archetypes where we can’t inline protocol methods because 
method resolution requires specialization. But yeah, we should be inlining 
methods on unbound generic nominal types. I updated the doc.

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

Re: [swift-dev] Proposal: Opaque SIL values

2017-01-26 Thread Andrew Trick via swift-dev


> On Jan 25, 2017, at 4:22 PM, Karl Wagner  wrote:
> 
> 
>> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> I’m sending out a proposal for fundamentally changing SIL. This work feeds 
>> into generic code optimization, resilience, semantic ARC, and SIL ownership. 
>> This was discussed at length back in October—some info went out on 
>> swift-dev—but I realized there hasn’t been a formal proposal. So here it is. 
>> I want to make sure enough people have seen this before pushing my PR that 
>> puts the infrastructure in place: https://github.com/apple/swift/pull/6922 
>> <https://github.com/apple/swift/pull/6922>.
>> 
>> Rendered Proposal: 
>> https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7 
>> <https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7>
>> 
>> Markdown:
>> 
>> 
>> -Andy
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> I won’t pretend to understand all of the implications of this, but as a 
> newcomer to the codebase I found SILGen (particularly lowering) extremely 
> confusing to unpick.
> 
> The simplification and separation described here makes a lot of sense to me, 
> and I believe it would make it easier for myself and others to contribute to 
> the project. As do your comments in the PR about using consistent idioms 
> throughout the compiler.
> 
> So as far as those things are considerations, I’m really happy with this 
> proposal.
> 
> - Karl


Thanks. I appreciate the encouragement. I’m actually trying not to add more 
complexity without offering some way to reason about it.

I added another section to the proposal that offers some background:
https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7#sil-types-and-argument-conventions
 
<https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7#sil-types-and-argument-conventions>

...
Here's how this design fits into broader picture of the layers of
abstraction in the type system:

- Formal types: The AST types directly exposed by the language.
  (e.g. `T?`)

- Canonical types: desugared formal AST types.
  (e.g. `Optional`)

- Lowered types: Canonical types in the ASTContext that can be
  directly referenced by SIL. These "formalize" some properties of the
  ABI. For example, they make the ownership and indirection of
  function arguments explicit. These formalized conventions must match
  on both the caller and callee side of every call. Lowered types
  include types that aren't part of the language's formal type
  system. See SILFunctionType.  Although these types have been lowered
  for use by SIL, they exist independent of a SILModule.
  (e.g. `@in Optional`)

- SIL types: The actual type associated with a SIL value. These merely
  wrap a lowered type with a flag indicating whether the SIL value
  has indirect SIL semantics. i.e. whether the value is an address or
  an object type. SIL types are part of a SILModule, and reflect the
  SILModule's conventions. Mapping lowered types to SIL types is
  specific to the current SIL stage.
  (`e.g. $Optional`)

- SIL storage types: These are SIL types with lowered addresses.  They
  represent the ABI requirements for indirection and storage of SIL
  objects. In the "lowered" SIL stage, the SIL type of every value is
  its storage type. Lowered types directly correspond to SIL storage
  types. For example, if a function parameter has an `@in` lowered type, then
  the storage type of the corresponding SIL argument is an address.
  (`e.g. $*Optional`)

- LLVM types: Represent the ABI requirements in terms of C types. This
  could introduce additional indirection, but I'd like to handle most
  if not all of that in SIL address lowering.
  (e.g. `%Sq* noalias nocapture, %swift.type* %T`)
  
So to recap, if you ask for the SIL type corresponding to a formal
convention, you'll get the SIL *storage* type
(e.g. `$*Optional`). If you ask for the SIL type for a function
argument corresponding to the same formal parameter, you will get the
right level of indirection for the current SIL stage
(e.g. `$Optional`). In short, the lowered type may specify a calling
convention that expects indirect storage, while the SIL type may be
direct.

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

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

2017-01-26 Thread Andrew Trick via swift-dev

Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
want to get feedback on how Swift compiler devs plan to use `clang-format`. 
(BTW, here's the PR https://github.com/apple/swift/pull/6922).

During the code review, I ran `git clang-format` as part of being a good 
citizen. There's only one problem with the tool. It rewraps long boolean 
expressions, hiding those unsightly operators at the end of lines (after all 
who wants to see those?).

if (some_expression->with_calls() ||
another_expression->with(nested_calls()) &&
an_even_longer_expression->making_your_eyes->glaze_over())

I don't get involved in style wars, but this is not a style change, it's an 
objective code quality degradation. It's a demonstrably bug-prone thing to do. 
It's hurt me too many times in the past, and I'm not happy using a formatting 
tool that injects future bugs and harms code comprehension.

When the LLVM coding style was originally ratified, this aspect was left up to 
individual preference and didn't get any discussion AFAIK. I think
clang-format then ended up with a `BreakBeforeBinaryOperators: None` style out 
of sheer inertia. 

So, how should I use clang-format on Swift compiler code? Vote please.

** Option 1: Add a simple configuration option to swift/.clang-format:

1a. BreakBeforeBinaryOperators: All

1b. BreakBeforeBinaryOperators: NonAssignment

I have absolutely no preference between 1a and 1b. It's purely style.

1a:
SomeLongTypeName someLongVariableName =
  someLongExpression();

1b:
SomeLongTypeName someLongVariableName
  = someLongExpression();

** Option 2: Contributors each tweak clang-format according to their (in my 
case strong) bias:

My own command line:
2a. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: All}"
2b. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: NonAssignment}"

** Option 3: Don't bother using clang-format.

Let emacs do its indentation thing. Embrace idiosyncrasies in the code base.

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

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

2017-01-26 Thread Andrew Trick via swift-dev


> On Jan 26, 2017, at 9:11 AM, Ben Langmuir  wrote:
>> 
>> ** Option 1: Add a simple configuration option to swift/.clang-format:
>> 
>> 1a. BreakBeforeBinaryOperators: All
>> 
>> 1b. BreakBeforeBinaryOperators: NonAssignment
> 
>> 
>> I have absolutely no preference between 1a and 1b. It's purely style.
>> 
>> 1a:
>> SomeLongTypeName someLongVariableName =
>> someLongExpression();
>> 
>> 1b:
>> SomeLongTypeName someLongVariableName
>> = someLongExpression();
> 
> 1b sounds good to me.

I contradicted myself above. If you like the style shown in (1b), the 
configuration option is actually BreakBeforeBinaryOperators: All.

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

Re: [swift-dev] Proposal: Opaque SIL values

2017-01-26 Thread Andrew Trick via swift-dev


> On Jan 26, 2017, at 8:33 AM, John McCall  wrote:
> 
>> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> I’m sending out a proposal for fundamentally changing SIL. This work feeds 
>> into generic code optimization, resilience, semantic ARC, and SIL ownership. 
>> This was discussed at length back in October—some info went out on 
>> swift-dev—but I realized there hasn’t been a formal proposal. So here it is. 
>> I want to make sure enough people have seen this before pushing my PR that 
>> puts the infrastructure in place: https://github.com/apple/swift/pull/6922 
>> <https://github.com/apple/swift/pull/6922>.
>> 
>> Rendered Proposal: 
>> https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7 
>> <https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7>
>> 
>> Markdown:
>> 
> 
> We've already talked about this at length, so I just want to say for the 
> record that it looks great, and thanks for taking this on.
> 
> What's the purpose of SILFunctionConventions?  To provide a context with 
> which to interpret the information in SILFunctionType?
> 
> John.

Yes, that’s the motivating factor. SILFunctionTypes are created as part of the 
ASTContext and I believe they should be immutable. A function's type should 
never change. SILFunctionConventions is a transient view of that type 
corresponding to the module’s current conventions.

I hope the separation of APIs also helps make the distinction between lowered 
types and SIL types. It’s hard for me to even talk about that distinction since 
they’ve always been the same thing.

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

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

2017-01-26 Thread Andrew Trick via swift-dev


> On Jan 26, 2017, at 9:29 AM, Ben Langmuir  wrote:
> 
>> 
>> On Jan 26, 2017, at 9:14 AM, Andrew Trick > > wrote:
>> 
>> 
>>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir >> > wrote:
 
 ** Option 1: Add a simple configuration option to swift/.clang-format:
 
 1a. BreakBeforeBinaryOperators: All
 
 1b. BreakBeforeBinaryOperators: NonAssignment
>>> 
 
 I have absolutely no preference between 1a and 1b. It's purely style.
 
 1a:
 SomeLongTypeName someLongVariableName =
 someLongExpression();
 
 1b:
 SomeLongTypeName someLongVariableName
 = someLongExpression();
>>> 
>>> 1b sounds good to me.
>> 
>> I contradicted myself above. If you like the style shown in (1b), the 
>> configuration option is actually BreakBeforeBinaryOperators: All.
> 
> Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check 
> your example code against the above description :-)

Alright, I’l reformat my PR with that config, unless anyone else wants to weigh 
in.

Incidentally, I despise what clang-format does with asserts now:
  assert(condition
 && “text”)

It’s a consequence of us not using a legit assert package, so I don’t know if I 
want to push to get clang-format changed.

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

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

2017-01-26 Thread Andrew Trick via swift-dev


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

assert((precondition1 || predcondition2) &&
   “informative message”)

The boolean operator is filling in for a comma. That’s how it’s meant to be 
parsed by the reader. It’s presence in the code is purely distracting. From the 
tool’s point of view, it’s tautological so shouldn’t be given significance as a 
boolean operator.

-Andy

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

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

2017-01-26 Thread Andrew Trick via swift-dev


> On Jan 26, 2017, at 10:34 AM, Andrew Trick via swift-dev 
>  wrote:
> 
> 
>> On Jan 26, 2017, at 10:25 AM, Jordan Rose > <mailto:jordan_r...@apple.com>> wrote:
>> 
>>> 
>>> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev >> <mailto:swift-dev@swift.org>> wrote:
>>> 
>>>> 
>>>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir >>> <mailto:blangm...@apple.com>> wrote:
>>>> 
>>>>> 
>>>>> On Jan 26, 2017, at 9:14 AM, Andrew Trick >>>> <mailto:atr...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir >>>>> <mailto:blangm...@apple.com>> wrote:
>>>>>>> 
>>>>>>> ** Option 1: Add a simple configuration option to swift/.clang-format:
>>>>>>> 
>>>>>>> 1a. BreakBeforeBinaryOperators: All
>>>>>>> 
>>>>>>> 1b. BreakBeforeBinaryOperators: NonAssignment
>>>>>> 
>>>>>>> 
>>>>>>> I have absolutely no preference between 1a and 1b. It's purely style.
>>>>>>> 
>>>>>>> 1a:
>>>>>>> SomeLongTypeName someLongVariableName =
>>>>>>> someLongExpression();
>>>>>>> 
>>>>>>> 1b:
>>>>>>> SomeLongTypeName someLongVariableName
>>>>>>> = someLongExpression();
>>>>>> 
>>>>>> 1b sounds good to me.
>>>>> 
>>>>> I contradicted myself above. If you like the style shown in (1b), the 
>>>>> configuration option is actually BreakBeforeBinaryOperators: All.
>>>> 
>>>> Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check 
>>>> your example code against the above description :-)
>>> 
>>> Alright, I’l reformat my PR with that config, unless anyone else wants to 
>>> weigh in.
>>> 
>>> Incidentally, I despise what clang-format does with asserts now:
>>>   assert(condition
>>>  && “text”)
>>> 
>>> It’s a consequence of us not using a legit assert package, so I don’t know 
>>> if I want to push to get clang-format changed.
>> 
>> What do you want it to do with this style of assert?
> 
> assert((precondition1 || predcondition2) &&
>“informative message”)
> 
> The boolean operator is filling in for a comma. That’s how it’s meant to be 
> parsed by the reader. It’s presence in the code is purely distracting. From 
> the tool’s point of view, it’s tautological so shouldn’t be given 
> significance as a boolean operator.

clang-format bug filed to put this tangent to rest:
https://llvm.org/bugs/show_bug.cgi?id=31772 
<https://llvm.org/bugs/show_bug.cgi?id=31772>

-Andy

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

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

2017-01-26 Thread Andrew Trick via swift-dev

> On Jan 26, 2017, at 11:38 AM, Graydon Hoare  wrote:
> 
> 
>> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev 
>>  wrote:
>> 
>> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
>> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
>> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
>> 
>> During the code review, I ran `git clang-format` as part of being a good 
>> citizen. There's only one problem with the tool. It rewraps long boolean 
>> expressions, hiding those unsightly operators at the end of lines (after all 
>> who wants to see those?).
>> 
>>   if (some_expression->with_calls() ||
>>   another_expression->with(nested_calls()) &&
>>   an_even_longer_expression->making_your_eyes->glaze_over())
>> 
>> I don't get involved in style wars, but this is not a style change, it's an 
>> objective code quality degradation. It's a demonstrably bug-prone thing to 
>> do. It's hurt me too many times in the past, and I'm not happy using a 
>> formatting tool that injects future bugs and harms code comprehension.
> 
> It's funny you'd mention this! I often format code that way, not out of any 
> great love of it, but from muscle-memory of living under an old coding 
> guideline somewhere in the distant past claiming that the ugliness of 
> trailing unfinished-binops draws the eye to them and makes the user pay 
> attention. Doug Crockford recommends this style; but of course Don Knuth 
> agrees with you. I don't feel strongly about them as such, but I feel ... 
> anti-strongly, I guess? Like changing that one thing isn't worth a 
> cross-codebase rewrite / merge collision.

I’m not sure who’s recommending what. The above style obscures operators. Does 
anyone disagree with that? A lot of code has been written in that way; I think 
because developers value aesthetics over clarity, or just don’t think about it. 
I care because when something doesn’t stand out, my brain fills in the gaps 
with whatever it expects. For me, that leads to a bunch of silly logic errors.

I need to see it this way:

  if (some_expression->with_calls()
  || another_expression->with(nested_calls())
  && an_even_longer_expression->making_your_eyes->glaze_over())

The need for parens now stands out. Sorry this isn’t a good example. Nested 
expressions would make it much more compelling.

That’s the coding convention we use for Swift code (at least in the stdlib). 
The compiler C++ code is just a hodge-podge.
If anyone actually thinks trailing operators are a good idea for our code base, 
I won’t argue, but I’ve never heard that argument.

BTW- I’m not interested at all in doing a mass reformatting or forcing a 
convention on people. I just don’t want to apply clang-format to every line of 
code I touch without knowing what settings to use.

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

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

2017-01-26 Thread Andrew Trick via swift-dev

> On Jan 26, 2017, at 4:48 PM, Greg Parker  wrote:
> 
> 
>> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev 
>>  wrote:
>> 
>> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
>> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
>> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
>> 
>> During the code review, I ran `git clang-format` as part of being a good 
>> citizen. There's only one problem with the tool. It rewraps long boolean 
>> expressions, hiding those unsightly operators at the end of lines (after all 
>> who wants to see those?).
>> 
>>   if (some_expression->with_calls() ||
>>   another_expression->with(nested_calls()) &&
>>   an_even_longer_expression->making_your_eyes->glaze_over())
>> 
>> I don't get involved in style wars, but this is not a style change, it's an 
>> objective code quality degradation. It's a demonstrably bug-prone thing to 
>> do. It's hurt me too many times in the past, and I'm not happy using a 
>> formatting tool that injects future bugs and harms code comprehension.
> 
> Counterargument: It's not an objective code quality degradation, it's a style 
> choice that you don't like. 

It’s not about what I’m used to or what I find visually pleasing. It’s been a 
source of bugs in my experience. If my experience is unique, and people want to 
standardize on a different style, then I’ll just have to try to be more careful 
reading the code and write fewer complicated if-conditions.

> The first rule of code style is "do as the rest of the code does". 
> 
> Trailing binary operators are fine, as long as they are consistent. Mixing 
> leading and trailing operators in the same code base is a greater harm to 
> code comprehension than either one is on its own. Any difference between 
> consistently leading and consistently trailing is small, and not worth the 
> pain of a mass rewrite.

That’s why I haven’t brought this up with LLVM project. The style has already 
been standardized (although my old code still wraps operators the right way :). 
I’m not sure anyone thought about this and didn’t want to repeat the same 
mistake in Swift.

I’ve seen both styles in the Swift compiler, although looking around the code 
now my preferred convention seems pretty clearly out of style. I also spent 
time in the standard library code, which has very carefully thought out 
conventions and wraps operators the way I’m recommending. Moving toward that 
style seemed reasonable if most developers agreed.

If I am the only person that feels strongly about it, then we’re probably 
better of standardizing on LLVM’s defaults just because most of the code has 
already done that. So here’s the option I intentionally left out:

Option 4: Standardize Swift style based purely on LLVM.

  Let's standardize the Swift compiler using LLVM’s default style configuration.

> I consider this LLVM and Swift project style to be an objective code quality 
> degradation:
>if (condition)
>single_line_body();
> 
> But the first rule of code style is "do as the rest of the code does", so I 
> write my LLVM and Swift code like that.

I agree. If auto-indenting editors hadn’t solved that problem I’d be arguing 
about that too!

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

[swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-02 Thread Andrew Trick via swift-dev

I'm following up on a resilient dynamic dispatch discussion kicked off by
Slava during a performance team meeting to summarize some key
points on public [swift-dev].

It's easy to get sidetracked by the details of dynamic
dispatch and various ways to generate code. I suggest approaching the
problem by focusing on the ABI aspects and flexibility the ABI affords
for future optimization. I'm including a proposal for one specific
approach (#3) that wasn't discussed yet.

---
#1. (thunk export) The simplest, most flexible way to expose dispatch
across resilience boundaries is by exporting a single per-method entry
point. Future compilers could improve dispatch and gradually expose
more ABI details.

Cost: We're forced to export all those symbols in perpetuity.

[The cost of the symbols is questionable. The symbol trie should compress the
names, so the size may be small, and they should be lazily resolved,
so the startup cost should be amortized].

---
#2. (offset export) An alternative approach was proposed by JoeG a
while ago and revisited in the meeting yesterday. It involves a
client-side vtable offset lookup helper.

This allows more opportunity for micro-optimization on the client
side. This exposes the isa-based vtable mechanism as ABI. However, it
stops short of exposing the vtable layout itself. Guaranteeing vtable
dispatch may become a problem in the future because it forces an
explosion of metadata. It also has the same problem as #1 because the
framework must export a per-method symbol for the dispatch
offset. What's worse, the symbols need to be eagerly resolved (AFAIK).

---
#3. (method index) This is an alternative that I've alluded to before,
but was not discussed in yesterday's meeting. One that makes a
tradeoff between exporting symbols vs. exposing vtable layout. I want
to focus on direct cost of the ABI support and flexibility of this
approach vs. approach #1 without arguing over how to micro-optimize
various dispatching schemes. Here's how it works:

The ABI specifies a sort function for public methods that gives each
one a per-class index. Version availability takes sort precedence, so
public methods can be added without affecting other
indices. [Apparently this is the same approach we're taking with
witness tables].

As with #2 this avoids locking down the vtable format for now--in the
future we'll likely optimize it further. To avoid locking all methods
into the vtable mechanism, the offset can be tagged. The alternative
dispatch mechanism for tagged offsets will be hidden within the
class-defining framework.

This avoids the potential explosion of exported symbols--it's limited
to one per public class. It avoids explosion of metadata by allowing
alternative dispatch for some subset of methods. These tradeoffs can
be explored in the future, independent of the ABI.

---
#3a. (offset table export) A single per-class entry point provides a
pointer to an offset table. [It can be optionally cached on the client
side].

  method_index = immediate
  { // common per-class method lookup
isa = load[obj]
isa = isa & @isa_mask
offset = load[@class_method_table + method_index]
if (isVtableOffset(offset))
  method_entry = load[isa + offset]
else
  method_entry = @resolveMethodAddress(isa, @class_method_table, 
method_index)
  }
  call method_entry

Cost - client code size: Worst case 3 instructions to dispatch vs 1
instruction for approach #1. Method lookups can be combined, so groups
of calls will be more compact.

Cost - library size: the offset tables themselves need to be
materialized on the framework side. I believe this can be done
statically in read-only memory, but that needs to be verified.

ABI: The offset table format and tag bit are baked into the ABI.

---
#3b. (lazy resolution) Offset tables can be completely localized.

  method_index = immediate
  { // common per-class method lookup
isa = load[obj]
offset = load[@local_class_method_table + method_index]
if (!isInitializedOffset(offset)) {
  offset = @resolveMethodOffset(@class_id, method_index)
  store [@local_class_method_table + method_index]
}
if (isVtableOffset(offset))
  method_entry = load[isa + offset]
else
  method_entry = @resolveMethodAddress(isa, @class_id, method_index)
  }
  call method_entry

ABI: This avoids exposing the offset table format as ABI. All that's
needed is a symbol for the class, a single entry point for method
offset resolution, and a single entry point for non-vtable method
resolution.

Benefit: The library no longer needs to statically materialize
tables. Instead they are initialized lazilly in each client module.

Cost: Lazy initialization of local tables requires an extra check and
burns some code size.

---
Caveat:

This is the first time I've thought through approach #3, and it hasn't
been discussed, so there are likely a few things I'm missing at the
moment.

---
Side Note:

Regardless of the resilient dispatch mechanism, within a mod

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

2017-02-03 Thread Andrew Trick via swift-dev

I don’t know what this could have to do with the changes in Runtime.swift. 
Speculatively reverting until it clears up:
https://github.com/apple/swift/pull/7227

ArchetypeBuilder.cpp:2461: auto 
swift::ArchetypeBuilder::getGenericEnvironment(swift::GenericSignature 
*)::(anonymous class)::operator()(swift::ArchetypeBuilder::PotentialArchetype 
*) const: Assertion `(inContext->isEqual(repInContext) || inContext->hasError() 
|| repInContext->hasError()) && "Potential archetype mapping differs from 
representative!"' failed.

1.  While type-checking '_BidirectionalCollectionBox' at 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/swift/stdlib/public/core/ExistentialCollection.swift.gyb:336:16
2.  While validating '_BidirectionalCollectionBox' at 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/swift/stdlib/public/core/ExistentialCollection.swift.gyb:336:16

> On Feb 3, 2017, at 9:08 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10-long-test [#658]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10-long-test/658/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10-long-test
> Date of build:Fri, 03 Feb 2017 08:52:00 -0800
> Build duration:   16 min
> 
> Changes
> 
> Commit 7137bab0c72932464fa950f95ece2193c3ade5f0 by ghoare:
> [Bridging PCH] Teach SourceKit to ignore the bridging-pch driver
> 
> edit: tools/SourceKit/lib/SwiftLang/SwiftASTManager.cpp
> add: test/SourceKit/Misc/ignore_bridging_pch.swift
> 
> Commit 139699432bf1b508bf95cded65936c91393f569f by atrick:
> [stdlib] Resolve unsafeBitCast warnings in Runtime.swift.gyb. (#7116)
> 
> edit: stdlib/public/core/Runtime.swift.gyb
> 
> Commit f24f5d034aab53c6e18ddd49df9d068b8e0f663d by ankit_aggarwal:
> [PackageLoading] Always create test modules
> 
> edit: Tests/PackageGraphTests/PackageGraphTests.swift
> edit: Sources/Commands/SwiftTestTool.swift
> edit: Tests/PackageLoadingTests/ConventionTests.swift
> edit: Sources/PackageLoading/PackageBuilder.swift
> edit: Sources/PackageGraph/PackageGraph.swift
> edit: Sources/Xcodeproj/pbxproj().swift
> edit: Tests/PackageLoadingTests/ManifestTests.swift
> edit: Sources/Build/BuildPlan.swift
> edit: Sources/PackageGraph/PackageGraphLoader.swift
> 
> Commit 2c4f597e72e4f5fcfb3307793312bca5cfc823ee by ankit_aggarwal:
> [PackageModel] Roll test module into the type enum
> 
> edit: Sources/Xcodeproj/Module+PBXProj.swift
> delete: Sources/Build/Buildable.swift
> edit: Tests/PackageLoadingTests/ConventionTests.swift
> edit: Sources/Xcodeproj/generate().swift
> edit: Sources/Xcodeproj/xcscheme().swift
> edit: Tests/PackageGraphTests/PackageGraphTests.swift
> edit: Sources/Commands/Describe.swift
> edit: Sources/PackageLoading/ModuleMapGenerator.swift
> edit: Tests/BuildTests/BuildPlanTests.swift
> edit: Sources/Build/BuildPlan.swift
> edit: Sources/PackageLoading/PackageBuilder.swift
> edit: Sources/PackageModel/Module.swift
> edit: Sources/PackageModel/ResolvedModels.swift
> edit: Tests/PackageLoadingTests/PkgConfigTests.swift
> edit: Sources/PackageGraph/PackageGraphLoader.swift
> edit: Sources/Build/llbuild.swift
> edit: Sources/PackageModel/Product.swift
> edit: Sources/Xcodeproj/pbxproj().swift

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

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-03 Thread Andrew Trick via swift-dev


> On Feb 3, 2017, at 10:58 AM, John McCall  wrote:
> 
>> On Feb 2, 2017, at 9:57 PM, Andrew Trick via swift-dev  
>> wrote:
>> ---
>> #1. (thunk export) The simplest, most flexible way to expose dispatch
>> across resilience boundaries is by exporting a single per-method entry
>> point. Future compilers could improve dispatch and gradually expose
>> more ABI details.
> 
> Probably the most important such case is that many of these "dispatch" symbols
> for a non-open class could simply be aliases to the actual method definition.
> 
> Note that open classes have to support super-dispatch, not just ordinary 
> dynamic
> dispatch; that's something that needs to be discussed at the same time, since 
> it
> may affect the trade-offs.  #1 has some serious disadvantages here; the others
> are likely fine, since their mechanisms are all easily parameterized by the 
> isa.
> 
>> ---
>> #3. (method index) This is an alternative that I've alluded to before,
>> but was not discussed in yesterday's meeting. One that makes a
>> tradeoff between exporting symbols vs. exposing vtable layout. I want
>> to focus on direct cost of the ABI support and flexibility of this
>> approach vs. approach #1 without arguing over how to micro-optimize
>> various dispatching schemes. Here's how it works:
>> 
>> The ABI specifies a sort function for public methods that gives each
>> one a per-class index. Version availability takes sort precedence, so
>> public methods can be added without affecting other
>> indices. [Apparently this is the same approach we're taking with
>> witness tables].
>> 
>> As with #2 this avoids locking down the vtable format for now--in the
>> future we'll likely optimize it further. To avoid locking all methods
>> into the vtable mechanism, the offset can be tagged. The alternative
>> dispatch mechanism for tagged offsets will be hidden within the
>> class-defining framework.
> 
> As a note, I went down a garden path here — I didn't realize at first that #3
> wasn't an option on its own, but really just forematter for options #3a and 
> #3b.
> The paragraph about the sort, especially coming after #2, made me think that
> you were talking about the option — let's call it #2b — where the class only
> exports an offset to the start of its v-table and an availability-sort allows 
> the
> caller to hard-code a fixed offset to add to that.  This greatly cuts down on 
> the
> number of symbols required to be exported, but of course it does force all
> the methods to actually end up in the v-table.

Right, I didn't go down that path initially because, as Joe pointed
out, the vtable offsets aren't statically knowable because of the
resilient base class problem. But, of course the vtable base offset
could be exported and we can rely on the class being realized before
it's invoked. This is great if we're willing to commit to vtable
dispatch.

>> This avoids the potential explosion of exported symbols--it's limited
>> to one per public class. It avoids explosion of metadata by allowing
>> alternative dispatch for some subset of methods. These tradeoffs can
>> be explored in the future, independent of the ABI.
>> 
>> ---
>> #3a. (offset table export) A single per-class entry point provides a
>> pointer to an offset table. [It can be optionally cached on the client
>> side].
> 
> Why would this need to be a function?  Just to allow its resolution to be 
> lazy?
> It seems to me that the class definition always knows the size of this table.

I don't know what you're asking. In #3b, the offset is resolved by a
class-exported function.

>> method_index = immediate
>> { // common per-class method lookup
>>   isa = load[obj]
>>   isa = isa & @isa_mask
>>   offset = load[@class_method_table + method_index]
>>   if (isVtableOffset(offset))
>> method_entry = load[isa + offset]
>>   else
>> method_entry = @resolveMethodAddress(isa, @class_method_table, 
>> method_index)
>> }
>> call method_entry
> 
> I hope the proposal is that the stuff in braces is a locally-emitted function,
> not something inlined into every call site.

This approach is based on generating local per-class "nocallersave" helper 
functions
for method lookup (all the stuff in curly braces).

> A sort of #4 is that this function could be exported by the class definition.
> It would be passed an isa and a method index and could resolve it however it 
> likes.

Yeah, let's call that option #4. I like that from an ABI perspective, but 
didn't go there
because it seem

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-03 Thread Andrew Trick via swift-dev


> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev  
> wrote:
> 
>>> #3b. (lazy resolution) Offset tables can be completely localized.
>>> 
>>> method_index = immediate
>>> { // common per-class method lookup
>>>  isa = load[obj]
>>>  offset = load[@local_class_method_table + method_index]
>>>  if (!isInitializedOffset(offset)) {
>>>offset = @resolveMethodOffset(@class_id, method_index)
>>>store [@local_class_method_table + method_index]
>>>  }
>>>  if (isVtableOffset(offset))
>>>method_entry = load[isa + offset]
>>>  else
>>>method_entry = @resolveMethodAddress(isa, @class_id, method_index)
>>> }
>>> call method_entry
>> 
>> The size of @local_class_method_table is not statically knowable.
>> Fortunately, it doesn't matter, because this mechanism does not actually
>> care about the table being contiguous; the lookup function could be
>> passed a per-method cache variable.  This would also allow the lookup
>> function to be shared between classes.

Hmm... I thought the local method offset table size could be statically 
knowable because it will only be accesd for methods that were publicly 
available at build time, based on the sorted method index.

We could simplify the method resolution API with a single exported symbol 
per-class (maybe that's what you're getting at):

method_entry = resolveMethodAddress_ForAClass(isa, method_index, &vtable_offset)

The problem with that is the client-side code can’t hoist and combine the 
method offset lookup anymore.

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

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-03 Thread Andrew Trick via swift-dev


> On Feb 3, 2017, at 1:27 PM, John McCall  wrote:
> 
>> On Feb 3, 2017, at 4:18 PM, Andrew Trick > <mailto:atr...@apple.com>> wrote:
>>> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>>>> #3b. (lazy resolution) Offset tables can be completely localized.
>>>>> 
>>>>> method_index = immediate
>>>>> { // common per-class method lookup
>>>>>  isa = load[obj]
>>>>>  offset = load[@local_class_method_table + method_index]
>>>>>  if (!isInitializedOffset(offset)) {
>>>>>offset = @resolveMethodOffset(@class_id, method_index)
>>>>>store [@local_class_method_table + method_index]
>>>>>  }
>>>>>  if (isVtableOffset(offset))
>>>>>method_entry = load[isa + offset]
>>>>>  else
>>>>>method_entry = @resolveMethodAddress(isa, @class_id, method_index)
>>>>> }
>>>>> call method_entry
>>>> 
>>>> The size of @local_class_method_table is not statically knowable.
>>>> Fortunately, it doesn't matter, because this mechanism does not actually
>>>> care about the table being contiguous; the lookup function could be
>>>> passed a per-method cache variable.  This would also allow the lookup
>>>> function to be shared between classes.
>> 
>> Hmm... I thought the local method offset table size could be statically 
>> knowable because it will only be accesd for methods that were publicly 
>> available at build time, based on the sorted method index.
> 
> Sure, I mean, you can pick a table size that's sufficient for all the offsets 
> that will be passed.  That would save a few instructions at call sites, at 
> the cost of requiring the resolvers to be per-class.
> 
>> We could simplify the method resolution API with a single exported symbol 
>> per-class (maybe that's what you're getting at):
>> 
>> method_entry = resolveMethodAddress_ForAClass(isa, method_index, 
>> &vtable_offset)
> 
> Right, this is what I was thinking.
> 
>> The problem with that is the client-side code can’t hoist and combine the 
>> method offset lookup anymore.
> 
> Why not?  vtable_offset is basically an opaque cache here.  Sure, technically 
> the call isn't readnone anymore, but it's an innocuous violation like adding 
> memoization to sin().
> 
> Or is there some finer-grained hoisting you're imagining than the entire call?
> 
> John.

I was briefly over-thinking the problem… we could hoist the part that wasn’t 
dependent on the `isa`. That’s probably not important, and if it were, we could 
still hoist the cache lookup.

This option does seem to have the lowest immediate ABI cost (one symbol per 
class) with a tremendous amount of flexibility for optimizing both the dispatch 
code and the metadata representation.

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

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-03 Thread Andrew Trick via swift-dev


> On Feb 3, 2017, at 3:12 PM, John McCall  wrote:
> 
> I think we can generalize this discussion a bit by describing some 
> mostly-independent axes of variation:

That's great (sorry I used up the arabic+letter naming convention earlier in 
the thread)...

> I. A call site:
>  I1) inlines the lookup
>  I2) calls a function that performs the lookup and returns a function pointer
>  I3) calls a function that performs the lookup and calls the function
> I3 minimizes code size at the call site, but it prevents the lookup (or 
> components thereof) from being hoisted.  I1 requires at least some details of 
> the lookup to be ABI.

Exactly.

> II. The function that performs the lookup:
> II1) is emitted lazily
> II2) is emitted eagerly
> II2 can use static information to implement the lookup inline without 
> affecting the ABI.  II1 cannot; it must either rely on ABI assumptions or 
> just recursively use another strategy, in which case the function is probably 
> just a call-site code-size optimization.

Sure, but I was thinking of it as client side vs. class-definition
side.  My suggestions explored the tradeoff between II1 and II2, where
the client code could optionally optimize for vtable dispatch by
emitting some lazy lookup helpers with a fall-back to the eagerly
emitted lookup.

> III. The function that performs the lookup:
>  III1) is method-specific
>  III2) is class-specific
>  III3) is part of the language runtime
> III1 requires a lot more functions, but if emitted with the class definition, 
> it allows the lookup to be statically specialized based on the method called, 
> so e.g. if a non-open method is never overridden, it can resolved to a 
> specific function pointer immediately, possibly by just aliasing a symbol to 
> the function definition.  III3 minimizes the number of functions required but 
> doesn't allow us to evolve dispatch beyond what's supported by the current 
> language runtime and doesn't allow class-specific optimizations (e.g. if the 
> class definition statically knows the offset to its v-table).

III1 is the sort of optimization that can be selectively added later
if we're willing to version the ABI.

I suppose by that logic we should start with III3. We could never
ditch the runtime/compiler support, but newer code could move toward
III2 through ABI versioning.

I actually prefer to start with III2 because the static overhead is
not significantly worse than III3 and it can be optimized without ABI
migration.

> IV. The function that performs the lookup:
>  IV1) is parameterized by an isa
>  IV2) is not parameterized by an isa
> IV1 allows the same function to be used for super-dispatch but requires extra 
> work to be inlined at the call site (possibly requiring a chain of resolution 
> function calls).

In my first message I was trying to accomplish IV1. But IV2 is simpler
and I can't see a fundamental advantage to IV1. Why would it need a
lookup chain?

> V. For any particular function or piece of information, it can be accessed:
>  V1) directly through a symbol
>  V2) through a class-specific table
>  V3) through a hierarchy-specific table (e.g. the class object)
> V1 requires more global symbols, especially if the symbol is per-method, but 
> doesn't have any index-computation problems, and it's generally a bit more 
> efficient.
> V2 allows stable assignment of fixed indexes to entries because of 
> availability-sorting.
> V3 does not; it requires some ability to (at least) slide indexes of entries 
> because of changes elsewhere in the hierarchy.
> If there are multiple instantiations of a table (perhaps with different 
> information, like a v-table), V2 and V3 can be subject to table bloat.

I had proposed V2 as an option, but am strongly leaning toward V1 for
ABI simplicity and lower static costs (why generate vtables and offset
tables?)

> So I think your alternatives were:
> 1. I3, II2, III1, IV2, V1 (for the dispatch function): a direct call to a 
> per-method global function that performs the dispatch.  We could apply V2 to 
> this to decrease the number of global symbols required, but at the cost of 
> inflating the call site and requiring a global variable whose address would 
> have to be resolved at load time.  Has an open question about super dispatch.
> 2. I1, V3 (for the v-table), V1 (for the global offset): a load of a 
> per-method global variable giving an offset into the v-table.  Joe's 
> suggestion adds a helper function as a code-size optimization that follows 
> I2, II1, III1, IV2.  Again, we could also use V2 for the global offset to 
> reduce the symbol-table costs.
> 3. I2, II2, III2, IV1, V2 (for the class offset / dispatch mechanism table).  
> At least I think this is right?  The difference between 3a and 3b seems to be 
> about initialization, but maybe also shifts a lot of code-generation to the 
> call site?

I'll pick the following option as a starting point because it constrains the 
ABI the least in
terms of static costs and potential

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-04 Thread Andrew Trick via swift-dev


> On Feb 3, 2017, at 9:37 PM, John McCall  wrote:
> 
>>> IV. The function that performs the lookup:
>>>  IV1) is parameterized by an isa
>>>  IV2) is not parameterized by an isa
>>> IV1 allows the same function to be used for super-dispatch but requires 
>>> extra work to be inlined at the call site (possibly requiring a chain of 
>>> resolution function calls).
>> 
>> In my first message I was trying to accomplish IV1. But IV2 is simpler
>> and I can't see a fundamental advantage to IV1.
> 
> Well, you can use IV1 to implement super dispatch (+ sibling dispatch, if we 
> add it)
> by passing in the isa of either the superclass or the current class.  IV2 
> means
> that the dispatch function is always based on the isa from the object, so 
> those
> dispatch schemes need something else to implement them.
> 
>> Why would it need a lookup chain?
> 
> Code size, because you might not want to inline the isa load at every call 
> site.
> So, for a normal dispatch, you'd have an IV2 function (defined client-side?)
> that just loads the isa and calls the IV1 function (defined by the class).

Right. Looks like I wrote the opposite of what I meant. The important thing to 
me is that the vtable offset load + check is issued in parallel with the isa 
load. I was originally pushing IV2 for this reason, but now think that 
optimization could be entirely lazy via a client-side cache.

>>> V. For any particular function or piece of information, it can be accessed:
>>>  V1) directly through a symbol
>>>  V2) through a class-specific table
>>>  V3) through a hierarchy-specific table (e.g. the class object)
>>> V1 requires more global symbols, especially if the symbol is per-method, 
>>> but doesn't have any index-computation problems, and it's generally a bit 
>>> more efficient.
>>> V2 allows stable assignment of fixed indexes to entries because of 
>>> availability-sorting.
>>> V3 does not; it requires some ability to (at least) slide indexes of 
>>> entries because of changes elsewhere in the hierarchy.
>>> If there are multiple instantiations of a table (perhaps with different 
>>> information, like a v-table), V2 and V3 can be subject to table bloat.
>> 
>> I had proposed V2 as an option, but am strongly leaning toward V1 for
>> ABI simplicity and lower static costs (why generate vtables and offset
>> tables?)
> 
> V1 doesn't remove the need for tables, it just hides them from the ABI.

I like that it makes the offset tables lazy and optional. They don’t even need 
to be complete.

>>> So I think your alternatives were:
>>> 1. I3, II2, III1, IV2, V1 (for the dispatch function): a direct call to a 
>>> per-method global function that performs the dispatch.  We could apply V2 
>>> to this to decrease the number of global symbols required, but at the cost 
>>> of inflating the call site and requiring a global variable whose address 
>>> would have to be resolved at load time.  Has an open question about super 
>>> dispatch.
>>> 2. I1, V3 (for the v-table), V1 (for the global offset): a load of a 
>>> per-method global variable giving an offset into the v-table.  Joe's 
>>> suggestion adds a helper function as a code-size optimization that follows 
>>> I2, II1, III1, IV2.  Again, we could also use V2 for the global offset to 
>>> reduce the symbol-table costs.
>>> 3. I2, II2, III2, IV1, V2 (for the class offset / dispatch mechanism 
>>> table).  At least I think this is right?  The difference between 3a and 3b 
>>> seems to be about initialization, but maybe also shifts a lot of 
>>> code-generation to the call site?
>> 
>> I'll pick the following option as a starting point because it constrains the 
>> ABI the least in
>> terms of static costs and potential directions for optimization:
>> 
>> "I2; (II1+II2); III2; IV1; V1"
>> 
>> method_entry = resolveMethodAddress_ForAClass(isa, method_index, 
>> &vtable_offset)
>> 
>> (where both modules would need to opt into the vtable_offset.)
> 
> Wait, remind me what this &vtable_offset is for at this point?  Is it 
> basically just a client-side cache?  I can't figure out what it's doing for 
> us.

It’s a client side cache that can be checked in parallel with the `isa` load. 
The resolver is not required to provide an offset, and the client does not need 
cache all the method offsets. It does burn an extra register, but gains the 
ability to implement vtable dispatch entirely on the client side.

You might be thinking of caching the method entry itself and checking `isa` 
within `resolveMethod`. I didn’t mention that possibility because the cost of 
calling the non-local `resolveMethod` function followed by an indirect call 
largely defeats the purpose of something like an inline-cache.

>> I think any alternative would need to be demonstrably better in terms of 
>> code size or dynamic dispatch cost.
> 
> That's a lot of stuff to materialize at every call site.  It makes calls
> into something like a 10 instruction sequence on ARM64, ignoring
> the actual formal arguments:
> 
>

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-06 Thread Andrew Trick via swift-dev


> On Feb 6, 2017, at 9:02 AM, Greg Parker  wrote:
> 
>> 
>> On Feb 4, 2017, at 2:35 AM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> 
>>> On Feb 3, 2017, at 9:37 PM, John McCall >> <mailto:rjmcc...@apple.com>> wrote:
>>> 
>>>>> IV. The function that performs the lookup:
>>>>>  IV1) is parameterized by an isa
>>>>>  IV2) is not parameterized by an isa
>>>>> IV1 allows the same function to be used for super-dispatch but requires 
>>>>> extra work to be inlined at the call site (possibly requiring a chain of 
>>>>> resolution function calls).
>>>> 
>>>> In my first message I was trying to accomplish IV1. But IV2 is simpler
>>>> and I can't see a fundamental advantage to IV1.
>>> 
>>> Well, you can use IV1 to implement super dispatch (+ sibling dispatch, if 
>>> we add it)
>>> by passing in the isa of either the superclass or the current class.  IV2 
>>> means
>>> that the dispatch function is always based on the isa from the object, so 
>>> those
>>> dispatch schemes need something else to implement them.
>>> 
>>>> Why would it need a lookup chain?
>>> 
>>> Code size, because you might not want to inline the isa load at every call 
>>> site.
>>> So, for a normal dispatch, you'd have an IV2 function (defined client-side?)
>>> that just loads the isa and calls the IV1 function (defined by the class).
>> 
>> Right. Looks like I wrote the opposite of what I meant. The important thing 
>> to me is that the vtable offset load + check is issued in parallel with the 
>> isa load. I was originally pushing IV2 for this reason, but now think that 
>> optimization could be entirely lazy via a client-side cache.
> 
> Is this client-side cache per-image or per-callsite? 

Per-image, with up to one cache entry per imported method to hold the vtable 
offset.
-Andy

>>> So we'd almost certainly want a client-side resolver function that handled
>>> the normal case.  Is that what you mean when you say II1+II2?  So the local
>>> resolver would be I2; II1; III2; IV2; V1, which leaves us with a 
>>> three-instruction
>>> call sequence, which I think is equivalent to Objective-C, and that function
>>> would do this sequence:
>>> 
>>> define @local_resolveMethodAddress(%object, %method_index)
>>>   %raw_isa = load %object// 1 instruction
>>>   %isa_mask = load @swift_isaMask// 3: 2 to materialize 
>>> address from GOT (not necessarily with ±1MB), 1 to load from it
>>>   %isa = and %raw_isa, %isa_mask // 1
>>>   %cache_table = @local.A.cache_table// 2: not necessarily 
>>> within ±1MB
>>>   %cache = add %cache_table, %method_index * 8   // 1
>>>   tailcall @A.resolveMethod(%isa, %method_index, %cache)  // 1
>>> 
>>> John.
>> 
>> Yes, exactly, except we haven’t even done any client-side vtable 
>> optimization yet.
>> 
>> To me the point of the local cache is to avoid calling @A.resolveMethod in 
>> the common case. So we need another load-compare-and-branch, which makes the 
>> local helper 12-13 instructions. Then you have the vtable load itself, so 
>> that’s 13-14 instructions. You would be saving on dynamic instructions but 
>> paying with 4 extra static instructions per class.
>> 
>> It would be lame if we can't force @local.A.cache_table to be ±1MB relative 
>> to the helper.
> 
> You should assume that code and data are far apart from each other. The 
> linker will optimize two-instruction far loads to a nop and a near load if 
> they are in fact close together, but in full-size apps that is uncommon and 
> in the dyld shared cache it never happens. (The shared cache deliberately 
> separates all code from all data in order to save VM map entries.)
> 
> 
> -- 
> Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime 
> Wrangler

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

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-06 Thread Andrew Trick via swift-dev


> On Feb 3, 2017, at 4:12 PM, Joe Groff  wrote:
> 
> Given that most open-coded resilient method lookup paths require an extra 
> load dependency to grab the method offset before loading the method address 
> itself, we might possibly consider indirecting the vtables for each class, so 
> that the top-level vtable contains [address of root class vtable, address of 
> first child class vtable, etc.]. If a class hierarchy is fixed once exported 
> (in other words, you can't insert a superclass into an inheritance chain 
> without an ABI break), then the offset into each superclass's pointer in the 
> vtable would be statically known, and the offset into each second-level 
> vtable could be statically known via sorting by availability. This somewhat 
> matches how we lay out protocol witness tables, where each parent protocol's 
> witness table is indirectly referenced instead of being inlined into the leaf 
> witness table. (OTOH, method offsets can be cached and reused to dispatch the 
> same method on different objects, whereas we would have to perform the load 
> chain once per object per method with this approach.)
> 
> -Joe

I want to avoid introducing dependent loads for both the resilient and 
non-resilient cases. obj->isa->target is already the critical path. We don’t 
want obj->isa->vtable->target. I’d rather go through thunks and do the lookup 
on the framework side.

The interesting question for me is whether to reserve any bits in the cached 
offset for future alternative dispatch mechanisms or table layouts. I doubt 
it’s worth the extra bitmask instruction that would be needed for cache lookup.

-Andy

>> On Feb 2, 2017, at 6:57 PM, Andrew Trick  wrote:
>> 
>> I'm following up on a resilient dynamic dispatch discussion kicked off by
>> Slava during a performance team meeting to summarize some key
>> points on public [swift-dev].
>> 
>> It's easy to get sidetracked by the details of dynamic
>> dispatch and various ways to generate code. I suggest approaching the
>> problem by focusing on the ABI aspects and flexibility the ABI affords
>> for future optimization. I'm including a proposal for one specific
>> approach (#3) that wasn't discussed yet.
>> 
>> ---
>> #1. (thunk export) The simplest, most flexible way to expose dispatch
>> across resilience boundaries is by exporting a single per-method entry
>> point. Future compilers could improve dispatch and gradually expose
>> more ABI details.
>> 
>> Cost: We're forced to export all those symbols in perpetuity.
>> 
>> [The cost of the symbols is questionable. The symbol trie should compress the
>> names, so the size may be small, and they should be lazily resolved,
>> so the startup cost should be amortized].
>> 
>> ---
>> #2. (offset export) An alternative approach was proposed by JoeG a
>> while ago and revisited in the meeting yesterday. It involves a
>> client-side vtable offset lookup helper.
>> 
>> This allows more opportunity for micro-optimization on the client
>> side. This exposes the isa-based vtable mechanism as ABI. However, it
>> stops short of exposing the vtable layout itself. Guaranteeing vtable
>> dispatch may become a problem in the future because it forces an
>> explosion of metadata. It also has the same problem as #1 because the
>> framework must export a per-method symbol for the dispatch
>> offset. What's worse, the symbols need to be eagerly resolved (AFAIK).
>> 
>> ---
>> #3. (method index) This is an alternative that I've alluded to before,
>> but was not discussed in yesterday's meeting. One that makes a
>> tradeoff between exporting symbols vs. exposing vtable layout. I want
>> to focus on direct cost of the ABI support and flexibility of this
>> approach vs. approach #1 without arguing over how to micro-optimize
>> various dispatching schemes. Here's how it works:
>> 
>> The ABI specifies a sort function for public methods that gives each
>> one a per-class index. Version availability takes sort precedence, so
>> public methods can be added without affecting other
>> indices. [Apparently this is the same approach we're taking with
>> witness tables].
>> 
>> As with #2 this avoids locking down the vtable format for now--in the
>> future we'll likely optimize it further. To avoid locking all methods
>> into the vtable mechanism, the offset can be tagged. The alternative
>> dispatch mechanism for tagged offsets will be hidden within the
>> class-defining framework.
>> 
>> This avoids the potential explosion of exported symbols--it's limited
>> to one per public class. It avoids explosion of metadata by allowing
>> alternative dispatch for some subset of methods. These tradeoffs can
>> be explored in the future, independent of the ABI.
>> 
>> ---
>> #3a. (offset table export) A single per-class entry point provides a
>> pointer to an offset table. [It can be optionally cached on the client
>> side].
>> 
>> method_index = immediate
>> { // common per-class method lookup
>>   isa = load[obj]
>>   isa = isa & @isa_mask
>>

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

2017-02-06 Thread Andrew Trick via swift-dev


> On Feb 5, 2017, at 7:45 AM, Karl Wagner  wrote:
> 
> I have a question about current dispatching behaviour with protocols and 
> ‘Self’.
> 
> protocol CustomEquatable {
> func equal(to: Self) -> Bool
> }
> 
> open class Super : CustomEquatable {
> func equal(to: Super) -> Bool { print("super"); return false }
> }
> class Sub: Super {
> func equal(to: Sub) -> Bool { print("sub-sub"); return true }
> override func equal(to: Super) -> Bool { print("sub-super"); return true }
> }
> 
> Sub().equal(to: Sub()) // sub-sub
> Sub().equal(to: Super())   // sub-super 
> Super().equal(to: Sub())   // super
> Super().equal(to: Super()) // super
> 
> (Sub() as Super).equal(to: Sub)  // sub-super — dynamically 
> dispatched to callee’s type, not param
> (Sub() as Super).equal(to: (Sub() as Super)) // sub-super — as above
> 
> 
> Currently, we dynamically dispatch to the callee’s type to find ‘Self’, but 
> we don’t apply that consistently when dispatching to ‘Self’-type parameters. 
> Is that expected behaviour?
> 
> - Karl

Hi Karl,

This is expected behavior. The choice of method overload is based on the static 
types: `Super.equal(to: Super)`. The dynamic dispatch that you get when using 
the override keyword is based on the `self` argument’s dynamic type only. The 
dynamic types of the non-self arguments don’t play a part.

I’m sure there are some good language design reasons not to support dynamic 
method overloads. I can only tell you that implementing it would be no fun.

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

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

2017-02-07 Thread Andrew Trick via swift-dev


> On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
> 
>> On Feb 6, 2017, at 11:44 AM, Jordan Rose > > wrote:
>> 
>> 
>>> On Feb 6, 2017, at 11:25, Joe Groff via swift-dev >> > wrote:
>>> 
>>> 
 On Feb 6, 2017, at 11:22 AM, Michael Gottesman >>> > wrote:
 
 Here is my suggestion:
 
 1. We assume by default the leaking case.
 2. We change noreturn functions from C to maybe have a special semantic 
 tag on them that says that cleanups should occur before them (i.e. 
 UIApplicationMain).
>> 
>> I'm not sure what you mean by this. Functions from C exist in both groups, 
>> and I don't see why one assumption is better than the other.
>> 
>> 
>>> 
>>> I feel that "clean up before" is the safer ground case, and if we do any 
>>> work to whitelist a group, it should be for the common "leakable" 
>>> noreturns, like exit/_exit/abort/fatalError. That way, we momentarily burn 
>>> some pointless cycles in the case we get it "wrong" rather than permanently 
>>> leak memory.
>> 
>> I don't like this because of the reverse issue: under -Onone, you may want 
>> to pop back up the stack in the debugger and see what values you had, and 
>> they won't be available. It's almost always possible to get things released 
>> sooner; usually more awkward to get them to stay alive.
> 
> On the other hand, this is safe to do in the short term. We can special case 
> asserts. One thing to consider though is if this should be provided to users. 
> If not, we can just use semantics. Otherwise, we would need to discuss how to 
> surface this at the language level.
> 
> Michael

Sorry I didn't jump in yesterday. I'm afraid I don't follow most of the 
reasoning expressed in the thread. I do completely understand Jordan's points.

'noreturn' functions are called from may-return functions. Guaranteeing cleanup 
would result in inconsistent behavior as a result of optimization.

The optimizer can always shorten lifetimes when it determines that the caller 
can't access the object. But I don't see what that has to do with 'noreturn'.

I agree that we *could* add a special "cleanup before" semantic tag for some C 
functions, but I'm not aware of a need to do that and there are definite 
drawbacks.

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

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

2017-02-26 Thread Andrew Trick via swift-dev

Building CoreAudio on armv7k:

(dependent_member_type assoc_type=Swift.(file).Strideable.Stride
  (base=generic_type_param_type depth=0 index=0 decl=Swift.(file).func decl.T))
deserialization produced an invalid type (rdar://problem/30382791)
 <>UNREACHABLE executed at 
/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swift/lib/Serialization/Deserialization.cpp:4246!

Looks like there’s already a radar for this. Slava, I don’t know if this is 
just sporadic or if you've exposed something.

-Andy

> On Feb 26, 2017, at 10:50 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#8580]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/8580/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Sun, 26 Feb 2017 22:43:33 -0800
> Build duration:   6 min 52 sec
> Identified problems:
> 
> Assertion failure: This build failed because of an assertion failure. Below 
> is a list of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit 38d44c216405817bd8f42b474b7aa968eb12f364 by atrick:
> AddressLowering: rewrite the call-site lowering logic.
> 
> edit: test/SILOptimizer/address_lowering.sil
> edit: include/swift/SIL/SILBuilder.h
> edit: include/swift/SIL/SILFunctionConventions.h
> edit: lib/SILOptimizer/Mandatory/AddressLowering.cpp
> 
> Commit 754c7feb2669bf93ec80a9d30ed4c38b9c279a55 by spestov:
> IRGen: Use SubstitutionMap in one spot
> 
> edit: lib/IRGen/IRGenSIL.cpp
> 
> Commit 0af2845c6ddfb2e3e2afa5569cec278dd4bdf9e6 by spestov:
> SILGen: Emission of materializeForSet for generic subscripts
> 
> edit: lib/SILGen/SILGenLValue.cpp
> edit: test/SILGen/lifetime.swift
> edit: test/SILGen/accessors.swift
> edit: lib/SIL/SILVerifier.cpp
> edit: test/SILGen/materializeForSet.swift
> edit: test/SILGen/constrained_extensions.swift
> edit: test/SILGen/addressors.swift
> edit: test/SILGen/properties.swift
> edit: test/SILOptimizer/devirt_materializeForSet.swift
> edit: lib/SIL/TypeLowering.cpp
> edit: lib/SILGen/SILGenMaterializeForSet.cpp
> edit: include/swift/SIL/TypeLowering.h
> 
> Commit 8b0094fe42d1081c3cc43a952f788a1d345d64ec by spestov:
> Add executable test for generic subscripts
> 
> add: test/Interpreter/generic_subscript.swift
> 
> Commit fa8f2ce503f114987e80f81846b0bc2f5286f28d by spestov:
> Add CHANGELOG.md entries for SE-0110 and SE-0148
> 
> edit: CHANGELOG.md

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

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

2017-04-06 Thread Andrew Trick via swift-dev

Something must have changed between the test and the merge. I’m just waiting on 
the PR revert’s smoke test.
-Andy

> On Apr 6, 2017, at 10:34 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#9249]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9249/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Thu, 06 Apr 2017 10:09:39 -0700
> Build duration:   25 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 1 test(s), Passed: 9144 test(s), Total: 9145 test(s)
> Failed: Swift(macosx-x86_64).stdlib.Data.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
> 
> Changes
> 
> Commit 1702b831e47db6dd5eede08f0b2c5fa193a4dbc7 by Erik Eckstein:
> StackNesting: fix use-after-free problem.
> 
> edit: lib/SILOptimizer/Utils/StackNesting.cpp
> 
> Commit 1d32586d2886ad8b35a37253a81c80837fbab95e by Andrew Trick:
> SE-0138: Proposed amendment to SE-0138: Normalize UnsafeRawBufferPointer
> 
> edit: validation-test/stdlib/Slice.swift.gyb
> edit: validation-test/stdlib/UnsafeBufferPointer.swift.gyb
> edit: stdlib/private/StdlibCollectionUnittest/CheckCollectionType.swift.gyb
> edit: validation-test/stdlib/Collection/LazyFilterCollection.swift.gyb
> edit: validation-test/stdlib/CollectionType.swift.gyb
> edit: test/stdlib/Inputs/CommonArrayTests.gyb
> edit: validation-test/stdlib/Data.swift
> edit: test/stdlib/UnsafeRawBufferPointer.swift
> edit: CHANGELOG.md
> edit: 
> stdlib/private/StdlibCollectionUnittest/CheckCollectionInstance.swift.gyb
> edit: validation-test/stdlib/Lazy.swift.gyb
> edit: validation-test/stdlib/Unicode.swift.gyb
> edit: validation-test/stdlib/UnicodeTrie.swift.gyb
> edit: stdlib/public/core/UnsafeBufferPointer.swift.gyb
> edit: stdlib/public/core/UnsafeRawBufferPointer.swift.gyb
> edit: test/Parse/pointer_conversion.swift.gyb

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

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

2017-04-10 Thread Andrew Trick via swift-dev

I probably messed up an instruction iterator… fixing.

-Andy

> On Apr 10, 2017, at 1:13 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-ASAN-RA-osx [#398]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/398/ 
> 
> Project:  oss-swift-incremental-ASAN-RA-osx
> Date of build:Mon, 10 Apr 2017 10:26:21 -0700
> Build duration:   2 hr 47 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 2 test(s), Passed: 9154 test(s), Total: 9156 test(s)
> Failed: Swift(macosx-x86_64).SILOptimizer.access_marker_elim.sil 
> 
> Failed: Swift(macosx-x86_64).SILOptimizer.access_marker_mandatory.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
> 
> Changes
> 
> Commit 41b388d9545d30f7d0006b1ab3dbdc58cc265b68 by Andrew Trick:
> Verify support for -enforce-exclusivity=checked.
> 
> edit: lib/SIL/SILVerifier.cpp
> add: test/SILGen/access_marker_gen.swift
> 
> Commit 44110e361d6f21aae57f9bb200f3398428c90d2d by Andrew Trick:
> Add a HasAccessMarkers flag to SILFunction.
> 
> edit: lib/SIL/SILVerifier.cpp
> edit: lib/SIL/SILFunction.cpp
> edit: include/swift/SIL/SILFunction.h
> 
> Commit ecfff065c2f40ae62f3df98658430b8b8fed8af1 by Andrew Trick:
> Add -enforce-exclusivity option to sil-opt.
> 
> edit: tools/sil-opt/SILOpt.cpp
> edit: test/SILOptimizer/exclusivity_static_diagnostics.sil
> 
> Commit 4355cad83ef629280d8d2efe6c9f469422f0de1f by Andrew Trick:
> Add a pass to eliminate access markers.
> 
> add: lib/SILOptimizer/Mandatory/AccessMarkerElimination.cpp
> edit: lib/SILOptimizer/PassManager/PassPipeline.cpp
> edit: include/swift/SIL/SILFunction.h
> edit: lib/SILOptimizer/Mandatory/CMakeLists.txt
> edit: include/swift/SILOptimizer/PassManager/Passes.def
> 
> Commit ba23be56f9add7e3883abf2adc59ce1bcde7d4f9 by Andrew Trick:
> Test access markers during mandatory passes.
> 
> add: test/SILOptimizer/access_marker_mandatory.swift
> add: test/SILOptimizer/access_marker_elim.sil
> 
> Commit a7dd0f7921e6aa3ba6179fbdd8c315978a493387 by Ankit Aggarwal:
> [Gradening] Remove useless characters
> 
> edit: Sources/PackageLoading/PackageBuilder.swift
> 
> Commit 9907200c6f82d26b678ebab4b147e860a6fd666d by Ankit Aggarwal:
> [PackageLoading] Clarify PackageBuilder's description
> 
> edit: Sources/PackageLoading/PackageBuilder.swift
> 
> Commit d5083501f0d4ac0f53cb9750ed719d375510e024 by Ankit Aggarwal:
> [PackageModel] Move ModuleType enum inside Module
> 
> edit: Sources/Commands/Describe.swift
> edit: Sources/PackageModel/ResolvedModels.swift
> edit: Tests/PackageLoadingTests/PackageBuilderTests.swift
> edit: Sources/PackageModel/Module.swift

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

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

2017-04-14 Thread Andrew Trick via swift-dev

> runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED

This is unrelated to my commit and recovered on the next build. Is it spurious? 
Can CI be taught to recognize known spurious asserts?

-Andy


> On Apr 14, 2017, at 7:51 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#2126]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/2126/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04-long-test
> Date of build:Fri, 14 Apr 2017 19:18:26 -0700
> Build duration:   33 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit 915b3198107fb1f0c200e433227dcca7c9943343 by Andrew Trick:
> [AccessEnforce] must handle `undef` before diagnostics.
> 
> edit: lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp
> edit: test/SILOptimizer/access_enforcement_selection.swift

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

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

2017-04-14 Thread Andrew Trick via swift-dev

> runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED

This is the same failure again, which seems sensitive to me checking anything 
at all in.

-Andy

> On Apr 14, 2017, at 10:10 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#2129]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/2129/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04-long-test
> Date of build:Fri, 14 Apr 2017 21:38:18 -0700
> Build duration:   32 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit 095083e0e88b7e46d776c2bcbfda88bcfb5ebe46 by Andrew Trick:
> CopyForwarding: new optimization to remove copies into dead temporaries.
> 
> edit: test/SILOptimizer/copyforward.sil
> edit: lib/SILOptimizer/Transforms/CopyForwarding.cpp

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

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

2017-04-17 Thread Andrew Trick via swift-dev

Backtrace:
#1 0x0398c9f6 SignalHandler(int) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x398c9f6)
#2 0x7f5e37c6f670 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11670)
#3 0x0392f35e getOpenFileImpl(int, llvm::Twine const&, unsigned long, 
unsigned long, long, bool, bool) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x392f35e)
#4 0x0392ed85 llvm::MemoryBuffer::getFileOrSTDIN(llvm::Twine const&, 
long, bool) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x392ed85)
#5 0x029db34a llvm::object::createBinary(llvm::StringRef) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x29db34a)
#6 0x005845c9 swift::performLLVM(swift::IRGenOptions&, 
swift::DiagnosticEngine*, 

> On Apr 16, 2017, at 11:42 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3056]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/3056/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Sun, 16 Apr 2017 23:28:31 -0700
> Build duration:   13 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 2 test(s), Passed: 9194 test(s), Total: 9196 test(s)
> Failed: Swift(linux-x86_64).AutolinkExtract.import.swift 
> 
> Failed: Swift(linux-x86_64).TBD.global.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 416 test(s), Total: 416 test(s)
> 
> Changes
> 
> Commit 3fe16ac03c45601d2cbc03bcecad2e156f3c44e8 by Andrew Trick:
> [Exclusivity] Fix AccessEnforcementSelection to handle unreachable
> 
> edit: lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp
> add: test/SILOptimizer/access_marker_selection.sil

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

Re: [swift-dev] Renaming SILSuccessor -> SILCFGEdge

2017-04-27 Thread Andrew Trick via swift-dev


> On Apr 26, 2017, at 1:24 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
> Hey everyone.
> 
> I am currently doing some small fixes to SILSuccessor (adding some comments 
> and fixing some issues exposed by LLVM upstream). As I read the code it 
> became pretty apparent that the name is a misnomer... SILSuccessor is not 
> just representing a successor, rather it is representing a whole CFG edge. 
> This can be seen in how SILSuccessor is used to iterate over the predecessors 
> of the block.
> 
> With that in mind, I would like to rename SILSuccessor to SILCFGEdge. It will 
> make it much clearer without knowing any context what this data structure is 
> used for.
> 
> Any objections, disagreements, flames, etc?
> Michael

Please call this SILBasicBlockEdge. CFG isn’t used anywhere in SIL type 
names.The guiding principle is to minimize the variation names used for the 
same entity.

-Andy

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

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

2017-04-28 Thread Andrew Trick via swift-dev

TestFoundation/TestFoundation: undefined symbol: 
_T0s10DictionaryV4keyss17LazyMapCollectionVyAByxq_GxGfg

-Andy

> On Apr 28, 2017, at 9:51 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3350]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/3350/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Fri, 28 Apr 2017 21:34:30 -0700
> Build duration:   17 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9309 test(s), Total: 9309 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 417 test(s), Total: 417 test(s)
> 
> Changes
> 
> Commit f469fb73db40f7ba5e2a4953f9ba768e825998b7 by Andrew Trick:
> [Exclusivity] Allow AccessEnforcementSelection to run before DI.
> 
> edit: lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp
> 
> Commit 8187aae1b87369c4ce0cbb8a021365bc6f07eef9 by Andrew Trick:
> [Exclusivity] Handle copy_addr+destroy_addr folding with end_access
> 
> edit: test/SILOptimizer/allocbox_to_stack_ownership.sil
> edit: lib/SIL/SILBuilder.cpp
> 
> Commit 2336a8786651897c22ae56852a83f45c3e7efbfd by Andrew Trick:
> [Exclusivity] Enable access markers for the entire -Onone pipeline.
> 
> edit: lib/Frontend/CompilerInvocation.cpp
> edit: test/SILOptimizer/access_marker_elim.sil
> edit: lib/SILOptimizer/Mandatory/AccessMarkerElimination.cpp
> edit: lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp
> edit: lib/SILOptimizer/PassManager/PassPipeline.cpp
> edit: include/swift/AST/DiagnosticsFrontend.def
> edit: test/SILOptimizer/access_enforcement_selection.swift
> edit: test/SILOptimizer/access_marker_mandatory.swift
> edit: lib/SILOptimizer/Transforms/AllocBoxToStack.cpp
> 
> Commit 45967ceb4f37294c24dfbc35e1980e3604706243 by Andrew Trick:
> [Exclusivity] Update tests for access markers.
> 
> edit: test/SILGen/addressors.swift
> edit: test/SILOptimizer/access_marker_mandatory.swift
> edit: test/SILOptimizer/definite_init_failable_initializers.swift
> edit: test/SILGen/unmanaged.swift
> edit: test/Interpreter/enforce_exclusive_access.swift
> 
> Commit 8ecc3e31cf73c67ba1bc3edbdc50025f1069451f by Andrew Trick:
> [Exclusivity] access enforcement SIL tests.
> 
> add: test/SILOptimizer/access_enforcement_selection.sil

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

Re: [swift-dev] Dependencies on Benchmark_O(& co.) --verbose format

2017-05-15 Thread Andrew Trick via swift-dev

Hi Pavol,

The compare_perf_tests.py script parses that output. I don’t actually use the 
driver. I might start using the driver once it has a —rerun option, but the 
compare script should still work directly on the benchmark output.

-Andy

> On May 15, 2017, at 2:42 AM, Pavol Vaskovic via swift-dev 
>  wrote:
> 
> Hello,
> 
> I’m working of fixes to SR-4780 "Can not run performance tests that are not 
> in precommit suite”  and SR-4669 "Add 
> a Benchmark_Driver --rerun N option” .
> 
> It would make my work easier if I could slightly modify the output format 
> from the Benchmark_O(& co.) in the verbose mode, but before I do that I’d 
> like to know if anybody has dependency on the exact format — any scripts that 
> parse it?
> 
> Manual use shouldn’t be affected, the provided information would remain the 
> same.
> 
> —Pavol
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

1 2 >

1 - 100 of 133 matches

Mail list logo