[swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (swift 4.1) #328

[no-reply--- via swift-dev]

Title: Report


  
  
 
 

 [FAILURE] oss-swift-4.1-package-osx [#328] 


  Build URL:https://ci.swift.org/job/oss-swift-4.1-package-osx/328/
  Project:oss-swift-4.1-package-osx
  Date of build:Tue, 12 Dec 2017 07:38:12 -0600
  Build duration:3 hr 21 min







  





  Changes
  
	
  No Changes

  


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

Re: [swift-dev] [swift-evolution] Re-pitch: Deriving collections of enum cases

[Step Christopher via swift-dev]

Has this stalled out again? I would like to help with the proposal and even 
attempt implementation. 

I also need to catch up on the resilient discussion regarding enum case 
ordering. 

> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> 
> 
> Jacob Bandes-Storch
> 
> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon  
> wrote:
 On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
 
 1. It must be possible to easily access the count of values, and to access 
 any particular value using contiguous `Int` indices. This could be 
 achieved either by directly accessing elements in the list of values 
 through an Int subscript, or by constructing an Array from the list of 
 values.
 
 2. It must be possible to control the order of values in the list of 
 values, either by using source order or through some other simple, 
 straightforward mechanism.
>>>  
>>> OK, first of all, nowhere in the proposal text are these requirements 
>>> stated as part of the use case. You're free to put forward new use cases, 
>>> but here I am trying to design the most elegant way to fulfill a stated 
>>> need and you're telling me that it's something other than what's written.
>> 
>> Honestly, re-reading the proposal, it never cites a fully-formed use case. 
>> Instead, it cites several blog posts, Stack Overflow questions, and small 
>> code samples without digging in to the underlying reasons why developers are 
>> doing what they're doing. Most of the people discussing it so far seem to 
>> have had a tacit understanding that we wanted roughly Array-like access, but 
>> we haven't explicitly dug into which properties of an Array are important.
>> 
>> (If anyone involved feels like they had a different understanding of the use 
>> case, please speak up.)
>> 
>> I think this is a place where the proposal can be improved, and I'm willing 
>> to do some writing to improve it.
> 
> For the record, I would be happy to add co-authors (or even relinquish 
> authorship entirely—I don't really care whose name is on this, it just needs 
> to happen!) if you or anyone else has improved wording, motivation, 
> justification, etc. to contribute.
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [swift-evolution] Re-pitch: Deriving collections of enum cases

[Step Christopher via swift-dev]

The “base” case desire makes sense to me, but not as a part of this proposal. 
It might be a good follow-on. 

If all associated values are enumerable, it is tempting to try to make the top 
level enum valueEnumerable too. I wonder if even that should be a follow-on 
feature. 

As far as source-order, I want something like fragile enums to serve 
double-duty - but given where that discussion has gone I am not sure that is a 
possibility any more.

My planned next step is to write up some of these usage desires and 
constraints, and contribute those to the proposal. 

If we can coalesce towards something (magic for loop, collection property...) I 
would like to investigate implementation and see how feasible it is for me. I 
don’t know expect to be particularly quick at it but hopefully I can help move 
things along. 

> On Dec 9, 2017, at 9:27 PM, Jonathan Hull via swift-evolution via swift-dev 
>  wrote:
> 
> 
>>> On Nov 14, 2017, at 9:06 PM, Brent Royal-Gordon via swift-dev 
>>>  wrote:
>>> 
 On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
 
 1. It must be possible to easily access the count of values, and to access 
 any particular value using contiguous `Int` indices. This could be 
 achieved either by directly accessing elements in the list of values 
 through an Int subscript, or by constructing an Array from the list of 
 values.
 
 2. It must be possible to control the order of values in the list of 
 values, either by using source order or through some other simple, 
 straightforward mechanism.
>>>  
>>> OK, first of all, nowhere in the proposal text are these requirements 
>>> stated as part of the use case. You're free to put forward new use cases, 
>>> but here I am trying to design the most elegant way to fulfill a stated 
>>> need and you're telling me that it's something other than what's written.
>> 
>> Honestly, re-reading the proposal, it never cites a fully-formed use case. 
>> Instead, it cites several blog posts, Stack Overflow questions, and small 
>> code samples without digging in to the underlying reasons why developers are 
>> doing what they're doing. Most of the people discussing it so far seem to 
>> have had a tacit understanding that we wanted roughly Array-like access, but 
>> we haven't explicitly dug into which properties of an Array are important.
>> 
>> (If anyone involved feels like they had a different understanding of the use 
>> case, please speak up.)
>> 
>> I think this is a place where the proposal can be improved, and I'm willing 
>> to do some writing to improve it.
> 
> 
> This is a feature I have been requesting since Swift 1.  If the resulting 
> ordering is not SOURCE ordering, this feature loses most of it’s usefulness 
> for me. I would say around 80% of my uses for this require a predictable 
> ordering (and I don’t consider something based on compiler internals 
> predictable) which I can control.  As Brent said, most of those cases involve 
> something that shows to the user in some way.  The weekday example was a good 
> one (I actually have that in my code).  
> 
> The most painful case of this being missing was where I needed an enum of all 
> country codes (it is a beast to maintain).  In that case, I am displaying 
> them to the user in a tableView (along with icons named by the country 
> codes), but I am also filtering them based on the user’s input in a search 
> field.  To do both, you need to be able to iterate/filter an array of cases. 
> Awful to build. Just awful.
> 
> Also, I would greatly prefer an allValues/allCases method to having the type 
> be a collection. It just reads clearer in code what is going on.  I think 
> what I basically want to see is:
> 
>   protocol ValueEnumerable {
>   var allValues:Collection
>   }
> 
> …where both the conformance and implementation are automatically inferred for 
> enums when possible.
> 
> I would probably also end up using this protocol on Structs that I use as 
> extensible enums.  That is, I have a private/internal initializer and use 
> static vars in place of the cases.  This isn’t perfect, since part of the 
> reason I use these structs is that they can be built in a distributed way… 
> but I could find a way to build that array in a mostly distributed way as 
> well (and if we ever get the Multi-function capability I have suggested 
> elsewhere, then it could be truly distributed).
> 
> Semantically, the protocol should infer not only a finite number of cases, 
> but a number that can be iterated over in a reasonable period of time..  I 
> would be fine with Bool conforming, but not with Int.  With those semantics, 
> I could easily see a follow-on proposal which says that associated cases 
> where all of the values are ValueEnumerable are ValueEnumerable themselves.  
> This would be super useful for cascading enums.  I have a game that I am 
> working on in my spare time right now, where effects of actions are 
> represented a

Re: [swift-dev] [swift-evolution] Re-pitch: Deriving collections of enum cases

[Step Christopher via swift-dev]

The “base” case desire makes sense to me, but not as a part of this proposal. 
It might be a good follow-on. 

If all associated values are enumerable, it is tempting to try to make the top 
level enum valueEnumerable too. I wonder if even that should be a follow-on 
feature. 

As far as source-order, I want something like fragile enums to serve 
double-duty - but given where that discussion has gone I am not sure that is a 
possibility any more.

My planned next step is to write up some of these usage desires and 
constraints, and contribute those to the proposal. 

If we can coalesce towards something (magic for loop, collection property...) I 
would like to investigate implementation and see how feasible it is for me. I 
don’t know expect to be particularly quick at it but hopefully I can help move 
things along. 

> On Dec 9, 2017, at 9:27 PM, Jonathan Hull via swift-evolution via swift-dev 
>  wrote:
> 
> 
>>> On Nov 14, 2017, at 9:06 PM, Brent Royal-Gordon via swift-dev 
>>>  wrote:
>>> 
 On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
 
 1. It must be possible to easily access the count of values, and to access 
 any particular value using contiguous `Int` indices. This could be 
 achieved either by directly accessing elements in the list of values 
 through an Int subscript, or by constructing an Array from the list of 
 values.
 
 2. It must be possible to control the order of values in the list of 
 values, either by using source order or through some other simple, 
 straightforward mechanism.
>>>  
>>> OK, first of all, nowhere in the proposal text are these requirements 
>>> stated as part of the use case. You're free to put forward new use cases, 
>>> but here I am trying to design the most elegant way to fulfill a stated 
>>> need and you're telling me that it's something other than what's written.
>> 
>> Honestly, re-reading the proposal, it never cites a fully-formed use case.. 
>> Instead, it cites several blog posts, Stack Overflow questions, and small 
>> code samples without digging in to the underlying reasons why developers are 
>> doing what they're doing. Most of the people discussing it so far seem to 
>> have had a tacit understanding that we wanted roughly Array-like access, but 
>> we haven't explicitly dug into which properties of an Array are important.
>> 
>> (If anyone involved feels like they had a different understanding of the use 
>> case, please speak up.)
>> 
>> I think this is a place where the proposal can be improved, and I'm willing 
>> to do some writing to improve it.
> 
> 
> This is a feature I have been requesting since Swift 1.  If the resulting 
> ordering is not SOURCE ordering, this feature loses most of it’s usefulness 
> for me. I would say around 80% of my uses for this require a predictable 
> ordering (and I don’t consider something based on compiler internals 
> predictable) which I can control.  As Brent said, most of those cases involve 
> something that shows to the user in some way.  The weekday example was a good 
> one (I actually have that in my code).  
> 
> The most painful case of this being missing was where I needed an enum of all 
> country codes (it is a beast to maintain).  In that case, I am displaying 
> them to the user in a tableView (along with icons named by the country 
> codes), but I am also filtering them based on the user’s input in a search 
> field.  To do both, you need to be able to iterate/filter an array of cases. 
> Awful to build. Just awful.
> 
> Also, I would greatly prefer an allValues/allCases method to having the type 
> be a collection. It just reads clearer in code what is going on.  I think 
> what I basically want to see is:
> 
>   protocol ValueEnumerable {
>   var allValues:Collection
>   }
> 
> …where both the conformance and implementation are automatically inferred for 
> enums when possible.
> 
> I would probably also end up using this protocol on Structs that I use as 
> extensible enums.  That is, I have a private/internal initializer and use 
> static vars in place of the cases.  This isn’t perfect, since part of the 
> reason I use these structs is that they can be built in a distributed way… 
> but I could find a way to build that array in a mostly distributed way as 
> well (and if we ever get the Multi-function capability I have suggested 
> elsewhere, then it could be truly distributed).
> 
> Semantically, the protocol should infer not only a finite number of cases, 
> but a number that can be iterated over in a reasonable period of time..  I 
> would be fine with Bool conforming, but not with Int.  With those semantics, 
> I could easily see a follow-on proposal which says that associated cases 
> where all of the values are ValueEnumerable are ValueEnumerable themselves.  
> This would be super useful for cascading enums.  I have a game that I am 
> working on in my spare time right now, where effects of actions are 
> represented 

Re: [swift-dev] Getting started with lib/Syntax

[Yurii Samsoniuk via swift-dev]

Hi Xi,

Thanks for your reply. I'll grab another bug then.

Cheers,
Yura

пн, 11 груд. 2017 о 22:10 Xi Ge  пише:

> Great to hear that! Please feel free to self-assign this task.
>
>
> Xi
>
> On Dec 11, 2017, at 12:45 PM, Faiçal Tchirou  wrote:
>
> Hi Xi,
>
> I would be interested in SR-6571.
>
> Thanks,
> Faiçal
> On Mon, 11 Dec 2017 at 21:26, Xi Ge  wrote:
>
>> Hi Yurii and Faiçal,
>> Currently, we are in the process of extending Swift parser to generate
>> libSyntax entities. A newly specialized libSyntax node will enable detailed
>> client-side analysis/transformation on that node.
>> Are you interested in helping with this (mostly compiler/parser side
>> change)? If so, please take a look at these two Jira tasks for more details:
>>
>> https://bugs.swift.org/browse/SR-6571
>> https://bugs.swift.org/browse/SR-6572
>>
>> Please let us know if you're interested in implementing one of them.
>>
>> cheers
>> Xi
>>
>>
>>
>> On Dec 9, 2017, at 12:55 PM, Faiçal Tchirou via swift-dev <
>> swift-dev@swift.org> wrote:
>>
>> I’m also interested in this. Anything I can do to help so Swift devs can
>> focus on more important problems?
>>
>> Thanks,
>> Faiçal
>> On Thu, 7 Dec 2017 at 00:24, Yurii Samsoniuk via swift-dev <
>> swift-dev@swift.org> wrote:
>>
>>> I have some spare time and I want to do something for Swift. I’m
>>> interested in lib/Syntax. What can a beginner do? What’s a not too
>>> complicated problem I can solve?
>>>
>>> Cheers,
>>> Yura
>>> ___
>>> 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #2003

[Adam Nemet via swift-dev]

Seems unrelated to my change which should only affect benchmarks. Is this test 
known to be flaky?

 TEST 'Swift(linux-x86_64) :: 
AutolinkExtract/import_archive.swift' FAILED 
Script:
--
rm -rf 
"/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/AutolinkExtract/Output/import_archive.swift.tmp"
 && mkdir -p 
"/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/AutolinkExtract/Output/import_archive.swift.tmp"
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/bin/swiftc
 -target x86_64-unknown-linux-gnu  -module-cache-path 
'/tmp/swift-testsuite-clang-module-cachebHZS3y' -emit-library -emit-module 
-emit-module-path 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/AutolinkExtract/Output/import_archive.swift.tmp/empty.swiftmodule
 -module-name empty -module-link-name empty 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test/AutolinkExtract/empty.swift
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/bin/swiftc
 -target x86_64-unknown-linux-gnu  -module-cache-path 
'/tmp/swift-testsuite-clang-module-cachebHZS3y' -c 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test/AutolinkExtract/import_archive.swift
 -I 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/AutolinkExtract/Output/import_archive.swift.tmp
 -o 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/AutolinkExtract/Output/import_archive.swift.tmp/import_experimental.o
llvm-ar cr 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/AutolinkExtract/Output/import_archive.swift.tmp/import_experimental.a
 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/AutolinkExtract/Output/import_archive.swift.tmp/import_experimental.o
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/bin/swift-autolink-extract
 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/AutolinkExtract/Output/import_archive.swift.tmp/import_experimental.a
 -o - | 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/utils/PathSanitizingFileCheck
 --sanitize 
'BUILD_DIR=/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/swift-linux-x86_64'
 --sanitize 
'SOURCE_DIR=/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift'
 --use-filecheck 
'/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/llvm-linux-x86_64/./bin/FileCheck'
 --check-prefix CHECK-elf 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/test/AutolinkExtract/import_archive.swift
--
Exit Code: 254

Command Output (stderr):
--
 <>clang-5.0: error: unable to execute command: Bus error (core dumped)
clang-5.0: error: linker command failed due to signal (use -v to see invocation)
:0: error: link command failed with exit code 254 (use -v to see 
invocation)


> On Dec 12, 2017, at 9:32 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#2003]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/2003/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Tue, 12 Dec 2017 11:08:18 -0600
> Build duration:   24 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 30cbf7e9e528ae51b08971a5d01fc5220ec711ff by anemet:
> Support opt-viewer with multi-source benchmarks as well
> 
> edit: benchmark/cmake/modules/AddSwiftBenchmarkSuite.cmake

__

Re: [swift-dev] Protocol Devirtualizer Pass

[Raj Barik via swift-dev]

Thanks for the recommendations, Slava. Although I am able to create both
the generic function and the wrapper thunk, I get a crash in the existing
performance inliner pass while iterating over the apply instruction and
trying to perform substitution. Here is the SIL that I generate:

sil hidden [thunk] [always_inline]
@_T04main8wrap_incSiAA11SumProtocol_p1a_Si3valtF : $@convention(thin)
(@owned SumProtocol, Int) -> Int {
// %0 // user: %3
// %1 // user: %4
bb0(%0 : $SumProtocol, %1 : $Int):
  // function_ref specialized wrap_inc(a:val:)
  %2 = function_ref @_T04main8wrap_incSiAA11SumProtocol_p1a_Si3valtFTf4nn_n
: $@convention(thin) <τ_0_0 where τ_0_0 : SumProtocol> (@owned τ_0_0, Int)
-> Int // user: %4
  %3 = open_existential_ref %0 : $SumProtocol to
$@opened("E6196082-DF72-11E7-8C84-420039484801") SumProtocol // user: %4
  %4 = apply %2<τ_0_0>(%3, %1) : $@convention(thin) <τ_0_0 where τ_0_0 :
SumProtocol> (@owned τ_0_0, Int) -> Int // user: %5
  return %4 : $Int// id: %5
} // end sil function '_T04main8wrap_incSiAA11SumProtocol_p1a_Si3valtF'

// specialized wrap_inc(a:val:)
sil shared [noinline]
@_T04main8wrap_incSiAA11SumProtocol_p1a_Si3valtFTf4nn_n :
$@convention(thin) <τ_0_0 where τ_0_0 : SumProtocol> (@owned τ_0_0, Int) ->
Int {
// %0 // users: %3, %2
// %1 // user: %4
bb0(%0 : $τ_0_0, %1 : $Int):
  debug_value_addr %0 : $τ_0_0, let, name "a"// id: %2
  %3 = unchecked_ref_cast %0 : $τ_0_0 to $SumProtocol // user: %4
  br bb1(%3 : $SumProtocol, %1 : $Int)// id: %4

// %5 // users: %12, %9, %7
// %6 // users: %11, %8
bb1(%5 : $SumProtocol, %6 : $Int):// Preds: bb0
  debug_value %5 : $SumProtocol, let, name "a", argno 1 // id: %7
  debug_value %6 : $Int, let, name "val", argno 2 // id: %8
  %9 = open_existential_ref %5 : $SumProtocol to
$@opened("E60585BC-DF72-11E7-8C84-420039484801") SumProtocol // users: %11,
%11, %10
  %10 = witness_method $@opened("E60585BC-DF72-11E7-8C84-420039484801")
SumProtocol, #SumProtocol.increment!1 : 
(Self) -> (Int) -> Int, %9 :
$@opened("E60585BC-DF72-11E7-8C84-420039484801") SumProtocol :
$@convention(witness_method) <τ_0_0 where τ_0_0 : SumProtocol> (Int,
@guaranteed τ_0_0) -> Int // type-defs: %9; user: %11
  %11 = apply %10<@opened("E60585BC-DF72-11E7-8C84-420039484801")
SumProtocol>(%6, %9) : $@convention(witness_method) <τ_0_0 where τ_0_0 :
SumProtocol> (Int, @guaranteed τ_0_0) -> Int // type-defs: %9; user: %13
  strong_release %5 : $SumProtocol// id: %12
  return %11 : $Int   // id: %13
} // end sil function
'_T04main8wrap_incSiAA11SumProtocol_p1a_Si3valtFTf4nn_n'


*One more question*: Is it OK to open an existential reference twice? In
the above code, I open the protocol in the thunk and also in the generic
wrapper.


0  swift0x00010980e278
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  swift0x00010980d1c6
llvm::sys::RunSignalHandlers() + 86
2  swift0x00010980e83e SignalHandler(int) + 366
3  libsystem_platform.dylib 0x7fff7baa4f5a _sigtramp + 26
4  libdyld.dylib0x7fff7b824279 dyldGlobalLockRelease() + 0
5  libsystem_c.dylib0x7fff7b8d030a abort + 127
6  libsystem_c.dylib0x7fff7b898360 basename_r + 0
7  swift0x0001075230cb
swift::SubstitutionMap::lookupSubstitution(swift::CanTypeWrapper)
const + 651
8  swift0x000107534904 llvm::Optional
llvm::function_ref
(swift::TypeBase*)>::callback_fn,
llvm::function_ref
(swift::CanType, swift::Type, swift::ProtocolType*)>,
swift::SubstOptions)::$_18>(long, swift::TypeBase*) + 884
9  swift0x000107531367
swift::Type::transformRec(llvm::function_ref
(swift::TypeBase*)>) const + 151
10 swift0x00010752fcb4
swift::Type::subst(llvm::function_ref,
llvm::function_ref
(swift::CanType, swift::Type, swift::ProtocolType*)>, swift::SubstOptions)
const + 196
11 swift0x000106fe9ad7 (anonymous
namespace)::SILTypeSubstituter::visitType(swift::CanType) + 119
12 swift0x000106fe953e swift::CanType
swift::CanTypeVisitor<(anonymous namespace)::SILTypeSubstituter,
swift::CanType>::visit<>(swift::CanType) + 94
13 swift0x000106fe4e8f (anonymous
namespace)::SILTypeSubstituter::substSILFunctionType(swift::CanTypeWrapper)
+ 607
14 swift0x000106fe961f swift::CanType
swift::CanTypeVisitor<(anonymous namespace)::SILTypeSubstituter,
swift::CanType>::visit<>(swift::CanType) + 319
15 swift0x000106fe49ea
swift::SILType::subst(swift::SILModule&, llvm::function_ref,

Re: [swift-dev] Request for review on Windows CMake changes

[Saleem Abdulrasool via swift-dev]

On Sat, Dec 9, 2017 at 9:21 AM, David Zarzycki via swift-dev <
swift-dev@swift.org> wrote:

> Can somebody please also speak up to why Windows needs to remove the
> "-Wl,-z,defs” from CXX_FLAGS? At the very least, I’d like to see the
> project-wide removal of this useful flag limited to just the Windows builds.
>

Currently, the way that swift approaches building goes against the way that
CMake intended cross-compilation to work.  The result is that we end up
having to do a number of fairly nasty things to get things to work.
Options are not spelt the same way nor do all options make sense on all
targets.  `-z defs` is an ELF specific option.  However, because we use the
same rules for all targets using the build as the host, we cannot simply
filter based on the target.  Instead, this needs to be done at the lowest
possible layer when we know if the build is ELF or COFF or MachO.  That
said, I think that exporting this flag from LLVM is not the right thing and
that swift should be re-adding that flag if it so decides to use (which for
ELF targets, it really is a good idea).

I think that if we start splitting things up and using ExternalProject to
joining the various pieces we should be able to accommodate that and re-use
the cross-compilation support in CMake.  I think that there is some work
that has been done there for the SDK overlay and libdispatch.


>
> On Dec 8, 2017, at 20:36, Thomas Roughton via swift-dev <
> swift-dev@swift.org> wrote:
>
> Hi all,
>
> I've had a PR (https://github.com/apple/swift/pull/13140) that's been
> open for about 10 days with a few CMake changes to fix the Windows
> cross-compile build. I wasn't sure who best to ask to review it, but was
> suggested to post here with it.
>
> Could someone familiar with that area maybe add themselves as a reviewer
> and then later take a look when they get a chance (even if that's not for a
> few weeks)? There's no particular urgency, but it'd be ideal if possible to
> have the changes in before it needs to be rebased too many times.
>
> Thanks,
> Thomas
> ___
> 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
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[Douglas Gregor via swift-dev]

> On Dec 10, 2017, at 4:47 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Dec 5, 2017, at 2:28 PM, Douglas Gregor via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> To perform that mapping from a mangled type in a conditional requirement to 
>> type metadata, we effectively need an operation to take a mangled type name 
>> and turn it into a type metadata pointer. This is something we could surface 
>> in the Swift standard library/runtime as, e.g.,
>> 
>> func type(named: String) -> Any.Type?
>> 
>> to take a mangled type name and try to get the type metadata for it. From 
>> there, one can query protocol conformances that (say) allow one to construct 
>> instances of the arbitrarily-named type. Think of it as NSClassFromString 
>> for any type in the Swift language, including specializations of generic 
>> types.
> 
> 
> It's worth noting here that the standard library already provides a limited 
> `_typeByName(_:)` function for Corelibs Foundation to use. That function will 
> presumably become part of the ABI unless we design a public version in Swift 
> 5.


Woah. That’s kinda awful… it parses “Foo.Bar” as a class name and looks for 
class Bar in module Foo.

- Doug

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

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

[Jordan Rose via swift-dev]

> On Dec 12, 2017, at 14:15, Douglas Gregor via swift-dev  
> wrote:
> 
> 
> 
>> On Dec 10, 2017, at 4:47 PM, Brent Royal-Gordon > > wrote:
>> 
>>> On Dec 5, 2017, at 2:28 PM, Douglas Gregor via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> To perform that mapping from a mangled type in a conditional requirement to 
>>> type metadata, we effectively need an operation to take a mangled type name 
>>> and turn it into a type metadata pointer. This is something we could 
>>> surface in the Swift standard library/runtime as, e.g.,
>>> 
>>> func type(named: String) -> Any.Type?
>>> 
>>> to take a mangled type name and try to get the type metadata for it. From 
>>> there, one can query protocol conformances that (say) allow one to 
>>> construct instances of the arbitrarily-named type. Think of it as 
>>> NSClassFromString for any type in the Swift language, including 
>>> specializations of generic types.
>> 
>> 
>> It's worth noting here that the standard library already provides a limited 
>> `_typeByName(_:)` function for Corelibs Foundation to use. That function 
>> will presumably become part of the ABI unless we design a public version in 
>> Swift 5.
> 
> 
> Woah. That’s kinda awful… it parses “Foo.Bar” as a class name and looks for 
> class Bar in module Foo.

Needed to implement NSCoding on Linux. They did limit it to "Foo.Bar" at least, 
deliberately excluding anything more complicated.

Jordan

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

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

[Douglas Gregor via swift-dev]

> On Dec 12, 2017, at 2:29 PM, Jordan Rose  wrote:
> 
> 
> 
>> On Dec 12, 2017, at 14:15, Douglas Gregor via swift-dev > > wrote:
>> 
>> 
>> 
>>> On Dec 10, 2017, at 4:47 PM, Brent Royal-Gordon >> > wrote:
>>> 
 On Dec 5, 2017, at 2:28 PM, Douglas Gregor via swift-dev 
 mailto:swift-dev@swift.org>> wrote:
 
 To perform that mapping from a mangled type in a conditional requirement 
 to type metadata, we effectively need an operation to take a mangled type 
 name and turn it into a type metadata pointer. This is something we could 
 surface in the Swift standard library/runtime as, e.g.,
 
 func type(named: String) -> Any.Type?
 
 to take a mangled type name and try to get the type metadata for it. From 
 there, one can query protocol conformances that (say) allow one to 
 construct instances of the arbitrarily-named type. Think of it as 
 NSClassFromString for any type in the Swift language, including 
 specializations of generic types.
>>> 
>>> 
>>> It's worth noting here that the standard library already provides a limited 
>>> `_typeByName(_:)` function for Corelibs Foundation to use. That function 
>>> will presumably become part of the ABI unless we design a public version in 
>>> Swift 5.
>> 
>> 
>> Woah. That’s kinda awful… it parses “Foo.Bar” as a class name and looks for 
>> class Bar in module Foo.
> 
> Needed to implement NSCoding on Linux. They did limit it to "Foo.Bar" at 
> least, deliberately excluding anything more complicated.

Makes sense. A type(named:) would serve their use case better, of course.

- Doug


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

Re: [swift-dev] Request for review on Windows CMake changes

[Wallacy via swift-dev]

Has anyone considered the Bezel Build for swift?

https://bazel.build/

Seems to address these problems.

Em ter, 12 de dez de 2017 às 19:39, Saleem Abdulrasool via swift-dev <
swift-dev@swift.org> escreveu:

> On Sat, Dec 9, 2017 at 9:21 AM, David Zarzycki via swift-dev <
> swift-dev@swift.org> wrote:
>
>> Can somebody please also speak up to why Windows needs to remove the
>> "-Wl,-z,defs” from CXX_FLAGS? At the very least, I’d like to see the
>> project-wide removal of this useful flag limited to just the Windows builds.
>>
>
> Currently, the way that swift approaches building goes against the way
> that CMake intended cross-compilation to work.  The result is that we end
> up having to do a number of fairly nasty things to get things to work.
> Options are not spelt the same way nor do all options make sense on all
> targets.  `-z defs` is an ELF specific option.  However, because we use the
> same rules for all targets using the build as the host, we cannot simply
> filter based on the target.  Instead, this needs to be done at the lowest
> possible layer when we know if the build is ELF or COFF or MachO.  That
> said, I think that exporting this flag from LLVM is not the right thing and
> that swift should be re-adding that flag if it so decides to use (which for
> ELF targets, it really is a good idea).
>
> I think that if we start splitting things up and using ExternalProject to
> joining the various pieces we should be able to accommodate that and re-use
> the cross-compilation support in CMake.  I think that there is some work
> that has been done there for the SDK overlay and libdispatch.
>
>
>>
>> On Dec 8, 2017, at 20:36, Thomas Roughton via swift-dev <
>> swift-dev@swift.org> wrote:
>>
>> Hi all,
>>
>> I've had a PR (https://github.com/apple/swift/pull/13140) that's been
>> open for about 10 days with a few CMake changes to fix the Windows
>> cross-compile build. I wasn't sure who best to ask to review it, but was
>> suggested to post here with it.
>>
>> Could someone familiar with that area maybe add themselves as a reviewer
>> and then later take a look when they get a chance (even if that's not for a
>> few weeks)? There's no particular urgency, but it'd be ideal if possible to
>> have the changes in before it needs to be rebased too many times.
>>
>> Thanks,
>> Thomas
>> ___
>> 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
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> ___
> 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] Swift CI - Failure notification email sender changed

[Mishal Shah via swift-dev]

Swift CI failure email notification will start coming from swift...@swift.org. 

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

Re: [swift-dev] Request for review on Windows CMake changes

[Saleem Abdulrasool via swift-dev]

On Tue, Dec 12, 2017 at 4:47 PM, Wallacy  wrote:

> Has anyone considered the Bezel Build for swift?
>
> https://bazel.build/
>
> Seems to address these problems.


I'm sorry, but I fail to see how bazel would address any of these issues.
The flags are exported from LLVM's CMake infrastructure.  First of all, we
would have to recreate all the dependency information from LLVM to import
that into this new build system.  Next, we need to reconstruct parts of
clang to re-embed into the swift compiler.  We also now have the additional
cognitive overhead of switching build systems going between clang/LLVM and
swift.  We would lose the dependency tracking or need to reconstruct all of
that and maintain it.

The problems with the cross-compiling that Im referring to are not inherent
to CMake (although, I am slightly partial to the autotools approach to
cross-compilation), but rather the way that the tool is being used within
the context of swift.  As an example, libdispatch is extremely easy to
cross-compile thanks to its use of CMake.


>
> Em ter, 12 de dez de 2017 às 19:39, Saleem Abdulrasool via swift-dev <
> swift-dev@swift.org> escreveu:
>
>> On Sat, Dec 9, 2017 at 9:21 AM, David Zarzycki via swift-dev <
>> swift-dev@swift.org> wrote:
>>
>>> Can somebody please also speak up to why Windows needs to remove the
>>> "-Wl,-z,defs” from CXX_FLAGS? At the very least, I’d like to see the
>>> project-wide removal of this useful flag limited to just the Windows builds.
>>>
>>
>> Currently, the way that swift approaches building goes against the way
>> that CMake intended cross-compilation to work.  The result is that we end
>> up having to do a number of fairly nasty things to get things to work.
>> Options are not spelt the same way nor do all options make sense on all
>> targets.  `-z defs` is an ELF specific option.  However, because we use the
>> same rules for all targets using the build as the host, we cannot simply
>> filter based on the target.  Instead, this needs to be done at the lowest
>> possible layer when we know if the build is ELF or COFF or MachO.  That
>> said, I think that exporting this flag from LLVM is not the right thing and
>> that swift should be re-adding that flag if it so decides to use (which for
>> ELF targets, it really is a good idea).
>>
>> I think that if we start splitting things up and using ExternalProject to
>> joining the various pieces we should be able to accommodate that and re-use
>> the cross-compilation support in CMake.  I think that there is some work
>> that has been done there for the SDK overlay and libdispatch.
>>
>>
>>>
>>> On Dec 8, 2017, at 20:36, Thomas Roughton via swift-dev <
>>> swift-dev@swift.org> wrote:
>>>
>>> Hi all,
>>>
>>> I've had a PR (https://github.com/apple/swift/pull/13140) that's been
>>> open for about 10 days with a few CMake changes to fix the Windows
>>> cross-compile build. I wasn't sure who best to ask to review it, but was
>>> suggested to post here with it.
>>>
>>> Could someone familiar with that area maybe add themselves as a reviewer
>>> and then later take a look when they get a chance (even if that's not for a
>>> few weeks)? There's no particular urgency, but it'd be ideal if possible to
>>> have the changes in before it needs to be rebased too many times.
>>>
>>> Thanks,
>>> Thomas
>>> ___
>>> 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
>>>
>>>
>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Request for review on Windows CMake changes

[Greg Parker via swift-dev]

> On Dec 12, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> The problems with the cross-compiling that Im referring to are not inherent 
> to CMake (although, I am slightly partial to the autotools approach to 
> cross-compilation), but rather the way that the tool is being used within the 
> context of swift.  As an example, libdispatch is extremely easy to 
> cross-compile thanks to its use of CMake.

CMake's cross-compilation machinery was unable to build for iOS at the time 
that Swift needed it. It's possible that CMake has improved enough since then 
that Swift could use more of CMake's built-in capabilities.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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