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

[mishal_shah via swift-dev]

Hi Mehdi, 

Can you please look at this failure? 

/llvm/lib/Target/PowerPC/PPCMCInstLower.cpp:40:22: error: no member named 
'Mang' in 'llvm::AsmPrinter'
  Mangler *Mang = AP.Mang;
  ~~ ^
1 error generated.


Thanks,
Mishal Shah
> On Dec 5, 2016, at 11:30 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#906]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/906/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Mon, 05 Dec 2016 23:12:50 -0800
> Build duration:   17 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit 7a841c779fb64f42a090ea40d24822277ee2b810 by mehdi.amini:
> Remove unused function getMang().
> 
> edit: lib/Target/X86/X86MCInstLower.cpp
> 
> Commit 8881b0ac145a61053b7bd6b4c4a7df3b6080155c by mehdi.amini:
> Actually remove the Mangler from the AsmPrinter and clean up the places
> 
> edit: include/llvm/CodeGen/AsmPrinter.h
> edit: lib/Target/NVPTX/NVPTXAsmPrinter.cpp
> edit: lib/Target/XCore/XCoreMCInstLower.cpp
> edit: lib/Target/XCore/XCoreMCInstLower.h
> edit: lib/Target/XCore/XCoreAsmPrinter.cpp
> edit: lib/Target/Lanai/LanaiAsmPrinter.cpp
> edit: lib/Target/Lanai/LanaiMCInstLower.cpp
> edit: lib/Target/Lanai/LanaiMCInstLower.h
> 
> Commit a7fc86787be6d0aa40a3f90673d6f1b1a2363c61 by mehdi.amini:
> Attempt to fix a ThinLTO crash when incrementally linking WebKit
> 
> edit: lib/LTO/ThinLTOCodeGenerator.cpp

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

[swift-dev] Proposal: SILValue SSA Instructions

[Michael Gottesman via swift-dev]

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.


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

Re: [swift-dev] -whole-module-optimization with -Onone

[Ben Asher via swift-dev]

I've also come up with a small repro case that shows the duplicated
bridging header work: https://bugs.swift.org/browse/SR-3338.

Thanks!

Ben

On Fri, Dec 2, 2016 at 3:28 PM, Ben Asher  wrote:

> Filed the issues I ran into with repro cases here:
>
> https://bugs.swift.org/browse/SR-3319
> https://bugs.swift.org/browse/SR-3321
>
> SR-3321 covers the SIL verification failure. The assertion failure was in
> the same file as the one that repro'd the SIL verification failure, but I'm
> not seeing it anymore. If/when SR-3321 gets fixed, I'll follow up again and
> see if it shows up.
>
> Thanks!
>
> Ben
>
> On Thu, Dec 1, 2016 at 7:10 PM, Ben Asher  wrote:
>
>> Sure thing! I’ll see if I can put small reproducers together tomorrow.
>>
>> Ben
>>
>> On Thu, Dec 1, 2016 at 7:08 PM, Mark Lacey  wrote:
>>
>>>
>>> On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev 
>>> wrote:
>>>
>>> The build failed compiling 3 files in our project. Our app is crashing
>>> that snapshot; here is some output from the failures:
>>>
>>>
>>> It would be awesome if you could come up with small reproducers for
>>> these and open bugs for them. Alternately, opening a radar with the full
>>> project attached will give us an opportunity to get these fixed ASAP!
>>>
>>> Mark
>>>
>>>
>>> - Assertion failed: (newType == type || (isa(newType) &&
>>> cast(newType)->getNumElements() == 1 &&
>>> cast(newType).getElementType(0) == type)), function
>>> rewriteType, file /Users/buildn
>>> ode/jenkins/workspace/oss-swift-package-osx/swift/lib/SILGen/RValue.h,
>>> line 207.
>>>
>>> - SIL verification failed: method's Self parameter should be constrained
>>> by protocol: selfRequirement.getKind() == RequirementKind::Conformance &&
>>> selfRequirement.getFirstType()->isEqual(selfGenericParam) && selfR
>>> equirement.getSecondType()->getAs() ->getDecl() ==
>>> protocol
>>>
>>> We're not getting all the way to linking, but compiling everything for
>>> that snapshot took ~11min45s. Based on that, it appears that about a minute
>>> is saved with the new fixes since the Swift 3.0 that shipped with Xcode 8.1
>>> (App Store).
>>>
>>> With Xcode 8.2 Beta 2, the app builds fine, and it takes about 12m15s.
>>> If Xcode 8.2 Beta 2 also has those fixes that we expect to speed up the
>>> build, the extra time here (compared to the snapshot) could be explained by
>>> linking, signing, and a few other custom builds scripts that run after
>>> compiling.
>>>
>>> Thanks everyone for your help!
>>>
>>> Ben
>>>
>>>
>>> On Thu, Dec 1, 2016 at 4:16 PM, Ben Asher  wrote:
>>>
 I'm trying out DEVELOPMENT-SNAPSHOT-2016-11-29-a now. It's still
 going, so I don't have any time results yet. But, I did notice something
 new (or maybe existed before but didn't have this warning to expose it).
 For every Swift file that's compiled (only using -Onone here), it outputs
 the same 2 warnings (easy to fix, but not related to any of this) from the
 same method in the same Obj-C header referring to the arguments and the
 return types in that method:

 - "array parameter is missing a nullability type specifier (_Nonnull,
 _Nullable, or _Null_unspecified)"
 - "inferring '_Nonnull' for pointer type within array is deprecated"

 Here's an example of what this method looks like:

 + (NSSet *)setWithSELs:(SEL[])sels
 count:(NSUInteger)count;

 Could this point to more duplicated work?

 Ben

 On Thu, Dec 1, 2016 at 2:50 PM, Ben Asher  wrote:

> Sure! Thanks for reminding me. I'll follow up on that, test, and get
> back to you.
>
> Ben
>
> On Thu, Dec 1, 2016 at 2:48 PM, Mark Lacey 
> wrote:
>
>>
>> On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev <
>> swift-dev@swift.org> wrote:
>>
>> Just running a quick trial before and after I made this change in our
>> project, we were previously seeing builds of our main target that took 
>> just
>> under 13min. With this hack, a clean debug build takes about 4.5min.
>>
>>
>> You may find that recent snapshot builds from swift.org help with
>> your build times even without enabling -Owholemodule. The redundant type
>> checking of synthesized accessors which we talked about a month or two
>> should now be fixed on master, and it would be great to verify that’s the
>> case with your code and to get an idea of how much it improves your build
>> times.
>>
>> Mark
>>
>>
>> Ben
>>
>> On Thu, Dec 1, 2016 at 1:33 PM, Ben Asher  w
>> rote:
>>
>>> Okay I think that worked! And just to clarify, you meant set
>>> SWIFT_OPTIMIZATION_LEVEL = -Owholemodule and OTHER_SWIFT_FLAGS = -Onone 
>>> ?
>>>
>>> I'll file a radar this afternoon with some details and DM 

[swift-dev] TWISt-shout Newsletter 2016-12-05

[Kenny Leung via swift-dev]

Here is your TWISt-shout Newsletter for the week of 2016-11-28 to 2016-12-04

https://github.com/pepperdog/TWISt-shout/blob/master/2016/TWISt-shout-2016-12-05.md

Enjoy!

-Kenny



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

Re: [swift-dev] [swift-evolution] .swiftmodule format, a few short questions

[Joe Groff via swift-dev]

On Dec 5, 2016, at 9:40 AM, Joe Groff  wrote:


> On Dec 4, 2016, at 1:48 AM, Benjamin Spratling via swift-evolution 
>  wrote:
> 
> Howdy,
>   I would appreciate it if someone with a working knowledge of the 
> .swiftmodule format and especially the DECLS_AND_TYPES_BLOCK block would 
> contact me privately.
>   I’m working on a module which extracts information from .swiftmodule 
> files (the binary files, not the directories) to enable more advanced unit 
> tests which are otherwise implausible.  I have been able to access the basic 
> names of types and members, but I’m thus far unable to determine which 
> members belong in which types.
>   Brownie points if you can tell me how to do it without loading the hash 
> table in the TOP_LEVEL_DECLS block.
> -Ben Spratling


[-swift-evolution, +swift-dev]

Swift-evolution is for discussion of Swift language design, not its 
implementation.

-Joe

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

[swift-corelibs-dev] Broken master-next?

[Alex Blewitt via swift-corelibs-dev]

My pull request failed to build:

https://github.com/apple/swift-corelibs-foundation/pull/733 


The build failure is entirely unrelated to my changes; it looks like whatever 
point the branch was taken from/built from, the underlying swift implementation 
is broken:

https://ci.swift.org/job/swift-corelibs-foundation-PR-Linux/455/ 
 

In file included from 
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILFunction.h:20:
In file included from 
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILBasicBlock.h:21:
 
<>/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILInstruction.h:80:16:
 error: no template named 'ilist_sentinel_traits' in namespace 'llvm'; did you 
mean 'ilist_sentinel_tracking'?
  friend llvm::ilist_sentinel_traits;
 ~~^
   ilist_sentinel_tracking
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/llvm/include/llvm/ADT/ilist_node_options.h:25:47:
 note: 'ilist_sentinel_tracking' declared here
template  struct ilist_sentinel_tracking {};
  ^

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

[swift-corelibs-dev] Why is Array.init(contentsOfURL:) not available?

[Ole Begemann via swift-corelibs-dev]

(Apologies if this is not the right list to ask this question. I couldn't 
decide between swift-corelibs-dev and swift-dev.)

I noticed that the NSArray and NSDictionary initializers to create a collection 
from a property list file are not exposed in the stdlib Array and Dictionary 
types. The same is true for the corresponding methods to write a collection to 
a property list:

– init?(contentsOfFile:)
– init?(contentsOfURL:)
– write(toFile:atomically:)
– write(to:atomically:)

You can still call these from Swift by using NSArray or NSDictionary directly.

My question is why this decision was made, purely out of interest and because I 
couldn't find any information about this. I can imagine a few reasons:

1) Property lists are quite specific to Apple platforms and we don't want to 
"pollute" the standard library with platform-specific solutions.

2) Plists are just one of several potentially useful file formats and users 
might assume that an initializer to deserialize a collection from a file also 
supported other file formats, such as JSON or YAML, especially with a generic 
name like init(contentsOfFile:).

3) The resulting collections are heterogeneously typed ([Any] or [String:Any]) 
and as such not very pleasant to work with in Swift, so Array and Dictionary 
are really considered to be the wrong types to offer this functionality. It 
would be preferable to have a separate data type for working with plists, 
something like:

enum PropertyList {
case text(String)
case bool(Bool)
case int(Int)
case double(Double)
case date(Date)
indirect case array([PropertyList])
indirect case dict([String: PropertyList])
}

Thanks!
Ole

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

Re: [swift-corelibs-dev] SwiftXCTest proposals to make it more useful as a framework and for other platforms

[Ilya Laryionau via swift-corelibs-dev]

Brian,

I appreciate your comments.

> You should check out https://bugs.swift.org/browse/SR-710 
> . There's been a great deal of 
> discussion on this topic in the past. I think we left off with the idea that 
> we should use SourceKit to generate the list of tests (+cc Daniel Dunbar). 
> This work has largely been abandoned. If you'd like to pick it up, you could 
> have huge impact!

This’s a great comment. I’ll check what I can do.

> I'm not sure I understand your first two points. Are you suggesting that we 
> implement some method of kicking off tests on an iOS simulator, but only when 
> corelibs-xctest framework is linked with the application bundle...? I'd 
> appreciate it if you could explain what you mean in more detail.

Let me clarify my first two points.

In general you’re correct. I suggest implementing some method that triggers the 
same logic that XCTestMain does. But instead of calling exit, when the work is 
done, returning the exit code.
I suggest implementing API that allows creating XCTestSuite from a list of 
XCTestCaseEntries. 

Ilya

> On 2 Dec 2016, at 21:00, Brian Gesiak  wrote:
> 
> Hey Ilya,
> 
> I'm glad you're thinking about how to use corelibs-xctest on mobile devices. 
> I'd like to prepare it for Android as well, and I think there's a lot of 
> overlap here.
> 
> > This proposal is because Swift has very poor reflection at the moment. So I 
> > suggest creating a generator (pre-build script) for Swift test cases that 
> > for example is able analysing concrete folder with swift files and generate 
> > e.g. TestCases.swift file. This script is intended to be used manually.
> 
> You should check out https://bugs.swift.org/browse/SR-710 
> . There's been a great deal of 
> discussion on this topic in the past. I think we left off with the idea that 
> we should use SourceKit to generate the list of tests (+cc Daniel Dunbar). 
> This work has largely been abandoned. If you'd like to pick it up, you could 
> have huge impact!
> 
> I'm not sure I understand your first two points. Are you suggesting that we 
> implement some method of kicking off tests on an iOS simulator, but only when 
> corelibs-xctest framework is linked with the application bundle...? I'd 
> appreciate it if you could explain what you mean in more detail.
> 
> - Brian Gesiak
> 
> 
> On Fri, Dec 2, 2016 at 5:57 AM, Ilya Laryionau via swift-corelibs-dev 
> > wrote:
> Hello Community,
> 
> I’m working on adding iOS platform support for SwiftXCTest. So I’ve have the 
> following proposals and would like to hear feedback from the community.
> SwiftXCTest runs the tests in a way `XCTMain([ testCase(TestFoo.allTests) 
> ])`. XCTMain supports only Linux / FreeBSD / macOS. So I suggest introducing 
> an API that will provide a similar way of running tests as XCTMain, but in a 
> case using SwiftXCTest as a framework e.g. on iOS. It could be the same logic 
> that just returns exit code, when XCTMain just exits with this code.
> The suggestion above (number 1) is good, but too simple for using SwiftXCTest 
> as a framework, since we only have exit code and debug logs. So my second 
> proposal is providing mechanism of initialising root test suite with array of 
> testCases (array of XCTestCaseEntry objects) with the same structure that 
> XCTMain does. This isn’t possible now since XCTestCaseSuite class that is 
> used to initialise root test suite (see XCTMain.swift line 80) is internal.
> This proposal is because Swift has very poor reflection at the moment. So I 
> suggest creating a generator (pre-build script) for Swift test cases that for 
> example is able analysing concrete folder with swift files and generate e.g. 
> TestCases.swift file. This script is intended to be used manually.
> Looking forward to any feedback.
> 
> Ilya
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
> 
> 

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