[swift-dev] [Swift CI] Build Failure: 1. OSS - Swift (Tools Opt+Assert, Stdlib Opt+DebInfo+Assert, Resilience) - macOS (master) #160

2018-01-08 Thread swift-ci--- via swift-dev 
Groovy Template file [build-report.groovy] was not found in $JENKINS_HOME/email-templates.___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

2018-01-08 Thread swift-ci--- via swift-dev 
Title: Report


  
  
 
 

 [FAILURE] oss-swift-package-osx [#998] 


  Build URL:https://ci.swift.org/job/oss-swift-package-osx/998/
  Project:oss-swift-package-osx
  Date of build:Sun, 07 Jan 2018 03:22:34 -0600
  Build duration:2 hr 20 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 8b4dfd812aee0e42039c938c7300cc20b1e77ada by spestov: SILGen: Fix crash when emitting implicit 'super.init()' delegation to


  edit: lib/SILGen/SILGenConstructor.cpp

  edit: test/SILGen/auto_generated_super_init_call.swift


  
 

  Commit 859b58e28e14581ac366349dd6b0e58c2aa56bdf by eeckstein: SIL: allow parsing of sil_globals with a $-identifier


  edit: lib/ParseSIL/ParseSIL.cpp


  
 

  Commit cd3d50a5d9948cff0ba6eae47d44957592e8bb44 by eeckstein: ABI: Change the mangling prefix from _T0 to $S


  edit: test/SILOptimizer/devirt_single_module_in_multiple_files.swift

  edit: test/IRGen/indirect_return.swift

  edit: test/SILGen/c_function_pointers.swift

  edit: test/SILGen/partial_apply_init.swift

  edit: test/SIL/Serialization/vtable.sil

  edit: test/SILGen/unsafe_pointer_gen.swift

  edit: test/DebugInfo/closure-multivalue.swift

  edit: test/SILGen/properties.swift

  edit: test/IRGen/generic_classes.sil

  edit: test/SILGen/pgo_foreach.swift

  edit: test/ClangImporter/attr-swift_private.swift

  edit: test/IRGen/objc_deprecated_objc_thunks.swift

  edit: test/SILGen/switch_var.swift

  edit: test/SILGen/pgo_switchenum.swift

  edit: test/SourceKit/InterfaceGen/gen_stdlib.swift

  edit: test/SILGen/objc_factory_init.swift

  edit: test/SILGen/objc_witnesses.swift

  edit: test/SILGen/property_abstraction.swift

  edit: test/DebugInfo/implicitdecl.swift

  edit: test/IRGen/field_type_vectors.sil

  edit: test/SourceKit/CursorInfo/cursor_stdlib.swift

  edit: test/SILGen/guaranteed_normal_args_curry_thunks.swift

  edit: test/SILOptimizer/array_element_propagation.sil

  edit: test/IRGen/static_initializer.sil

  edit: test/SILOptimizer/specialize_dynamic_self.swift

  edit: test/SILGen/versioned_attribute.swift

  edit: test/SILGen/static-stored-properties-in-concrete-contexts.swift

  edit: test/SILGen/witness-init-requirement-with-base-class-init.swift

  edit: test/IRGen/c_functions.swift

  edit: test/IRGen/coverage.swift

  edit: test/SILGen/required_init.swift

  edit: test/DebugInfo/closure-arg-linetable.swift

  edit: test/SILGen/ivar_destroyer.swift

  edit: test/SILGen/super_objc_class_method.swift

  edit: test/SILGen/vtable_thunks.swift

  edit: test/SIL/Serialization/specializer_can_deserialize.swift

  edit: test/SILOptimizer/devirt_method_with_generic_params.swift

  edit: test/SILOptimizer/specialize_deep_generics.swift

  edit: test/SILGen/protocol_optional.swift

  edit: test/SILGen/reabstract_lvalue.swift

  edit: test/IRGen/struct_layout.sil

  edit: test/SILOptimizer/capture_promotion_reachability.sil

  edit: test/IRGen/keypaths_objc.sil

  edit: test/SILGen/global_init_attribute.swift

  edit: test/SILOptimizer/specialize_anyobject.swift

  edit: test/SILGen/lying_about_optional_return.swift

  edit: test/SILGen/force_cast_chained_optional.swift

  edit: test/SILOptimizer/super_method.swift

  edit: test/DebugInfo/shadow_copies.swift

  edit: test/IRGen/abi_v7k.swift

  edit: test/SILOptimizer/access_enforcement_selection.swift

  edit: test/SILGen/existential_erasure.swift

  edit: test/SILOptimizer/functionsigopts.sil

  edit: test/IRGen/abitypes.swift

  edit: test/SILGen/retaining_globals.swift

  edit: test/SILOptimizer/specialize_unconditional_checked_cast.swift

  edit: test/IRGen/asmname.swift

  edit: test/IRGen/unowned_objc.sil

  edit: test/SILOptimizer/definite_init_failable_initializers_objc.swift

  edit: test/SILOptimizer/cast_folding_objc.swift

  edit: test/SILGen/default_arguments.swift

  edit: test/SILGen/lifetime.swift

  edit: test/DebugInfo/pcomp.swift

  edit: test/IRGen/indirect_enum.sil

  edit: test/IRGen/generic_vtable.swift

  edit: test/SILGen/availability_query.swift

  edit: test/SILGen/same_type_abstraction.swift

  edit: test/SILGen/arguments_as_tuple_overloads.swift

  edit: test/IRGen/clang_inline_reverse.swift

  edit: test/SILOptimizer/super_init.swift

  edit

[swift-dev] Where is Collection defined?

2018-01-08 Thread Daryle Walker via swift-dev 
I’ve looked around 
 and read 
through the various Sequence and Collection definition files. AIUI, you don’t 
have to define both versions of Collection.subscript; the system will 
automatically define the missing one in terms of the other. But the source 
files I read don’t have a default implementation for either version of 
subscript. Where is that code located?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

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

2018-01-08 Thread swift-ci--- via swift-dev 
Title: Report


  
  
 
 

 [FAILURE] oss-swift-package-osx [#995] 


  Build URL:https://ci.swift.org/job/oss-swift-package-osx/995/
  Project:oss-swift-package-osx
  Date of build:Sat, 06 Jan 2018 10:46:19 -0600
  Build duration:4 hr 35 min







  





  Changes
  
	
  No Changes

  


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

[swift-dev] heads-up: some temporary build failures

2018-01-08 Thread Erik Eckstein via swift-dev 
I just merged a mangling change into the swift repo. This will cause some build 
failures on linux until my foundation PR gets merged. Should be resolved in the 
next hours.

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

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

2018-01-08 Thread swift-ci--- via swift-dev 
Title: Report


  
  
 
 

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


  Build URL:https://ci.swift.org/job/oss-swift-4.1-package-osx/490/
  Project:oss-swift-4.1-package-osx
  Date of build:Sat, 06 Jan 2018 00:44:40 -0600
  Build duration:2 hr 51 min







  





  Changes
  

  Commit c7c9ec7026936f13cd71c174ee250ba5ee7033ab by shajrawi: Merge pull request #13763 from shajrawi/arch_class_irgen2


  add: test/IRGen/archetype_resilience.sil

  edit: lib/IRGen/GenHeap.cpp

  edit: lib/IRGen/GenArchetype.cpp


  
 

  


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

Re: [swift-dev] [swift-corelibs-dev] Discourse rollout re-schedule

2018-01-08 Thread Nicole Jacque via swift-dev 
We did a re-set of the forum content and it overwrote all the temporary data.  
I’ll put up new instructions and pin them to the front page.

> On Jan 6, 2018, at 3:13 PM, Lars Sonchocky-Helldorf 
>  wrote:
> 
> Hi Nicole,
> 
>> Am 15.12.2017 um 03:59 schrieb Nicole Jacque via swift-corelibs-dev 
>> mailto:swift-corelibs-...@swift.org>>:
>> 
>> Hi All-
>> 
>> First of all, a big thank you to everyone who has provided feedback on our 
>> prototype Discourse forum.  Based on the fact that we’re still receiving 
>> feedback, we’d like to move to a slightly less aggressive schedule for our 
>> rollout, in order to make sure that we’ve adequately addressed it.  We’re 
>> still working out an exact schedule, but due to the upcoming holidays, I 
>> expect that we’ll be looking at shortly after the beginning of the new year.
>> 
>> In the meantime, I’ve moved the prototype forum to https://forums.swift.org 
>> , and I have GitHub-enabled logins working if 
>> you’d like to give it a try!  You can also test out registering (including 
>> using the staged account pre-created from your mailing list account).  
>> Instructions are here: 
>> https://forums.swift.org/t/taking-over-a-pre-created-staged-account/7121 
>> 
> 
> that link doesn’t work for me, it redirects me to:
> 
> https://forums.swift.org/t/synthesizing-equatable-hashable-and-comparable-for-tuple-types/7121
>  
> 
> 
> I am missing something?
> 
> Thanks and happy new year,
> 
>   Lars

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

[swift-dev] JIRA down

2018-01-08 Thread Michael Gottesman via swift-dev 
The JIRA looks like it is down...

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

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

2018-01-08 Thread swift-ci--- via swift-dev 
Title: Report


  
  
 
 

 [FAILURE] oss-swift-package-osx [#992] 


  Build URL:https://ci.swift.org/job/oss-swift-package-osx/992/
  Project:oss-swift-package-osx
  Date of build:Sat, 06 Jan 2018 00:47:12 -0600
  Build duration:2 hr 48 min







  





  Changes
  

  Commit 08ed42076d44cdbe3a5f3f0bece2bc7b9f0345ee by pyaskevich: [Runtime] NFC: Remove getBlockTypeMetadata* API stubs


  edit: include/swift/Runtime/Metadata.h


  
 

  Commit 300587a5072db88f3bcb8922983efa371031 by pyaskevich: [Runtime] NFC: Remove getCFunctionTypeMetadata* stubs


  edit: include/swift/Runtime/Metadata.h


  
 

  Commit d787a14d6cb978664fe2eb2ba0db95420be9cc55 by pyaskevich: [Runtime] NFC: Remove getThinFunctionTypeMetadata* stubs


  edit: include/swift/Runtime/Metadata.h


  
 

  Commit 8409cdb8a2e74cf9af9b7c9c5941a70c5ea5b926 by pyaskevich: [Runtime/ABI] Add swift_getFunctionTypeMetadata0 function


  edit: include/swift/Runtime/Metadata.h

  edit: lib/IRGen/GenMeta.cpp

  edit: test/IRGen/c_function_pointer.sil

  edit: test/IRGen/function_metadata.swift

  edit: stdlib/public/runtime/Metadata.cpp

  edit: test/IRGen/dynamic_cast_functions.swift

  edit: include/swift/Runtime/RuntimeFunctions.def

  edit: test/IRGen/objc_block.sil


  
 

  Commit 86de71ee6dc23f7259cf11f8aec1fbad0063a660 by pyaskevich: [Runtime/ABI] Remove swift_getFunctionTypeMetadata{1-3}WithFlags


  edit: include/swift/Runtime/Metadata.h

  edit: include/swift/Runtime/RuntimeFunctions.def

  edit: test/IRGen/function_metadata.swift

  edit: docs/ABI/TypeMetadata.rst

  edit: stdlib/public/runtime/Metadata.cpp

  edit: lib/IRGen/GenMeta.cpp


  
 

  Commit 0f071848f33a75cecc1b68614cf92d052eba8752 by pyaskevich: [Runtime/ABI] NFC: Refactor function type metadata generation


  edit: lib/IRGen/GenMeta.cpp

  edit: test/IRGen/function_metadata.swift

  edit: include/swift/Runtime/RuntimeFunctions.def

  edit: stdlib/public/runtime/Metadata.cpp

  edit: include/swift/Remote/MetadataReader.h


  
 

  Commit 1eaf1f5571a14bcbc59d4b33881d93c29b04999e by milseman: [benchmark] Hook up CSVParsing to suite


  edit: benchmark/CMakeLists.txt

  edit: benchmark/single-source/CSVParsing.swift

  edit: benchmark/utils/main.swift


  
 

  Commit f7e992a3ed845b95674c54a1efc0d3da7d2382cc by milseman: [benchmark] Don't use inline(__always) in benchmarks


  edit: benchmark/single-source/CSVParsing.swift


  
 

  Commit 132075f870e3d79f6fb26dfc65bb66e4c520fdd0 by dgregor: [NFC] Move TypeDecoder into the Demangling library.


  edit: tools/swift-reflection-dump/swift-reflection-dump.cpp

  edit: stdlib/public/Reflection/TypeRefBuilder.cpp

  add: include/swift/Demangling/TypeDecoder.h

  edit: include/swift/Remote/MetadataReader.h


  
 

  Commit 7148e84099671a375ea5ee51d7c66376e47ece63 by dgregor: [Runtime] Stub out the implementation of _typeByMangledName().


  add: test/Runtime/demangleToMetadata.swift

  edit: stdlib/public/core/Misc.swift

  edit: stdlib/public/runtime/MetadataLookup.cpp


  
 

  Commit 83fd37a2d051722c1501f44a24bf4db5124036e1 by dgregor: [Runtime] Form function types based on mangled names.


  edit: include/swift/Demangling/TypeDecoder.h

  edit: stdlib/public/runtime/MetadataLookup.cpp

  edit: test/Runtime/demangleToMetadata.swift


  
 

  Commit 33f89a13447b8d7a79d9d01f4eb8056b476012ad by dgregor: [Runtime] Form metatypes based on mangled names.


  edit: test/Runtime/demangleToMetadata.swift

  edit: stdlib/public/runtime/MetadataLookup.cpp


  
 

  Commit 04a151d8a0b19446bbaa15fec35231a96430910b by dgregor: [Runtime] Form existential types and existential types based on mangled


  edit: stdlib/public/runtime/MetadataLookup.cpp

  edit: test/Runtime/demangleToMetadata.swift


  
 

  Commit ae93fd0cbcf22cea08fea08e1f5829e9360115de by mgottesman: [sil-opt] When a target triple is not specified, use the default target


  edit: tools/sil-opt/SILOpt.cpp


  
 

  Commit 5f51df4b9275bf267bd28263324ff83f1b898bc8 by dgregor: [Runtime] Add missing #include


  edit: stdlib/public/runtime/MetadataLookup.cpp


  
 

  Commit 24027067b916b8ee0d996ee1daf5f006dc59b49b by gottesmm: [benchmarks] Add some more benchmarks by our very own airspeedswift.


  add: benchmark/single

Re: [swift-dev] JIRA down

2018-01-08 Thread Mishal Shah via swift-dev 
bugs.swift.org is back online.

Please also email swift-infrastruct...@swift.org in the future. 

Thanks,
Mishal Shah

> On Jan 7, 2018, at 4:35 PM, Michael Gottesman  wrote:
> 
> The JIRA looks like it is down...
> 
> Michael

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

Re: [swift-dev] JIRA down

2018-01-08 Thread Michael Gottesman via swift-dev 
K

Sent from my iPhone

> On Jan 8, 2018, at 7:57 AM, Mishal Shah  wrote:
> 
> bugs.swift.org is back online.
> 
> Please also email swift-infrastruct...@swift.org in the future. 
> 
> Thanks,
> Mishal Shah
> 
>> On Jan 7, 2018, at 4:35 PM, Michael Gottesman  wrote:
>> 
>> The JIRA looks like it is down...
>> 
>> Michael
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - OS X (master) #1011

2018-01-08 Thread swift-ci--- via swift-dev 
New issue found!Title: Report


  
  
 
 

 [FAILURE] oss-swift-package-osx [#1011] 


  Build URL:https://ci.swift.org/job/oss-swift-package-osx/1011/
  Project:oss-swift-package-osx
  Date of build:Mon, 08 Jan 2018 10:40:40 -0600
  Build duration:1 hr 44 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 6098fa4ac4834cf207edf67ff21a6767b45cbfc2 by klorentey: [benchmark] Add word counting benchmarks


  edit: benchmark/CMakeLists.txt

  edit: benchmark/utils/main.swift

  add: benchmark/single-source/WordCount.swift


  
 

  Commit f85f836f911f12a03ebb37e8ee550fd8a9c3543d by klorentey: [benchmark] WordCount: Use CheckResults.


  edit: benchmark/single-source/WordCount.swift


  
 

  Commit 67d403f97e11cf5bab2195de06fddc1b0c58697c by klorentey: [benchmark] WordCount: Use default makeIterator()


  edit: benchmark/single-source/WordCount.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) #983

2018-01-08 Thread Ben Langmuir via swift-dev 
Maybe the libc++ on this host (Ubuntu 14.04) is too old for this feature?  All 
of our 14.04 bots are broken AFAICT.

Ben

> On Jan 5, 2018, at 7:39 PM, Michael Ilseman via swift-dev 
>  wrote:
> 
> Err, wrong version of C++ somehow?
> 
> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include/swift/ABI/TrailingObjects.h:268:19:
>  error: no member named 'is_final' in namespace 'std'
> static_assert(LLVM_IS_FINAL(BaseTy), "BaseTy must be final.");
>   ^
> 
> But the build line does specify C++14:
> 
> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/./bin/clang++
>-DCMARK_STATIC_DEFINE -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS 
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Istdlib/public/runtime 
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/stdlib/public/runtime
>  -Iinclude 
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include
>  
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/llvm/include
>  
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/include
>  
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/tools/clang/include
>  
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/llvm/tools/clang/include
>  
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/cmark/src
>  
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/cmark-linux-x86_64/src
>  -isystem /usr/include/x86_64-linux-gnu -Wno-unknown-warning-option 
> -Werror=unguarded-availability-new -fno-stack-protector -fPIC 
> -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
> -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections 
> -Werror=switch -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code 
> -Woverloaded-virtual -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -fno-sanitize=all 
> -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 -O3-UNDEBUG  
> -fno-exceptions -fno-rtti -Wglobal-constructors -Wexit-time-destructors 
> -fvisibility=hidden -D__SWIFT_CURRENT_DYLIB=swiftCore -DswiftCore_EXPORTS 
> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include
>  -target x86_64-unknown-linux-gnu -O2 -g0 -DNDEBUG  -std=c++14 -MMD -MT 
> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o
>  -MF 
> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o.d
>  -o 
> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o
>  -c 
> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/stdlib/public/runtime/ErrorObjectConstants.cpp
> 
> 
> (either way not related to my benchmark changes)
> 
> 
>> On Jan 5, 2018, at 6:29 PM, swift...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#983]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/983/ 
>> 
>> Project: oss-swift-package-linux-ubuntu-14_04
>> Date of build:   Fri, 05 Jan 2018 20:04:43 -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 
>> 
>> Changes
>> 
>> Commit aa0cec68df962b151b5c2835f1585b4649cd4961 by compnerd:
>> build: switch to C++14
>> 
>> edit: CMakeLists.txt
>> edit: cmake/modules/AddSwift.cmake
>> 
>> Commit 9bf8d773ab550500eb07d48f15d22f41c99b55ed by moiseev:
>> [stdlib] Rearrange + on RangeReplaceableCollection/Sequence once again
>> 
>> edit: stdlib/public/core/RangeReplaceableCollection.swift
>> edit: test/Constraints/bridging.swift
>> 
>> Commit 1c2954b133dcfbabcddf98409d16b17020264ec8 by milseman:
>> [benchmark] Add a CharacterProperties benchmark
>> 
>> edit: benchmark/utils/main.swift
>> add: benchmark/single-source/CharacterProperties.swift
>> add: benchmark/single-source/CharacterProperties.swift.gyb
>> edit: benchmark/CMakeLists.txt
>> 
>> Commit 0782b482b364f15741cc4a445976d8167c1a9d25 by natecook1000:
>> [stdlib] Documentation improvements
>> 
>> edit: stdlib/public/core/HashedCollections.swift.gyb
>> edit: stdlib/public/core/Map.swift
>> edit: stdlib/public/core/DoubleWidth.swift.gyb
>> edit: stdlib/public/core/Integ

Re: [swift-dev] Where is Collection defined?

2018-01-08 Thread Michael Gottesman via swift-dev 
If it is a gybed file, you need to look in the build directory. I would just do 
a find ./ for the file (without the gybed) extension in your build directory.

> On Jan 8, 2018, at 11:02 AM, Daryle Walker via swift-dev 
>  wrote:
> 
> I’ve looked around 
>  and read 
> through the various Sequence and Collection definition files. AIUI, you don’t 
> have to define both versions of Collection.subscript; the system will 
> automatically define the missing one in terms of the other. But the source 
> files I read don’t have a default implementation for either version of 
> subscript. Where is that code located?
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 
> ___
> 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 14.04 (master) #983

2018-01-08 Thread Michael Gottesman via swift-dev 
We have to do special things for 14.04. See: docs/Ubuntu14.md.

I imagine the problem could be that we need to change that special series of 
steps/update the documentation.

Michael

> On Jan 8, 2018, at 11:02 AM, Ben Langmuir via swift-dev  
> wrote:
> 
> Maybe the libc++ on this host (Ubuntu 14.04) is too old for this feature?  
> All of our 14.04 bots are broken AFAICT.
> 
> Ben
> 
>> On Jan 5, 2018, at 7:39 PM, Michael Ilseman via swift-dev 
>>  wrote:
>> 
>> Err, wrong version of C++ somehow?
>> 
>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include/swift/ABI/TrailingObjects.h:268:19:
>>  error: no member named 'is_final' in namespace 'std'
>> 
>> static_assert(LLVM_IS_FINAL(BaseTy), "BaseTy must be final.");
>>   ^
>> 
>> 
>> But the build line does specify C++14:
>> 
>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/./bin/clang++
>>-DCMARK_STATIC_DEFINE -DGTEST_HAS_RTTI=0 -D_DEBUG 
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
>> -Istdlib/public/runtime 
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/stdlib/public/runtime
>>  -Iinclude 
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include
>>  
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/llvm/include
>>  
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/include
>>  
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/tools/clang/include
>>  
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/llvm/tools/clang/include
>>  
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/cmark/src
>>  
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/cmark-linux-x86_64/src
>>  -isystem /usr/include/x86_64-linux-gnu -Wno-unknown-warning-option 
>> -Werror=unguarded-availability-new -fno-stack-protector -fPIC 
>> -fvisibility-inlines-hidden -Werror=date-time 
>> -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
>> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
>> -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections 
>> -Werror=switch -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code 
>> -Woverloaded-virtual -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -fno-sanitize=all 
>> -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 -O3-UNDEBUG  
>> -fno-exceptions -fno-rtti -Wglobal-constructors -Wexit-time-destructors 
>> -fvisibility=hidden -D__SWIFT_CURRENT_DYLIB=swiftCore -DswiftCore_EXPORTS 
>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include
>>  -target x86_64-unknown-linux-gnu -O2 -g0 -DNDEBUG  -std=c++14 -MMD -MT 
>> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o
>>  -MF 
>> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o.d
>>  -o 
>> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o
>>  -c 
>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/stdlib/public/runtime/ErrorObjectConstants.cpp
>> 
>> 
>> 
>> (either way not related to my benchmark changes)
>> 
>> 
>>> On Jan 5, 2018, at 6:29 PM, swift...@swift.org wrote:
>>> 
>>> [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#983]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/983/
>>> Project:oss-swift-package-linux-ubuntu-14_04
>>> Date of build:  Fri, 05 Jan 2018 20:04:43 -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
>>> 
>>> Changes
>>> 
>>> • Commit aa0cec68df962b151b5c2835f1585b4649cd4961 by compnerd:
>>> build: switch to C++14
>>> 
>>> • edit: CMakeLists.txt
>>> • edit: cmake/modules/AddSwift.cmake
>>> 
>>> • Commit 9bf8d773ab550500eb07d48f15d22f41c99b55ed by moiseev:
>>> [stdlib] Rearrange + on RangeReplaceableCollection/Sequence once again
>>> 
>>> • edit: stdlib/public/core/RangeReplaceableCollection.swift
>>> • edit: test/Constraints/bridging.swift
>>> 
>>> • Commit 1c2954b133dcfbabcddf98409d16b17020264ec8 by milseman:
>>> [benchmark] Add a CharacterProperties benchmark
>>> 
>>> • edit: benchmark/utils/main.swift
>>> • add: benchmark/single-source/CharacterProperties.swift
>>> • add: benchmark/single-source/CharacterProperties.swift.gyb
>>> • edit: benchmark/CMakeLists.txt
>>>

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

2018-01-08 Thread Ben Langmuir via swift-dev 
Does anyone know which C++ stdlib this configuration would use by default?  If 
this is using the system's default libstdc++ then I'm not really shocked that 
it would be missing is_final.

Ben

> On Jan 8, 2018, at 11:12 AM, Michael Gottesman  wrote:
> 
> We have to do special things for 14.04. See: docs/Ubuntu14.md.
> 
> I imagine the problem could be that we need to change that special series of 
> steps/update the documentation.
> 
> Michael
> 
>> On Jan 8, 2018, at 11:02 AM, Ben Langmuir via swift-dev 
>>  wrote:
>> 
>> Maybe the libc++ on this host (Ubuntu 14.04) is too old for this feature?  
>> All of our 14.04 bots are broken AFAICT.
>> 
>> Ben
>> 
>>> On Jan 5, 2018, at 7:39 PM, Michael Ilseman via swift-dev 
>>>  wrote:
>>> 
>>> Err, wrong version of C++ somehow?
>>> 
>>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include/swift/ABI/TrailingObjects.h:268:19:
>>>  error: no member named 'is_final' in namespace 'std'
>>> 
>>>static_assert(LLVM_IS_FINAL(BaseTy), "BaseTy must be final.");
>>>  ^
>>> 
>>> 
>>> But the build line does specify C++14:
>>> 
>>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/./bin/clang++
>>>-DCMARK_STATIC_DEFINE -DGTEST_HAS_RTTI=0 -D_DEBUG 
>>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
>>> -Istdlib/public/runtime 
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/stdlib/public/runtime
>>>  -Iinclude 
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include
>>>  
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/llvm/include
>>>  
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/include
>>>  
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/llvm-linux-x86_64/tools/clang/include
>>>  
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/llvm/tools/clang/include
>>>  
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/cmark/src
>>>  
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/build/buildbot_linux/cmark-linux-x86_64/src
>>>  -isystem /usr/include/x86_64-linux-gnu -Wno-unknown-warning-option 
>>> -Werror=unguarded-availability-new -fno-stack-protector -fPIC 
>>> -fvisibility-inlines-hidden -Werror=date-time 
>>> -Werror=unguarded-availability-new -std=c++11 -Wall -W 
>>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
>>> -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor 
>>> -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
>>> -ffunction-sections -fdata-sections -Werror=switch -Wdocumentation 
>>> -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual 
>>> -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -fno-sanitize=all 
>>> -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 -O3-UNDEBUG  
>>> -fno-exceptions -fno-rtti -Wglobal-constructors -Wexit-time-destructors 
>>> -fvisibility=hidden -D__SWIFT_CURRENT_DYLIB=swiftCore -DswiftCore_EXPORTS 
>>> -I/home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/include
>>>  -target x86_64-unknown-linux-gnu -O2 -g0 -DNDEBUG  -std=c++14 -MMD -MT 
>>> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o
>>>  -MF 
>>> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o.d
>>>  -o 
>>> stdlib/public/runtime/CMakeFiles/swiftRuntime-linux-x86_64.dir/ErrorObjectConstants.cpp.o
>>>  -c 
>>> /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-14_04/swift/stdlib/public/runtime/ErrorObjectConstants.cpp
>>> 
>>> 
>>> 
>>> (either way not related to my benchmark changes)
>>> 
>>> 
 On Jan 5, 2018, at 6:29 PM, swift...@swift.org wrote:
 
 [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#983]
 
 Build URL: 
 https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/983/
 Project:   oss-swift-package-linux-ubuntu-14_04
 Date of build: Fri, 05 Jan 2018 20:04:43 -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
 
 Changes
 
• Commit aa0cec68df962b151b5c2835f1585b4649cd4961 by compnerd:
 build: switch to C++14
 
• edit: CMakeLists.txt
• edit: cmake/modules/AddSwift.cmake
 
• Commit 9bf8d773ab550500eb07d48f15d22f41c99b55ed by moiseev:
 [stdlib] Rearrange + on RangeReplaceableCollection/Sequence once again
 
• edit: stdlib/public/core/RangeReplaceableCollection.swift
• edit: test/Constraints/bridging.swift
 
• Commit 1c2954b1

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

2018-01-08 Thread Ben Langmuir via swift-dev 
Hi Ted,

I've created a PR to revert this: https://github.com/apple/swift/pull/13804 


Updating to C++14 broke our Ubuntu 14.04 bots.  While those bots are using a 
new-enough clang, they are still using the system's libstdc++ 4.8 which doesn't 
include full C++14 support.  Since this ends up linked to the swift-runtime, 
I'm guessing it would not be practical for us to upgrade the c++ standard 
library for our Ubuntu 14.04 configuration since that would affect deployment 
of swift programs on that platform.  If that's the case, then it may be 
likewise impractical for us to support both Ubuntu 14.04 (pre-c++14 libstdc++) 
and Windows (needs c++14, IIUC).

Caveat: I am not an expert on either distributing software on Linux or Windows, 
I'm just making the bots happy.

Ben

> On Jan 5, 2018, at 5:54 PM, Ted Kremenek via swift-dev  
> wrote:
> 
> Thanks Jim.
> 
> I’ve merged the PR to enable this change.
> 
>> On Jan 5, 2018, at 2:38 PM, Jim Ingham  wrote:
>> 
>> I have no formal objections to switching lldb to C++14.  I haven't been 
>> following what is in C++14, but presumably it's purely additive?  If so then 
>> except for bugs this should be a no-op.  
>> 
>> My only reservation is it seems a little odd to adopt a "use C++14" policy 
>> for Swift lldb and not for llvm.org lldb.  Is clang going to move to C++14 
>> some time soon?  I don't remember seeing anything about this on the lldb dev 
>> lists.  If we're going to build GitHub lldb this way it would be worth 
>> raising the suggestion on the lldb-dev as well.
>> 
>> And of course, all this is dependent on lldb actually building and passing 
>> the testsuite built with C++14.  Has somebody tried that?
>> 
>> Jim
>> 
>> 
>> 
>>> On Jan 3, 2018, at 8:46 PM, Ted Kremenek via swift-lldb-dev 
>>>  wrote:
>>> 
>>> I’m pinging some folks, but not everybody is back yet.  I hope to resolve 
>>> this ASAP.
>>> 
>>> On Jan 2, 2018, at 11:33 AM, Saleem Abdulrasool  
>>> wrote:
>>> 
 On Wed, Dec 20, 2017 at 4:26 PM, Ted Kremenek  wrote:
 
 On Dec 19, 2017, 8:33 PM -0800, Ted Kremenek via swift-dev 
 , wrote:
> 
> 
> On Dec 19, 2017, at 5:08 PM, Saleem Abdulrasool  
> wrote:
> 
>> 
>> 
>>> On Dec 19, 2017, at 3:59 PM, Ted Kremenek  wrote:
>>> 
>>> 
>>> 
 On Dec 19, 2017, at 2:31 PM, Daniel Dunbar  
 wrote:
 
 
 
> On Dec 19, 2017, at 2:27 PM, Ted Kremenek  wrote:
> 
> Fair enough.
> 
> We care about swiftc and llbuild building a variety of platforms 
> today — FreeBSD, Rasberry Pi, etc.  My impression is that C++14 is 
> generally supported by both (a) the mininum versions of the 
> distributions we support today and (b) the current versions of the 
> platforms we’d like to expand Swift to in the future.  Does that 
> sound right?  I suspect you went through the same kind of reasoning 
> with llbuild.
 
 It sounds reasonable, but to be honest I never did an audit of what 
 platforms supported C++14.
>>> 
>>> Interesting.  Was that not a concern when that choice was made for 
>>> llbuild, or was the context different?
>>> 
 
 I do think that we could always use the Clang++ we build as part of 
 Swift to build Swift itself. By that logic, it seems reasonable to 
 expect we could always have C++14 support, although it does mean that 
 porters would need modern Clang to support their platform. However, 
 that is likely largely a prerequisite for Swift to work as well.
>>> 
>>> That’s a significant change to make just to get C++14 support 
>>> guaranteed, and (I believe) would have a non-trivial impact on those 
>>> using development environments that expect to use the Clang bundled 
>>> with them to build projects.
>> 
>> Agreed.  However, the current supported platforms already support this 
>> minimum.  I think that future platforms will need to provide that 
>> anyways.  If the system doesn’t have a modern toolchain available, I 
>> suspect that it already would not have C++11 available either.  In such 
>> a scenario, they need to provide a newer toolchain, and so the 
>> difference there is minimal as we already require C++11.
> 
> OK, I’m convinced.
> 
> I want to hold off for a tiny bit just to see if anyone else has any 
> commentary on this thread before we make a change. 
 
 We’d also need to make this change on the LLDB side, and I realize now 
 that a few people I’d like to weigh in are on vacation until the holidays. 
  How about we pick this up immediately in the new year once it’s clear 
 everyone that should weigh in has had a chance to do so.
 
 Just a post-holiday bump to bring this back up :-).  I'd like to get this 
 merged so that th

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

2018-01-08 Thread Jordan Rose via swift-dev 
Thanks for the info, Alan!

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

Jordan


> On Jan 5, 2018, at 17:22, Alan Zeino  wrote:
> 
> Hey Jordan,
> 
> We tend to have to do major migrations of our Swift codebase, so I might be 
> able to help. For context at last count (February 2017 was the last time I 
> checked) we had 1.4m lines of Swift across our apps.
> 
> This means that when we migrate, we tend to have to chose the smallest 
> possible scope for necessity reasons. For example when Swift 3.0 was 
> available, we went to 2.3 first and it took a few months before we were on 
> 3.0.
> 
> When 4.0 was available we went to 3.2 first (with many, many #if statements) 
> and it took a few months before we went to 4.0; which we did by landing many 
> months worth of #if statements to switch between 3.2/4.0 right up until the 
> 4.0 switch.
> 
> To answer the last question first, the larger the codebase the more likely 
> you will be to want to do your swift migrations piecemeal with many small 
> changes until you can build a fully–compatible–with–the–new–version 
> executable. 
> 
> This is even more important for open source libraries, who struggle with 
> either having entire forked branches for swift versions (which means fixes 
> sometimes have to be committed to more than one branch), or many #if 
> statements littered in their codebase.
> 
> As for this issue, the main improvement here would be to be able to use > and 
> < in these statements. The first time I had to do one of these large 
> migrations I found it more difficult to reason and read the cases where you 
> had to do this:
> 
> #if !swift(>=3.2)
> /* code */
> #endif
> 
> …when it would be a little easier to grok what’s happening if it were 
> possible to do this:
> 
> #if swift(<3.2)
> /* code */
> #endif
> 
> In your example, it could be a little simpler if the unary requirement here 
> was relaxed (though I’m sure there’s a good reason why it’s the way it is!).
> 
> If I’m reading this correctly (sorry if my interval notation is wrong it’s 
> been a while) the bounds here would be:
> 
> // n >= 4.1
> // or
> // 3.3 >= n < 4.0
> #if swift(>=4.1) || (swift(>=3.3) && !swift(>=4.0))
> print("asdf")
> #endif
> 
> But if it were possible to use > and <, it would read:
> 
> #if (swift(>=3.3) && swift(<4.0)) || swift(>=4.1)
> print("asdf")
> #endif
> 
> (I don’t know why Mail.app is making the < above look like a less than or 
> equal to symbol ≤)
> 
> I find it a little easier to read it this way, because the negation with ! 
> changes my thinking from ‘interval’ to ‘interval plus… not something in this 
> interval’.
> 
> Overall, while I think that most people here know that these compatibility 
> versions are really ‘the old code built with the latest compiler’, most tend 
> to ignore this fact so we try not to worry about it much and trust the 
> compiler a lot here to do the right thing. We also try to only support one 
> Xcode version at Uber at a time (and so one swift compiler toolchain), which 
> tends to narrow the scope of the ‘what version of Swift will this code 
> compile for’ question.
> 
> Hope this helps!
> 
> Alan
> 
> 
>> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-build-dev 
>> mailto:swift-build-...@swift.org>> wrote:
>> 
>> Hi, all. Swift 4.1 is off on its own branch and going well, but we never 
>> quite came up with an answer for a particular problem developers might have: 
>> "am I running a Swift 4.1 compiler?".
>> 
>> #if swift(>=3.2)
>> // Swift 3.2 (4.0 in compatibility mode)
>> // Swift 3.3 (4.1 in compatibility mode)
>> // Swift 4.0
>> // Swift 4.1
>> #endif
>> 
>> #if swift(>=3.3)
>> // Swift 3.3 (4.1 compatibily mode)
>> // Swift 4.0
>> // Swift 4.1
>> // this one is probably not very useful
>> #endif
>> 
>> #if swift(>=4.0)
>> // Swift 4.0
>> // Swift 4.1
>> #endif
>> 
>> #if ???
>> // Swift 3.3
>> // Swift 4.1
>> #endif
>> 
>> I don't think this is going to come up a lot, but given that we do have 
>> changes to the standard library and to the language, I can see people 
>> wanting it. Right now the only way to do it is the rather unwieldy:
>> 
>> #if swift(>=4.1) || (swift(>=3.3) && !swift(>=4.0))
>> print("new")
>> #else
>> print("old")
>> #endif
>> 
>> Do we need something better here, or do you think people will be okay with 
>> this? I'm realizing I don't really know how many people try to keep their 
>> libraries working across Swift versions and run into compatibility issues. 
>> 
>> (Strictly speaking this problem is already present with Swift 4.0.2 with 
>> 3.2.2 compatibility mode, but that's much less likely to come up.)
>> 
>> Jordan
>> ___
>> swift-bu

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

2018-01-08 Thread Jordan Rose via swift-dev 


> On Jan 5, 2018, at 23:43, David Hart  wrote:
> 
> I was really surprised when I saw that the release of 4.0 introduced this 3.2 
> version to mean “the 4.0 compiler running in 3.1 compatibility mode”. So of 
> course, I’m even more surprised to see a new 3.3 version. I find it very 
> counter-intuitive. It also means we will continue to have to increment all 
> previous Swift language versions from now on whenever a new compiler is 
> released:
> 
> Swift 3.4 = Swift 5 compiler in Swift 3 compatibility mode
> Swift 4.2 = Swift 5 compiler in Swift 4 compatibility mode
> Swift 3.5 = Swift 5.1 compiler in Swift 3 compatibility mode
> Swift 4.3 = Swift 5.1 compiler in Swift 4 compatibility mode

The most common use of `#if swift` is `#if swift(>=4.0)`, to check for things 
that actually changed in Swift 4 and not in the 3 compatibility modes. I agree 
that the "subtraction" going on here is very weird, though, and of course it 
leads to this problem when you're actually trying to test the compiler release 
rather than the language mode.

(Your predictions are right, though, if nothing else here changes: 
https://github.com/apple/swift/pull/13767)


> I have the impression that what we really need is a different directive to 
> test for the compiler version:
> 
> #if compiler(>=4.1)
> // Swift 3.3
> // Swift 4.1
> #endif

That certainly seems reasonable. If that's the direction we want to go, the 
next question is whether it's important enough to put through swift-evolution 
in time for Swift 4.1, or whether it could wait for Swift 5. (I'd also love if 
someone else shepherded that proposal and implementation through. I could put 
it up as a StarterBug/StarterProposal.)

Jordan


> 
> On 6 Jan 2018, at 01:19, Jordan Rose via swift-build-dev 
> mailto:swift-build-...@swift.org>> wrote:
> 
>> Hi, all. Swift 4.1 is off on its own branch and going well, but we never 
>> quite came up with an answer for a particular problem developers might have: 
>> "am I running a Swift 4.1 compiler?".
>> 
>> #if swift(>=3.2)
>> // Swift 3.2 (4.0 in compatibility mode)
>> // Swift 3.3 (4.1 in compatibility mode)
>> // Swift 4.0
>> // Swift 4.1
>> #endif
>> 
>> #if swift(>=3.3)
>> // Swift 3.3 (4.1 compatibily mode)
>> // Swift 4.0
>> // Swift 4.1
>> // this one is probably not very useful
>> #endif
>> 
>> #if swift(>=4.0)
>> // Swift 4.0
>> // Swift 4.1
>> #endif
>> 
>> #if ???
>> // Swift 3.3
>> // Swift 4.1
>> #endif
>> 
>> I don't think this is going to come up a lot, but given that we do have 
>> changes to the standard library and to the language, I can see people 
>> wanting it. Right now the only way to do it is the rather unwieldy:
>> 
>> #if swift(>=4.1) || (swift(>=3.3) && !swift(>=4.0))
>> print("new")
>> #else
>> print("old")
>> #endif
>> 
>> Do we need something better here, or do you think people will be okay with 
>> this? I'm realizing I don't really know how many people try to keep their 
>> libraries working across Swift versions and run into compatibility issues. 
>> 
>> (Strictly speaking this problem is already present with Swift 4.0.2 with 
>> 3.2.2 compatibility mode, but that's much less likely to come up.)
>> 
>> Jordan
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-build-dev 
>> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - OS X (master) #1012

2018-01-08 Thread swift-ci--- via swift-dev 
New issue found!Title: Report


  
  
 
 

 [FAILURE] oss-swift-package-osx [#1012] 


  Build URL:https://ci.swift.org/job/oss-swift-package-osx/1012/
  Project:oss-swift-package-osx
  Date of build:Mon, 08 Jan 2018 16:30:08 -0600
  Build duration:2 hr 26 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 deab78fba06c027b3077433ae6215634ca3401c2 by daniel_dunbar: [BuildSystem] Add support for a directory structure tracking node.


  edit: docs/buildsystem.rst

  edit: include/llbuild/BuildSystem/BuildNode.h

  add: tests/BuildSystem/Build/directory-tree-structure-signatures.llbuild

  edit: include/llbuild/BuildSystem/BuildKey.h

  edit: lib/BuildSystem/BuildKey.cpp

  edit: tests/BuildSystem/Build/directory-tree-signatures.llbuild

  edit: lib/BuildSystem/BuildSystem.cpp

  edit: products/libllbuild/include/llbuild/buildsystem.h

  edit: include/llbuild/BuildSystem/BuildValue.h

  edit: lib/BuildSystem/ExternalCommand.cpp

  edit: lib/BuildSystem/BuildNode.cpp

  edit: products/libllbuild/BuildSystem-C-API.cpp


  
 

  Commit 95e1c013d8b68c94875ee8661df60b2c1388d905 by daniel_dunbar: [BuildSystem] Update a couple places for new node type.


  edit: lib/BuildSystem/BuildSystemFrontend.cpp

  edit: lib/BuildSystem/BuildValue.cpp


  
 

  


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

[swift-dev] Suggestions for open projects (GSoC 2018)

2018-01-08 Thread Anna Zaks via swift-dev 
Dear Swift Developers,

The Swift project is applying to participate in Google Summer of Code 2018. 
During GSoC, students get a mentor from the open source community and spend 3 
months working on a project.

In preparation for the application, I am looking for open project ideas as well 
as mentors. Once I have the list, I’ll post it on the project website. The 
prospective GSoC students as well as any other new contributors will be able to 
use it as a source of inspiration. 

If you have a project idea and/or would like to volunteer as a mentor, please 
send me the following information by January 15th:
The project title/description
A more detailed description of the project (2-5 sentences)
Expected outcomes of the project or benefits it brings
Possible mentors
An easy, medium, or hard rating
Thank you!
Anna

P.S.
This website has more information about how to construct the project ideas list 
for GSoC:
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

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

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

2018-01-08 Thread Chris Lattner via swift-dev 

> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev  
> wrote:
> 
> Hi, all. Swift 4.1 is off on its own branch and going well, but we never 
> quite came up with an answer for a particular problem developers might have: 
> "am I running a Swift 4.1 compiler?”.

I agree, this is getting bad.  Ted mentioned that something like __has_feature 
in clang is probably the best way to go, so people could check the specific 
thing they care about, instead of a set of global version numbers.

Another thing that could help is something along the lines of:

#if swift_stdlib(>=5.0)

which would presumably be active in any language mode when the 5.0 standard 
library is available.  It would be even better to use a generalized 
availability system for this: the standard library version could be treated 
just like Foundation versions are handled, for example.

-Chris


> 
> #if swift(>=3.2)
> // Swift 3.2 (4.0 in compatibility mode)
> // Swift 3.3 (4.1 in compatibility mode)
> // Swift 4.0
> // Swift 4.1
> #endif
> 
> #if swift(>=3.3)
> // Swift 3.3 (4.1 compatibily mode)
> // Swift 4.0
> // Swift 4.1
> // this one is probably not very useful
> #endif
> 
> #if swift(>=4.0)
> // Swift 4.0
> // Swift 4.1
> #endif
> 
> #if ???
> // Swift 3.3
> // Swift 4.1
> #endif
> 
> I don't think this is going to come up a lot, but given that we do have 
> changes to the standard library and to the language, I can see people wanting 
> it. Right now the only way to do it is the rather unwieldy:
> 
> #if swift(>=4.1) || (swift(>=3.3) && !swift(>=4.0))
> print("new")
> #else
> print("old")
> #endif
> 
> Do we need something better here, or do you think people will be okay with 
> this? I'm realizing I don't really know how many people try to keep their 
> libraries working across Swift versions and run into compatibility issues. 
> 
> (Strictly speaking this problem is already present with Swift 4.0.2 with 
> 3.2.2 compatibility mode, but that's much less likely to come up.)
> 
> Jordan
> ___
> 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 4.1 or Swift 3.3"

2018-01-08 Thread Jordan Rose via swift-dev 


> On Jan 8, 2018, at 17:18, Chris Lattner  wrote:
> 
> 
>> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev > > wrote:
>> 
>> Hi, all. Swift 4.1 is off on its own branch and going well, but we never 
>> quite came up with an answer for a particular problem developers might have: 
>> "am I running a Swift 4.1 compiler?”.
> 
> I agree, this is getting bad.  Ted mentioned that something like 
> __has_feature in clang is probably the best way to go, so people could check 
> the specific thing they care about, instead of a set of global version 
> numbers.
> 
> Another thing that could help is something along the lines of:
> 
>   #if swift_stdlib(>=5.0)
> 
> which would presumably be active in any language mode when the 5.0 standard 
> library is available.  It would be even better to use a generalized 
> availability system for this: the standard library version could be treated 
> just like Foundation versions are handled, for example.

Yep, though there's a difference between compile-time availability (which is 
what `#if swift` and `@available(swift, …)` check) and run-time availability 
(which is what `@available(macOS, …)` and `#available` check). Thus far, 
availability of features in the standard library has been a compile-time check, 
but as soon as the standard library starts shipping with Apple's OS, it becomes 
a run-time check. The conclusion I draw is that there's a good chance we'll end 
up with different solutions for checking compiler versions vs. checking 
run-time versions.

(And then there's another thing people have asked for, which is statically 
checking SDK versions. Thus far they've been able to emulate that with `#if 
swift` because we've shipped a new Swift with every new Apple SDK, but it's 
still potentially an interesting feature.)

Jordan

___
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) #2255

2018-01-08 Thread Yan Li via swift-dev 
Hi all,

I have taken a look at the failure, looks like its not related to the
changes in NSAttributedString.

On Tue, Jan 9, 2018 at 4:19 PM  wrote:

> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2255]
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2255/
> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build: Mon, 08 Jan 2018 21:00:59 -0600
> 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
>   
> 
>
> Tests:
> Name: *Swift(linux-x86_64)*
> Failed: 0 test(s), Passed: 10157 test(s), Total: 10157 test(s)
> Name: *Swift-Unit*
> Failed: 0 test(s), Passed: 506 test(s), Total: 506 test(s)
>
> Changes
>
>- Commit *eb220dd130d532405f3f3a6eedf35679a09238da* by *eyeplum:*
>
>implement attributes mutating methods
>- *edit*: Foundation/NSAttributedString.swift
>
>- Commit *db3aeaa6ed9a82711e7e037d25ba42d1b660754c* by *eyeplum:*
>
>add tests
>- *edit*: Foundation/NSAttributedString.swift
>   - *edit*: TestFoundation/TestNSAttributedString.swift
>
>- Commit *22654b072e34a4141cfd6cb6d792c26feea39c8c* by *eyeplum:*
>
>implement more methods by mapping CFAttributedString functions calls
>- *edit*: Foundation/NSAttributedString.swift
>
>- Commit *1c5b0074f82c79152c86e788755098ff0a8d04aa* by *eyeplum:*
>
>implement substring/insert/append
>- *edit*: Foundation/NSAttributedString.swift
>
>- Commit *722ed7271396065f94603fb3f4b191df3b5f467a* by *eyeplum:*
>
>add tests
>- *edit*: Foundation/NSAttributedString.swift
>   - *edit*: TestFoundation/TestNSAttributedString.swift
>
>- Commit *df180849e954da81c549716d32e704a812a19ed6* by *eyeplum:*
>
>implement remaining methods and NS[Mutable]Copying
>- *edit*: Foundation/NSAttributedString.swift
>
>- Commit *3e541f90bc6c8f8cd618ea5396c08a5efeb36e05* by *eyeplum:*
>
>add tests
>- *edit*: TestFoundation/TestNSAttributedString.swift
>   - *edit*: Foundation/NSAttributedString.swift
>
>- Commit *f43e647d0fc3cb42df9f760fe800852d149348a4* by *eyeplum:*
>
>override initializers in mutable attr string and add tests
>- *edit*: TestFoundation/TestNSAttributedString.swift
>   - *edit*: Foundation/NSAttributedString.swift
>
>- Commit *ec1b067403c0bee5c71ad8009072d04f5b0a250f* by *eyeplum:*
>
>move dummy attr str creating from mutableCopy to
>init(attributedString:)
>- *edit*: Foundation/NSAttributedString.swift
>
>- Commit *fba70bbe1881eab7718f615b880baa0bd1779875* by *eyeplum:*
>
>cleanup tests
>- *edit*: TestFoundation/TestNSAttributedString.swift
>
>
>

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

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

2018-01-08 Thread Chris Lattner via swift-dev 
On Jan 8, 2018, at 5:26 PM, Jordan Rose via swift-dev  
wrote:
>> On Jan 8, 2018, at 17:18, Chris Lattner > > wrote:
>>> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev >> > wrote:
>>> 
>>> Hi, all. Swift 4.1 is off on its own branch and going well, but we never 
>>> quite came up with an answer for a particular problem developers might 
>>> have: "am I running a Swift 4.1 compiler?”.
>> 
>> I agree, this is getting bad.  Ted mentioned that something like 
>> __has_feature in clang is probably the best way to go, so people could check 
>> the specific thing they care about, instead of a set of global version 
>> numbers.
>> 
>> Another thing that could help is something along the lines of:
>> 
>>  #if swift_stdlib(>=5.0)
>> 
>> which would presumably be active in any language mode when the 5.0 standard 
>> library is available.  It would be even better to use a generalized 
>> availability system for this: the standard library version could be treated 
>> just like Foundation versions are handled, for example.
> 
> Yep, though there's a difference between compile-time availability (which is 
> what `#if swift` and `@available(swift, …)` check) and run-time availability 
> (which is what `@available(macOS, …)` and `#available` check). Thus far, 
> availability of features in the standard library has been a compile-time 
> check, but as soon as the standard library starts shipping with Apple's OS, 
> it becomes a run-time check. The conclusion I draw is that there's a good 
> chance we'll end up with different solutions for checking compiler versions 
> vs. checking run-time versions.
> 
> (And then there's another thing people have asked for, which is statically 
> checking SDK versions. 

I think your second paragraph answers the issue you observe in the first 
paragraph.  You’re right that we have #available and @available, but neither of 
them are the thing we need here.  We need a third thing that allows people to 
conditionally build (#ifdef-style) based on build time information.

I don’t see the OS or the standard library as being special here.  The same 
thing is true for source packages - a dependent package should be able to write 
conditional code to allow it to work with different versions of some other 
package it depends on.  I outlined this sort of stuff in this ancient doc:
https://github.com/apple/swift/blob/master/docs/proposals/archive/ProgramStructureAndCompilationModel.rst#sdks
 



> Thus far they've been able to emulate that with `#if swift` because we've 
> shipped a new Swift with every new Apple SDK, but it's still potentially an 
> interesting feature.)


Sure, this is just a way of saying that people are already doing this - so we 
might as well make it nice and consistent.  Also, given that Swift is cross 
platform, it would be nice to have a solution that works in other environments 
too.

-Chris

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