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

[Slava Pestov via swift-dev]

That test failure is my fault. Sorry about that, I’ll fix it shortly. In the 
mean time you can do a smoke test instead of a full test and it won’t run i386 
tests.

Slava

> On Jan 11, 2018, at 2:51 PM, Itai Ferber  wrote:
> 
> Hi Doug, Slava,
> 
> Looks like this is still an issue — just hit this on 
> https://github.com/apple/swift/pull/13879 
> 
> Does this failure look familiar to either of you?
> 
> — Itai
> 
> On 11 Jan 2018, at 7:12, swift-ci--- via swift-dev wrote:
> 
> [FAILURE] oss-swift-package-osx [#1021]
> 
> Build URL:https://ci.swift.org/job/oss-swift-package-osx/1021/ 
> 
> Project:  oss-swift-package-osx
> Date of build:Thu, 11 Jan 2018 06:39:53 -0600
> Build duration:   2 hr 32 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> 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 005267f2b087f1db34688670b5e273015dcdd2f2 by spestov:
> SIL: Remove obsolete comments from FormalLinkage.h
> 
> edit: include/swift/SIL/FormalLinkage.h
> 
> Commit 3dae007465eca11d6d202ed411579ffc86826f2a by spestov:
> IRGen: Remove FieldAccess::NonConstantIndirect
> 
> edit: lib/IRGen/GenClass.cpp
> edit: lib/IRGen/GenDecl.cpp
> edit: lib/IRGen/GenMeta.cpp
> edit: lib/TBDGen/TBDGen.cpp
> edit: lib/IRGen/IRGenModule.h
> edit: lib/IRGen/IRGenMangler.h
> edit: lib/IRGen/Linking.cpp
> edit: include/swift/IRGen/Linking.h
> edit: lib/IRGen/StructLayout.h
> edit: lib/IRGen/GenKeyPath.cpp
> 
> Commit d134529e5491cce10b3af76e98356952e2c472f9 by spestov:
> IRGen: Field offset symbols of resilient classes have hidden linkage
> 
> edit: test/IRGen/class_resilience.swift
> edit: lib/IRGen/GenDecl.cpp
> 
> Commit 065d18921f57d8e18637a6b9dd6d152806e5ed55 by spestov:
> IRGen: Test protocol dispatch thunk for a throwing method requirement
> 
> edit: test/IRGen/protocol_resilience_thunks.swift
> 
> Commit df10c8659b19ea0bf6ff34d95c87db4e3b4b480a by spestov:
> SILOptimizer: Fix mandatory inlining bug with resilience
> 
> edit: lib/SILOptimizer/Mandatory/MandatoryInlining.cpp
> add: test/SILOptimizer/mandatory_inlining_resilience.sil
> 
> Commit 992da7494ba8a0086f34e09b9dbd61ca6fb46d5f by spestov:
> SIL: Remove some uses of LValueType
> 
> edit: lib/SIL/TypeLowering.cpp
> 
> Commit 43aebc832e0a9c596d89a77c65b894b8ac570c95 by github:
> Revert "IUO: Add support for non-subscript dynamic lookup."
> 
> edit: lib/Sema/ConstraintLocator.h
> edit: lib/Sema/ConstraintSystem.cpp
> edit: lib/Sema/CSApply.cpp
> edit: lib/Sema/ConstraintSystem.h
> edit: lib/Sema/ConstraintLocator.cpp
> 
> Commit 2c86f918def205b9414d89ee7967360ef56fc88f by dgregor:
> [Runtime] Add tests for demanling never-before-seen types to metadata.
> 
> edit: test/Runtime/demangleToMetadata.swift
> 
> Commit 35268902332dd3ac0b746f863c9517bc2a96c1cb by spestov:
> TypeReconstruction: Fix reconstruction of InOutType
> 
> edit: test/IDE/reconstruct_type_from_mangled_name.swift
> edit: lib/IDE/TypeReconstruction.cpp
> 
> Commit 759f4c3a2cb1531958465058849fabdb4e09e628 by dgregor:
> [Runtime] Skip Objective-C type records when looking for types.
> 
> edit: test/Runtime/demangleToMetadataObjC.swift
> edit: stdlib/public/runtime/ProtocolConformance.cpp
> edit: stdlib/public/runtime/MetadataLookup.cpp
> 
> Commit d104a7aec405177384a4cf92a101b99297183fed by spestov:
> [Swift] Update for mangler API change
> 
> edit: source/Symbol/SwiftASTContext.cpp
> 
> ___
> 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] "available externally" vs build time

[Slava Pestov via swift-dev]

> On Jan 4, 2018, at 1:08 PM, Erik Eckstein  wrote:
> 
> 
> 
>> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev  
>> wrote:
>> 
>> 
>> 
>>> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev 
>>>  wrote:
>>> 
>>> Folks working on the SIL optimizer, particularly those interested in faster 
>>> builds:
>>> 
>>> If I understand the SIL optimizer correctly, it seems that when the current 
>>> program references an external symbol declared as @_inlinable, that 
>>> SILModule::linkFunction eagerly deserializes the @_inlinable body and splat 
>>> it into the current module.  That SIL function exists in the current 
>>> module, gets optimized, inlined, etc along with existing functions, then 
>>> gets dropped on the floor at IRGen time if it still exists.
>> 
>> I’ve noticed this too, but haven’t had time to look at it yet.
>> 
>>> If this is true, this seems like an incredibly wasteful approach, 
>>> particularly given how many @_inlinable functions exist in the standard 
>>> library, and particularly for programs that have lots of small files.  Try 
>>> this:
>> 
>> I agree!
>> 
>>> 1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: 
>>> it deserializes the referenced function (MandatoryInlining.cpp:384) and 
>>> *then* checks to see if the callee is @_transparent.  Would it make sense 
>>> to change this to check for @_transparent first (which might require a SIL 
>>> change?), and only deserialize if so?
>> 
>> This seems like a clear win.
> 
> +1
> 
> It should be a trivial change and I’m wondering why we haven’t done this yet.
> I filed https://bugs.swift.org/browse/SR-6697 
> <https://bugs.swift.org/browse/SR-6697>
> 
>> 
>>> 2. The performance inliner will have the same issue after this, and 
>>> deserializing the bodies of all inlinable referenced functions is 
>>> unavoidable for it.  However, we don’t have to copy the SIL into the 
>>> current module and burn compile time by subjecting it to all of the 
>>> standard optimizations again.  Would it make sense to put deserialized 
>>> function bodies into a separate SIL module, and teach the (few) IPA/IPO 
>>> optimizations about this fact?  This should be very straight-forward to do 
>>> for all of the optimizations I’m aware of.
>> 
>> What if we deserialized function bodies lazily instead of deserializing the 
>> transitive closure of all serialized functions referenced from a function?
> 
> Well, with our pass pipeline architecture I suspect it will not make a 
> difference. We process functions bottom-up. For example, the performance 
> inliner optimizes the callee first before trying to inline it (because it 
> influences the inlining decision). So the performance inliner actually visits 
> the whole call tree.

However, imagine if f() calls g() which calls h() which calls i(). If all four 
of f, g, h, and i are serialized, then we will deserialize them all as soon as 
anything references f(). But the performance inliner might choose to inline 
f(), and not g(), therefore the deserialization of h() and i() is unnecessary.

Or am I misunderstanding the issue here?

> 
>>> Would it make sense to put deserialized function bodies into a separate SIL 
>>> module
> 
> We serialize early in the pipeline, i.e. serialized functions are not (fully) 
> optimized. And at least the performance inliner needs functions to be 
> optimized to make good inlining decisions. So it makes sense to also optimize 
> deserialized functions.
> 
> That said, I’m sure there is still potential for improvements. For example, 
> we could exclude deserialized generic functions from optimizations, because 
> we only inline specialized functions.
> 
>> 
>> Slava
>> 
>>> 
>>> I haven’t done any measurements, but this seems like it could be a big 
>>> speedup, particularly for programs containing a bunch of relatively small 
>>> files and not using WMO.
>>> 
>>> -Chris
>>> 
>>> ___
>>> swift-dev mailing list
>>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev 
>>> <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> <https://lists.swift.org/mailman/listinfo/swift-dev>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 2. Swift Source Compatibility Suite (master) #1014

[Slava Pestov via swift-dev]

> On Jan 3, 2018, at 7:36 PM, Vedant Kumar  wrote:
> 
>> 
>> On Jan 3, 2018, at 7:34 PM, Mark Lacey > > wrote:
>> 
>> 
>> 
>>> On Jan 3, 2018, at 7:31 PM, Vedant Kumar >> > wrote:
>>> 
 
 On Jan 3, 2018, at 7:23 PM, Mark Lacey >>> > wrote:
 
 
 
> On Jan 3, 2018, at 7:18 PM, Vedant Kumar  > wrote:
> 
> This is a bit surprising, since I wouldn't expect this suite of tests to 
> stress the code coverage logic.
> 
> How were you able to determine that the #13597 caused the break? 
 
 I’m seeing this in the failing builds:
 
 Assertion failed: (std::all_of(Mappings.begin(), Mappings.end(), [](const 
 SILCoverageMap &M) { return M.hasSymtabEntry(); }) && "Missing symtab 
 entry for coverage mapping"), function emitCoverageMapping, file 
 /Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/swift/lib/IRGen/GenCoverage.cpp,
  line 53.
>>> 
>>> I added this assert as a debugging tool, with plans on making it a 
>>> defensive measure. I.e, we'd use the check to avoid emitting broken 
>>> coverage mapping data. Instead of reverting, it might be easier to finish 
>>> that up. Wdyt?
>> 
>> Is that something you can do quickly?
> 
> I think so, I should have it done tonight. If it's looking unlikely, I can 
> finish up the revert of #13597. Is that ok?
> 
> vedant

Why don’t you just temporarily disable the assertion?

Slava

> 
>> 
>> It’s blocking PR testing for source compatibility, which means we get no 
>> coverage for people that want to run those tests until this is fixed or 
>> reverted.
>> 
>> Mark
>> 
>>> 
>>> 
 
> I'm having a hard time understanding what the logs mean. For example, I 
> see this failure, but I'm not sure how my change relates to it:
 
 It’s non-obvious, but the easiest thing to do is download the build 
 artifacts via a couple clicks from 
 https://ci.swift.org/job/swift-master-source-compat-suite/1014/ 
 , and 
 then look at the logs named FAIL_*.
>>> 
>>> Thanks, I see the failures now.
>>> 
>>> 
 
> 
> FAIL: JSQDataSourcesKit, 3.0, b764e3, JSQDataSourcesKit-iOS, 
> generic/platform=iOS, ExecuteCommandFailure(command="sandbox-exec -f 
> /Users/buildnode/jenkins/workspace-private/swift-source-compat-suite-sandbox/sandbox_xcodebuild.sb
>  xcodebuild clean build -project 
> /Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/project_cache/JSQDataSourcesKit/JSQDataSourcesKit.xcodeproj
>  -target JSQDataSourcesKit-iOS -destination generic/platform=iOS 
> SYMROOT=/Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/project_cache/JSQDataSourcesKit/build
>  -sdk 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.2.sdk
>  CODE_SIGN_IDENTITY= CODE_SIGNING_REQUIRED=NO ENABLE_BITCODE=NO 
> INDEX_ENABLE_DATA_STORE=NO GCC_TREAT_WARNINGS_AS_ERRORS=NO 
> SWIFT_TREAT_WARNINGS_AS_ERRORS=NO 'OTHER_SWIFT_FLAGS=$(OTHER_SWIFT_FLAGS) 
> -swift-version 3' -configuration Release 
> SWIFT_EXEC=/Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/build/compat_macos/install/toolchain/usr/bin/swiftc
>  SWIFT_VERSION=3", returncode=65)
> Can I reproduce the issue with `build-script -t`?
 
 You should be able to reproduce by building and then following the 
 instructions here to run a single project build: 
 https://github.com/apple/swift-source-compat-suite/blob/master/README.md 
 
>>> Thanks.
>>> 
>>> vedant
>>> 
 
 Mark
 
 
> 
> thanks,
> vedant
> 
>> On Jan 3, 2018, at 7:10 PM, Mark Lacey > > wrote:
>> 
>> Vedant, this appears to be a result of your changes.
>> 
>> I’ve opened https://github.com/apple/swift/pull/13709 
>>  to revert the later clean-up 
>> change which appears to be required before it will be possible to revert 
>> the change below.
>> 
>> Mark
>> 
>>> On Jan 3, 2018, at 6:06 PM, swift...@swift.org 
>>>  wrote:
>>> 
>>> [FAILURE] swift-master-source-compat-suite [#1014]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/swift-master-source-compat-suite/1014/ 
>>> 
>>> Project:swift-master-source-compat-suite
>>> Date of build:  Wed, 03 Jan 2018 16:40:37 -0600
>>> Build duration: 3 hr 26 min
>>> 
>>> Changes
>>> 
>>> Commit 5307f5d2ecdbcab62ae203ef21d2e1b95e2723f7 by dgregor:
>>> [Runtime] Add "reserved

Re: [swift-dev] "available externally" vs build time

[Slava Pestov via swift-dev]

> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev 
>  wrote:
> 
> Folks working on the SIL optimizer, particularly those interested in faster 
> builds:
> 
> If I understand the SIL optimizer correctly, it seems that when the current 
> program references an external symbol declared as @_inlinable, that 
> SILModule::linkFunction eagerly deserializes the @_inlinable body and splat 
> it into the current module.  That SIL function exists in the current module, 
> gets optimized, inlined, etc along with existing functions, then gets dropped 
> on the floor at IRGen time if it still exists.

I’ve noticed this too, but haven’t had time to look at it yet.

> If this is true, this seems like an incredibly wasteful approach, 
> particularly given how many @_inlinable functions exist in the standard 
> library, and particularly for programs that have lots of small files.  Try 
> this:

I agree!

> 1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: it 
> deserializes the referenced function (MandatoryInlining.cpp:384) and *then* 
> checks to see if the callee is @_transparent.  Would it make sense to change 
> this to check for @_transparent first (which might require a SIL change?), 
> and only deserialize if so?

This seems like a clear win.

> 2. The performance inliner will have the same issue after this, and 
> deserializing the bodies of all inlinable referenced functions is unavoidable 
> for it.  However, we don’t have to copy the SIL into the current module and 
> burn compile time by subjecting it to all of the standard optimizations 
> again.  Would it make sense to put deserialized function bodies into a 
> separate SIL module, and teach the (few) IPA/IPO optimizations about this 
> fact?  This should be very straight-forward to do for all of the 
> optimizations I’m aware of.

What if we deserialized function bodies lazily instead of deserializing the 
transitive closure of all serialized functions referenced from a function?

Slava

> 
> I haven’t done any measurements, but this seems like it could be a big 
> speedup, particularly for programs containing a bunch of relatively small 
> files and not using WMO.
> 
> -Chris
> 
> ___
> 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] Build standard library failed in debug

[Slava Pestov via swift-dev]

This is an error compiling Clang. Which branch/tag are you building?

Slava

> On Dec 24, 2017, at 6:56 PM, Meiliang Dong via swift-dev 
>  wrote:
> 
>  Hi swift developers, I get a compile error when try to build standard 
> library in debug with command:`$ swift/utils/build-script --release-debuginfo 
> --debug-swift-stdlib --xcode -c`.The detail error as follow:
> 
> ```
> The following build commands failed:
>   CompileC 
> /Users/dongmeiliang/Documents/swift-source/build/Xcode-RelWithDebInfoAssert+stdlib-DebugAssert/llvm-macosx-x86_64/tools/clang/utils/TableGen/LLVM.build/RelWithDebInfo/clang-tblgen.build/Objects-normal/x86_64/ClangASTNodesEmitter.o
>  tools/clang/utils/TableGen/ClangASTNodesEmitter.cpp normal x86_64 c++ 
> com.apple.compilers.llvm.clang.1_0.compiler
> (1 failure)
> 
> /Users/dongmeiliang/Documents/swift-source/llvm/tools/clang/utils/TableGen/ClangASTNodesEmitter.cpp:50:12:
>  error: no viable conversion from returned value of type 'llvm::Twine' to 
> function return type
>  'std::string' (aka 'basic_string, 
> allocator >')
>return R.getName() + BaseSuffix;
>   ^~~~
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/tools/clang/utils/TableGen/ClangASTNodesEmitter.cpp:14:
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/include/llvm/TableGen/Record.h:18:
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/include/llvm/ADT/ArrayRef.h:13:
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/include/llvm/ADT/Hashing.h:49:
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/include/llvm/Support/Host.h:17:
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/include/llvm/ADT/StringMap.h:17:
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/include/llvm/ADT/StringRef.h:13:
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/include/llvm/ADT/STLExtras.h:36:
> In file included from 
> /Users/dongmeiliang/Documents/swift-source/llvm/include/llvm/Support/ErrorHandling.h:19:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:763:5:
>  note: candidate constructor not viable: no known conversion from 
> 'llvm::Twine' to
>  'const std::__1::basic_string &' for 1st argument
>basic_string(const basic_string& __str);
>^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:768:5:
>  note: candidate constructor not viable: no known conversion from 
> 'llvm::Twine' to
>  'std::__1::basic_string &&' for 1st argument
>basic_string(basic_string&& __str)
>^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:778:31:
>  note: candidate constructor not viable: no known conversion from 
> 'llvm::Twine' to
>  'const value_type *' (aka 'const char *') for 1st argument
>_LIBCPP_INLINE_VISIBILITY basic_string(const value_type* __s);
>  ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:810:5:
>  note: candidate constructor not viable: no known conversion from 
> 'llvm::Twine' to
>  'initializer_list' (aka 'initializer_list') for 1st 
> argument
>basic_string(initializer_list __il);
>^
> 1 error generated.
> ```
> 
> My software enviroments:
> 
> ```
> $ sw_vers
> ProductName:  Mac OS X
> ProductVersion:   10.13.2
> BuildVersion: 17C88
> 
> $ xcodebuild -version
> Xcode 9.2
> Build version 9C40b
> ```___
> 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] Protocol Devirtualizer Pass

[Slava Pestov via swift-dev]

> On Dec 20, 2017, at 3:56 PM, Raj Barik  wrote:
> 
> Thank you Arnold & Slava! The protocol devirtualizer pass works fine now for 
> most cases. I should be creating a PR soon (after some more testing).
> 
> I am thinking about extending this to Optional types as well, i.e., 

I’m not sure if its possible in the general case. What you might think of doing 
is rewriting this into a function that takes an Optional where T : 
SumProtocol. But the trouble is if the value of ‘a’ is nil, then there’s no 
concrete type to bind to the type parameter T at runtime. What you really want 
is a way to write

enum WeirdOptional {
  case  some(T)
  case none
}

But we don’t allow this.

I think even without handling optionals though, this optimization definitely 
has value.

Are you implementing it as a separate pass, or is it part of function signature 
specialization?

Slava

> 
> @inline(never) internal func wrap_inc_optional(a:SumProtocol?, val:Int) -> 
> Int?{
>  return a?.increment(i:val)
> }
> 
> The generated SIL looks something like this:
> 
> sil hidden [noinline] 
> @_T04main21wrap_inc_optionalSiSgAA11SumProtocol_pSg1a_Si3valtF : 
> $@convention(thin) (@owned Optional, Int) -> Optional {
> // %0 // users: %11, %4, %7, %2
> // %1 // users: %10, %3
> bb0(%0 : $Optional, %1 : $Int):
>   debug_value %0 : $Optional, let, name "a", argno 1 // id: %2
>   debug_value %1 : $Int, let, name "val", argno 2 // id: %3
>   switch_enum %0 : $Optional, case #Optional.some!enumelt.1: 
> bb2, case #Optional.none!enumelt: bb1 // id: %4
> 
> bb1:  // Preds: bb0
>   %5 = enum $Optional, #Optional.none!enumelt // user: %6
>   br bb3(%5 : $Optional) // id: %6
> 
> bb2:  // Preds: bb0
>   %7 = unchecked_enum_data %0 : $Optional, 
> #Optional.some!enumelt.1 // user: %8
>   %8 = open_existential_ref %7 : $SumProtocol to 
> $@opened("F0395A0A-E5DE-11E7-A06A-420039484801") SumProtocol // users: %10, 
> %10, %9
>   %9 = witness_method $@opened("F0395A0A-E5DE-11E7-A06A-420039484801") 
> SumProtocol, #SumProtocol.increment!1 :  
> (Self) -> (Int) -> Int, %8 : $@opened("F0395A0A-E5DE-11E7-A06A-420039484801") 
> SumProtocol : $@convention(witness_method) <τ_0_0 where τ_0_0 : SumProtocol> 
> (Int, @guaranteed τ_0_0) -> Int // type-defs: %8; user: %10
>   %10 = apply %9<@opened("F0395A0A-E5DE-11E7-A06A-420039484801") 
> SumProtocol>(%1, %8) : $@convention(witness_method) <τ_0_0 where τ_0_0 : 
> SumProtocol> (Int, @guaranteed τ_0_0) -> Int // type-defs: %8; user: %12
>   release_value %0 : $Optional   // id: %11
>   %12 = enum $Optional, #Optional.some!enumelt.1, %10 : $Int // user: %13
>   br bb3(%12 : $Optional)// id: %13
> 
> // %14// user: %15
> bb3(%14 : $Optional):// Preds: bb1 bb2
>   return %14 : $Optional // id: %15
> 
> 
> The above branching code (in red) in the SIL makes it non-trivial to abstract 
> out the non-nil path to a generic outlined method while keeping the branching 
> code in the thunk and also its not clear if the SILCombiner peephole 
> optimizer will actually come into affect for this scenario (because of the 
> branching code getting inlined in the caller).  It also gets more complicated 
> if there are more than one optional types as parameter to wrap_inc_optional. 
> Any clue on how one can handle optional types for devirtualization or if 
> there are any existing transformations in Swift compiler that can help 
> implement this easily? Thanks.
> 
> -R
> 
> 
> 
> On Wed, Dec 13, 2017 at 3:28 PM, Arnold Schwaighofer  > wrote:
> You don’t need a second open_existential_ref in the _wrap_inc 
> function. It should look something like this:
> 
> sil @_wrap_inc : $@convention(thin)  (@owned T, Int) 
> -> Int {
> bb0(%0 : $T, %1 : $Int):
>   %5 = witness_method $T, #SumProtocol.inc!1 :  SumProtocol> (Self) -> (Int) -> Int : $@convention(witness_method: 
> SumProtocol) <τ_0_0 where τ_0_0 : SumProtocol> (Int, @guaranteed τ_0_0) -> Int
>   %6 = apply %5(%1, %0) : $@convention(witness_method: SumProtocol) <τ_0_0 
> where τ_0_0 : SumProtocol> (Int, @guaranteed τ_0_0) -> Int
>   destroy_value %0 : $T
>   return %6 : $Int
> }
> 
> In the other function it looks like you need to apply the proper substitution 
> list to the apply instruction:
> 
> sil hidden [thunk] [always_inline] 
> @_T04main8wrap_incSiAA11SumProtocol_p1a_Si3valtF : $@convention(thin) (@owned 
> SumProtocol, Int) -> Int {
> bb0(%0 : $SumProtocol, %1 : $Int):
>   // function_ref specialized wrap_inc(a:val:)
>   %2 = function_ref @_T04main8wrap_incSiAA11SumProtocol_p1a_Si3valtFTf4nn_n
>   %3 = open_existential_ref %0 : $SumProtocol to 
> $@opened("E6196082-DF72-11E7-8C84-420039484801") SumProtocol
>   %4 = apply %2<τ_0_0>(%3, %1)

Re: [swift-dev] Conditional conformance: Removing the opt-in flag

[Slava Pestov via swift-dev]

> On Dec 18, 2017, at 6:27 PM, Dave Abrahams via swift-dev  > wrote:
> 
> 
> 
>> On Dec 18, 2017, at 4:52 PM, Douglas Gregor via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Hi all,
>> 
>> A little while back, I added an error to the Swift 4.1 compiler that 
>> complains if one tries to use conditional conformances, along with a flag 
>> “-enable-experimental-conditional-conformances” to enable the feature. We 
>> did this because we haven’t implemented the complete proposal yet; 
>> specifically, we don’t yet handle dynamic casting that involves conditional 
>> conformances, and won’t in Swift 4.1.
>> 
>> I’d like to take away the "-enable-experimental-conditional-conformances” 
>> flag and always allow conditional conformances in Swift 4.1, because the 
>> changes in the standard library that make use of conditional conformances 
>> can force users to change their code *to themselves use conditional 
>> conformances*. Specifically, if they had code like this:
>> 
>> extension MutableSlice : P { }
>> extension MutableBidirectionalSlice : P { }
>> // …
>> 
>> they’ll get an error about overlapping conformances, and need to do 
>> something like the following to fix the issue:
>> 
>> extension Slice: P where Base: MutableCollection { }
>> 
>> which is way more elegant, but would require passing 
>> "-enable-experimental-conditional-conformances”. That seems… unfortunate… 
>> given that we’re forcing them to use this feature.
>> 
>> My proposal is, specifically:
>> 
>> Allow conditional conformances to be used in Swift 4.1 (no flag required)
>> Drop the -enable-experimental-conditional-conformances flag entirely
>> Add a runtime warning when an attempt to dynamic cast fails due to a 
>> conditional conformance, so at least users know what’s going on
>> 
>> Thoughts?
> 
> I'm confused; I thought that overlapping conformances could result in cases 
> where it's ambiguous which extension to use to satisfy a requirement, but I 
> don't see anything in your proposal for handling that.  Does that become a 
> dynamic failure?

We don’t allow overlapping conformances; a concrete type T cannot conform to 
the same protocol P in more than one way with different conditional 
requirements.

Slava

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

Re: [swift-dev] Simple question about ParameterTypeFlags

[Slava Pestov via swift-dev]

It is one of the user-facing features from John McCall’s ownership manifesto.

Slava

> On Dec 11, 2017, at 3:33 PM, David Zarzycki  wrote:
> 
> This is a tangent from the original question, but is __shared a planned 
> feature? Or just experimental work?
> 
> Dave
> 
>> On Dec 11, 2017, at 17:12, Slava Pestov  wrote:
>> 
>> Sorry, what I meant is that they make sense with our language model, but 
>> it’s not surprising that it doesn’t work today. In any case, __shared is not 
>> yet completely implemented or even designed, so it doesn’t matter.
>> 
>> Slava
>> 
>>> On Dec 11, 2017, at 2:05 PM, David Zarzycki  wrote:
>>> 
>>> Hi Slava,
>>> 
>>> Interesting. Did I make a mistake in my test then? Both __shared @escaping 
>>> and __shared @autoclosure are failing below.
>>> 
>>> Dave
>>> 
>>>> On Dec 11, 2017, at 16:58, Slava Pestov via swift-dev 
>>>>  wrote:
>>>> 
>>>> I think perhaps __shared @escaping and __shared @autoclosure should be OK. 
>>>> You’re just passing the context as a +0 value instead of +1. Also __shared 
>>>> varargs make sense for the same reason. But it’s not important to get that 
>>>> working right now.
>>>> 
>>>> The others look OK.
>>>> 
>>>> Slava
>>>> 
>>>>> On Dec 11, 2017, at 1:15 PM, David Zarzycki via swift-dev 
>>>>>  wrote:
>>>>> 
>>>>> Hello! I’m trying to test which ParameterTypeFlags flag combinations are 
>>>>> valid. I wrote the following test case. Are the results “as expected”, or 
>>>>> are some of the failures incorrect?
>>>>> 
>>>>> // RUN: %target-typecheck-verify-swift
>>>>> 
>>>>> 
>>>>> //
>>>>> // isVariadic is NOT compatible with any flag combinations
>>>>> //
>>>>> // expected-error@+1 {{@autoclosure must not be used on variadic 
>>>>> parameters}}
>>>>> func v_and_autoclosure(arg : @autoclosure ()->()...) {}
>>>>> // expected-error@+1 {{@escaping attribute may only be used in function 
>>>>> parameter position}}
>>>>> func v_and_escaping(arg : @escaping ()->()...) {}
>>>>> // expected-error@+1 {{'inout' must not be used on variadic parameters}}
>>>>> func v_and_inout(arg : inout Int...) {}
>>>>> // expected-error@+1 {{'__shared' must not be used on variadic 
>>>>> parameters}}
>>>>> func v_and_shared(arg : __shared Int...) {}
>>>>> 
>>>>> //
>>>>> // 'inout' is NOT compatible with remaining parameter flag combinations
>>>>> //
>>>>> // expected-error@+1 {{parameter must not have multiple '__owned', 
>>>>> 'inout', '__shared', 'var', or 'let' specifiers}}
>>>>> func inout_and_shared(arg : inout __shared Int) {}
>>>>> // expected-error@+1 {{'inout' may only be used on parameters}}
>>>>> func inout_and_escaping(arg : @escaping inout ()->()) {}
>>>>> // expected-error@+1 {{@escaping attribute may only be used in function 
>>>>> parameter position}}
>>>>> func escaping_and_inout(arg : inout @escaping ()->()) {}
>>>>> // expected-error@+1 {{@autoclosure may only be used on parameters}}
>>>>> func inout_and_autoclosure(arg : inout @autoclosure ()->()) {}
>>>>> // expected-error@+1 {{'inout' may only be used on parameters}}
>>>>> func autoclosure_and_inout(arg : @autoclosure inout ()->()) {}
>>>>> 
>>>>> //
>>>>> // '__shared' is NOT compatible with remaining parameter flag combinations
>>>>> //
>>>>> // expected-error@+1 {{'__shared' may only be used on parameters}}
>>>>> func autoclosure_and_shared(arg : @autoclosure __shared ()->()) {}
>>>>> // expected-error@+1 {{@autoclosure may only be used on parameters}}
>>>>> func shared_and_autoclosure(arg : __shared @autoclosure ()->()) {}
>>>>> // expected-error@+1 {{'__shared' may only be used on parameters}}
>>>>> func escaping_and_shared(arg : @escaping __shared ()->()) {}
>>>>> // expected-error@+1 {{@escaping attribute may only be used in function 
>>>>> parameter position}}
>>>>> func shared_and_escaping(arg : __shared @escaping ()->()) {}
>>>>> 
>>>>> //
>>>>> // @autoclosure and @escaping are the only valid parameter flag 
>>>>> combinations
>>>>> //
>>>>> func autoclosure_and_escaping(arg : @autoclosure @escaping ()->()) {}
>>>>> func escaping_and_autoclosure(arg : @escaping @autoclosure ()->()) {}
>>>>> ___
>>>>> 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] Create SILType from GenericTypeParamType

[Slava Pestov via swift-dev]

There are two things that need to happen here, first the generic type parameter 
needs to be substituted with a concrete type, then it needs to be “lowered” to 
a SIL type.

You can try something like this,

GenericTypeParamType *paramTy = …;
SILFunction *F = …;
SILType T = F->getModule().Types.getLoweredType(F->mapTypeIntoContext(paramTy));

But we would need more details to understand what you’re doing.

Slava

> On Dec 11, 2017, at 2:30 PM, Raj Barik via swift-dev  
> wrote:
> 
> Hi,
> 
> I am trying to create a new generic function in the Swift compiler (as part 
> of a pass). Although I am able to create the generic function signature 
> fairly easily, I do not find an easy way to create a SILType from a 
> GenericTypeParamType, which is needed to be passed to createFunctionArgument. 
> Any help/suggestion?
> 
> Best,
> Raj
> ___
> 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] Simple question about ParameterTypeFlags

[Slava Pestov via swift-dev]

Sorry, what I meant is that they make sense with our language model, but it’s 
not surprising that it doesn’t work today. In any case, __shared is not yet 
completely implemented or even designed, so it doesn’t matter.

Slava

> On Dec 11, 2017, at 2:05 PM, David Zarzycki  wrote:
> 
> Hi Slava,
> 
> Interesting. Did I make a mistake in my test then? Both __shared @escaping 
> and __shared @autoclosure are failing below.
> 
> Dave
> 
>> On Dec 11, 2017, at 16:58, Slava Pestov via swift-dev  
>> wrote:
>> 
>> I think perhaps __shared @escaping and __shared @autoclosure should be OK. 
>> You’re just passing the context as a +0 value instead of +1. Also __shared 
>> varargs make sense for the same reason. But it’s not important to get that 
>> working right now.
>> 
>> The others look OK.
>> 
>> Slava
>> 
>>> On Dec 11, 2017, at 1:15 PM, David Zarzycki via swift-dev 
>>>  wrote:
>>> 
>>> Hello! I’m trying to test which ParameterTypeFlags flag combinations are 
>>> valid. I wrote the following test case. Are the results “as expected”, or 
>>> are some of the failures incorrect?
>>> 
>>> // RUN: %target-typecheck-verify-swift
>>> 
>>> 
>>> //
>>> // isVariadic is NOT compatible with any flag combinations
>>> //
>>> // expected-error@+1 {{@autoclosure must not be used on variadic 
>>> parameters}}
>>> func v_and_autoclosure(arg : @autoclosure ()->()...) {}
>>> // expected-error@+1 {{@escaping attribute may only be used in function 
>>> parameter position}}
>>> func v_and_escaping(arg : @escaping ()->()...) {}
>>> // expected-error@+1 {{'inout' must not be used on variadic parameters}}
>>> func v_and_inout(arg : inout Int...) {}
>>> // expected-error@+1 {{'__shared' must not be used on variadic parameters}}
>>> func v_and_shared(arg : __shared Int...) {}
>>> 
>>> //
>>> // 'inout' is NOT compatible with remaining parameter flag combinations
>>> //
>>> // expected-error@+1 {{parameter must not have multiple '__owned', 'inout', 
>>> '__shared', 'var', or 'let' specifiers}}
>>> func inout_and_shared(arg : inout __shared Int) {}
>>> // expected-error@+1 {{'inout' may only be used on parameters}}
>>> func inout_and_escaping(arg : @escaping inout ()->()) {}
>>> // expected-error@+1 {{@escaping attribute may only be used in function 
>>> parameter position}}
>>> func escaping_and_inout(arg : inout @escaping ()->()) {}
>>> // expected-error@+1 {{@autoclosure may only be used on parameters}}
>>> func inout_and_autoclosure(arg : inout @autoclosure ()->()) {}
>>> // expected-error@+1 {{'inout' may only be used on parameters}}
>>> func autoclosure_and_inout(arg : @autoclosure inout ()->()) {}
>>> 
>>> //
>>> // '__shared' is NOT compatible with remaining parameter flag combinations
>>> //
>>> // expected-error@+1 {{'__shared' may only be used on parameters}}
>>> func autoclosure_and_shared(arg : @autoclosure __shared ()->()) {}
>>> // expected-error@+1 {{@autoclosure may only be used on parameters}}
>>> func shared_and_autoclosure(arg : __shared @autoclosure ()->()) {}
>>> // expected-error@+1 {{'__shared' may only be used on parameters}}
>>> func escaping_and_shared(arg : @escaping __shared ()->()) {}
>>> // expected-error@+1 {{@escaping attribute may only be used in function 
>>> parameter position}}
>>> func shared_and_escaping(arg : __shared @escaping ()->()) {}
>>> 
>>> //
>>> // @autoclosure and @escaping are the only valid parameter flag combinations
>>> //
>>> func autoclosure_and_escaping(arg : @autoclosure @escaping ()->()) {}
>>> func escaping_and_autoclosure(arg : @escaping @autoclosure ()->()) {}
>>> ___
>>> 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] Simple question about ParameterTypeFlags

[Slava Pestov via swift-dev]

I think perhaps __shared @escaping and __shared @autoclosure should be OK. 
You’re just passing the context as a +0 value instead of +1. Also __shared 
varargs make sense for the same reason. But it’s not important to get that 
working right now.

The others look OK.

Slava

> On Dec 11, 2017, at 1:15 PM, David Zarzycki via swift-dev 
>  wrote:
> 
> Hello! I’m trying to test which ParameterTypeFlags flag combinations are 
> valid. I wrote the following test case. Are the results “as expected”, or are 
> some of the failures incorrect?
> 
> // RUN: %target-typecheck-verify-swift
> 
> 
> //
> // isVariadic is NOT compatible with any flag combinations
> //
> // expected-error@+1 {{@autoclosure must not be used on variadic parameters}}
> func v_and_autoclosure(arg : @autoclosure ()->()...) {}
> // expected-error@+1 {{@escaping attribute may only be used in function 
> parameter position}}
> func v_and_escaping(arg : @escaping ()->()...) {}
> // expected-error@+1 {{'inout' must not be used on variadic parameters}}
> func v_and_inout(arg : inout Int...) {}
> // expected-error@+1 {{'__shared' must not be used on variadic parameters}}
> func v_and_shared(arg : __shared Int...) {}
> 
> //
> // 'inout' is NOT compatible with remaining parameter flag combinations
> //
> // expected-error@+1 {{parameter must not have multiple '__owned', 'inout', 
> '__shared', 'var', or 'let' specifiers}}
> func inout_and_shared(arg : inout __shared Int) {}
> // expected-error@+1 {{'inout' may only be used on parameters}}
> func inout_and_escaping(arg : @escaping inout ()->()) {}
> // expected-error@+1 {{@escaping attribute may only be used in function 
> parameter position}}
> func escaping_and_inout(arg : inout @escaping ()->()) {}
> // expected-error@+1 {{@autoclosure may only be used on parameters}}
> func inout_and_autoclosure(arg : inout @autoclosure ()->()) {}
> // expected-error@+1 {{'inout' may only be used on parameters}}
> func autoclosure_and_inout(arg : @autoclosure inout ()->()) {}
> 
> //
> // '__shared' is NOT compatible with remaining parameter flag combinations
> //
> // expected-error@+1 {{'__shared' may only be used on parameters}}
> func autoclosure_and_shared(arg : @autoclosure __shared ()->()) {}
> // expected-error@+1 {{@autoclosure may only be used on parameters}}
> func shared_and_autoclosure(arg : __shared @autoclosure ()->()) {}
> // expected-error@+1 {{'__shared' may only be used on parameters}}
> func escaping_and_shared(arg : @escaping __shared ()->()) {}
> // expected-error@+1 {{@escaping attribute may only be used in function 
> parameter position}}
> func shared_and_escaping(arg : __shared @escaping ()->()) {}
> 
> //
> // @autoclosure and @escaping are the only valid parameter flag combinations
> //
> func autoclosure_and_escaping(arg : @autoclosure @escaping ()->()) {}
> func escaping_and_autoclosure(arg : @escaping @autoclosure ()->()) {}
> ___
> 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] [SE-0143] Dynamic casting for conditional conformances

[Slava Pestov via swift-dev]

> On Dec 6, 2017, at 10:04 PM, Slava Pestov via swift-dev  
> wrote:
> 
>> 
>> In AST terms:
>>  func matchEnvironment(GenericSignature, Type, TypeMetadata) -> 
>> GenericEnvironment?
>>  func substitute(GenericEnvironment, Type) -> TypeMetadata?
> 
> By GenericEnvironment do you really mean a substitution map?

Also note that the remote mirrors library already implements these operations 
in terms of TypeRefs, which are wrappers around mangled type strings. So there 
should be some potential for code reuse here.

Slava
___
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

[Slava Pestov via swift-dev]

> On Dec 6, 2017, at 10:00 PM, John McCall  wrote:
> 
> Yes, I can see how there's some nice synergy there, and it would certainly be 
> good to avoid having to eagerly generate code for this operation.  And it 
> should be possible to optimize the cast operation in the runtime if we find 
> ourselves executing it many times for different types.
> 
> Okay, the basic idea seems reasonable to me.  I guess my biggest concern is 
> the use of just mangled names, since it seems like that will pose a lot of 
> problems with private or local types.

As long as we mangle the unique private or local discriminator prefix, it 
shouldn’t be a problem. We’re not looking up global symbols by name, but 
scanning some kind of metadata section in the binary, which would presumably 
still have metadata for private and local types.

>  When Ashley was working on the remote-mirrors metadata, we had the idea of 
> using descriptor "strings" that could embed a reference to a nominal type 
> descriptor (or something like that) instead of just relying on a name.  (A 
> name would still be reasonable for a type that's not known to be defined 
> within the linkage unit, of course.)

Yes, this would be a useful optimization, but I don’t think it’s a 
pre-requisite for getting an initial implementation going before the ABI is 
finalized.

> In AST terms:
>   func matchEnvironment(GenericSignature, Type, TypeMetadata) -> 
> GenericEnvironment?
>   func substitute(GenericEnvironment, Type) -> TypeMetadata?

By GenericEnvironment do you really mean a substitution map?

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

Re: [swift-dev] [swift-build-dev] Swift CI will be down for maintenance - Dec 5th 2017 - 1pm PST

[Slava Pestov via swift-dev]

CI is not triggering for me here: https://github.com/apple/swift/pull/13288 


Slava

> On Dec 5, 2017, at 4:25 PM, Mishal Shah via swift-dev  
> wrote:
> 
> Maintenance completed. 
> 
> Thanks,
> Mishal Shah
> 
>> On Dec 5, 2017, at 1:00 PM, Mishal Shah via swift-build-dev 
>> mailto:swift-build-...@swift.org>> wrote:
>> 
>> Maintenance started. 
>> 
>> 
>>> On Dec 4, 2017, at 5:18 PM, Mishal Shah >> > wrote:
>>> 
>>> We will be taking down ci.swift.org  for maintenance 
>>> tomorrow Dec 5th 2017 at 1pm PST to update the Xcode. Please avoid 
>>> triggering pull request testing during the maintenance. 
>>> 
>>> Xcode 9.2 (9C40b) - https://developer.apple.com/download/ 
>>> 
>>> 
>>> I will reply to this email once the maintenance has started and completed. 
>>> 
>>> Thanks,
>>> Mishal Shah
>> 
>> ___
>> 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 mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[Slava Pestov via swift-dev]

> On Dec 5, 2017, at 4:05 PM, Douglas Gregor via swift-dev 
>  wrote:
> 
> 
> 
>> On Dec 5, 2017, at 3:56 PM, David Hart > > wrote:
>> 
>> But that wouldn’t allow surfacing a func type(named: String) Standard 
>> Library function that worked on any type, wouldn’t it (like the Dictionary 
>> with non-Hashable key)?
> 
> As I noted to John, we still need to handle the general case for the 
> right-hand side of a same-type constraint, which can be an arbitrary type. 
> That requires all of the functionality of type(named:). 
> 
> That said, from my perspective, adding type(named:) is entirely “gravy”. We 
> get it for free from this implementation plan, but IMO it could be added to 
> some later version of Swift and that would be fine.

I agree that surfacing it in the stdlib is gravy, but implementing the 
underlying mechanism is important, IMO. Field type vector accessors are a large 
contributor to binary code size (I wouldn’t be surprised if it was 5-10% for 
some projects) and implementing a more efficient encoding for ABI stability 
would be nice.

Slava

> 
>   - Doug
> 
>> 
>> On 6 Dec 2017, at 00:42, John McCall via swift-dev > > wrote:
>> 
 On Dec 5, 2017, at 5:28 PM, Douglas Gregor via swift-dev 
 mailto:swift-dev@swift.org>> wrote:
 Hi all,
 
 The main missing piece for conditional conformances 
 (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md
  
 )
  is support for dynamic casting. Right now, dynamic casting that queries a 
 conditional conformance will always fail. Here’s an example:
 
 protocol P {
   func foo()
 }
 
 struct X : P {
   func foo() { print("X.P") }
 }
 
 struct Y {
   var wrapped: T
 }
 
 extension Y: P where T: P {
   func foo() { wrapped.foo() }
 }
 
 func tryAsP(_ value: Any) {
   if let p = value as? P {
 p.foo()
   }
 }
 
 let yx = Y(wrapped: X())
 tryAsP(yx)
 
 This won’t print anything, but should print “X.P”. We’d like to fix that :)
 
 Joe Groff, Slava, and I discussed an approach to implement dynamic casting 
 for conditional conformances, which I’d like to outline here.
 
 Background
 The Swift runtime expresses the conformance of a specific type (say 
 Array) to a particular protocol (say, Equatable) using a witness 
 table. Witness tables contain the actual associated types as well as 
 function pointers for each of the requirements of a protocol. Slava and 
 John’s talk on Implementing Swift Generics 
 (https://llvm.org/devmtg/2017-10/#talk15 
 ) gives a bunch of background 
 here.
 
 When a conformance is conditional, the witness table also stores the 
 conditional requirements. So, the witness table for Array: Equatable 
 has to store the witness table Int: Equatable. In the example above, the 
 witness table for Y: P needs to store a pointer to the witness table X: 
 P. The compiler knows how to pass along the witness tables needed for a 
 conditional conformance, but for runtime casting to work, we need to (1) 
 evaluate all of the conditional requirements to determine whether they 
 apply (e.g., does T: P for a specific T?) and then (2) pass those witness 
 tables along when building the witness table. The cast should fail if any 
 of the conditional requirements goes unsatisfied, and produce a valid 
 witness table otherwise.
 
 Protocol Conformance Records
 Whenever code declares conformance of a particular type to a given 
 protocol, the compiler emits a “protocol conformance record” (documented 
 at 
 https://github.com/apple/swift/blob/master/docs/ABI/TypeMetadata.rst#protocol-conformance-records
  
 ).
  These protocol conformance records state the type declaring conformance 
 (e.g., Y) and the protocol (e.g., P), and then provide a witness table 
 accessor to form the witness table given type metadata for a specific type 
 instance (e.g., Y). In the case of a conditional conformance, this 
 accessor also needs to be passed the witness tables for any conditional 
 requirements, e.g., the witness table for X: P. 
 
 Conditional Requirements in Protocol Conformance Records
 Somehow we need to dynamically evaluate the conditional requirements. For 
 example, we need to know that for the X: P conformance to be valid, we 
 need T: P to hold for the given T. So, we’ll extend the protocol 
 conformance record with an encoding of those requirements. Fortunately, we 
 already have a way to encod

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

[Slava Pestov via swift-dev]

> On Dec 5, 2017, at 3:42 PM, John McCall via swift-dev  
> wrote:
> 
>> On Dec 5, 2017, at 5:28 PM, Douglas Gregor via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> Hi all,
>> 
>> The main missing piece for conditional conformances 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md
>>  
>> )
>>  is support for dynamic casting. Right now, dynamic casting that queries a 
>> conditional conformance will always fail. Here’s an example:
>> 
>> protocol P {
>>   func foo()
>> }
>> 
>> struct X : P {
>>   func foo() { print("X.P") }
>> }
>> 
>> struct Y {
>>   var wrapped: T
>> }
>> 
>> extension Y: P where T: P {
>>   func foo() { wrapped.foo() }
>> }
>> 
>> func tryAsP(_ value: Any) {
>>   if let p = value as? P {
>> p.foo()
>>   }
>> }
>> 
>> let yx = Y(wrapped: X())
>> tryAsP(yx)
>> 
>> This won’t print anything, but should print “X.P”. We’d like to fix that :)
>> 
>> Joe Groff, Slava, and I discussed an approach to implement dynamic casting 
>> for conditional conformances, which I’d like to outline here.
>> 
>> Background
>> The Swift runtime expresses the conformance of a specific type (say 
>> Array) to a particular protocol (say, Equatable) using a witness table. 
>> Witness tables contain the actual associated types as well as function 
>> pointers for each of the requirements of a protocol. Slava and John’s talk 
>> on Implementing Swift Generics (https://llvm.org/devmtg/2017-10/#talk15 
>> ) gives a bunch of background here.
>> 
>> When a conformance is conditional, the witness table also stores the 
>> conditional requirements. So, the witness table for Array: Equatable 
>> has to store the witness table Int: Equatable. In the example above, the 
>> witness table for Y: P needs to store a pointer to the witness table X: 
>> P. The compiler knows how to pass along the witness tables needed for a 
>> conditional conformance, but for runtime casting to work, we need to (1) 
>> evaluate all of the conditional requirements to determine whether they apply 
>> (e.g., does T: P for a specific T?) and then (2) pass those witness tables 
>> along when building the witness table. The cast should fail if any of the 
>> conditional requirements goes unsatisfied, and produce a valid witness table 
>> otherwise.
>> 
>> Protocol Conformance Records
>> Whenever code declares conformance of a particular type to a given protocol, 
>> the compiler emits a “protocol conformance record” (documented at 
>> https://github.com/apple/swift/blob/master/docs/ABI/TypeMetadata.rst#protocol-conformance-records
>>  
>> ).
>>  These protocol conformance records state the type declaring conformance 
>> (e.g., Y) and the protocol (e.g., P), and then provide a witness table 
>> accessor to form the witness table given type metadata for a specific type 
>> instance (e.g., Y). In the case of a conditional conformance, this 
>> accessor also needs to be passed the witness tables for any conditional 
>> requirements, e.g., the witness table for X: P. 
>> 
>> Conditional Requirements in Protocol Conformance Records
>> Somehow we need to dynamically evaluate the conditional requirements. For 
>> example, we need to know that for the X: P conformance to be valid, we 
>> need T: P to hold for the given T. So, we’ll extend the protocol conformance 
>> record with an encoding of those requirements. Fortunately, we already have 
>> a way to encode arbitrary generic requirements: the mangling of a 
>> generic-signature (see 
>> https://github.com/apple/swift/blob/master/docs/ABI/Mangling.rst#generics 
>> ) 
>> already encodes arbitrary generic requirements, so we can put a string 
>> comprised of the mangled conditional requirements into the protocol 
>> conformance record.
>> 
>> When evaluating a conditional conformance, we demangle the conditional 
>> requirements to get something like: “T must conform to P”. We then need to 
>> substitute the type arguments (e.g., X) for the  corresponding type 
>> parameters (T) to form type metadata for the requirements. In this case, 
>> we’d get the type metadata pointer for Y and the protocol descriptor for P, 
>> and then call swift_conformsToProtocol() to determine whether the 
>> requirement holds. If it does, swift_conformsToProtocol() produces the Y: P 
>> witness table we need to pass along to the witness table accessor.
>> 
>> Note that the conditional requirements can be arbitrarily complicated. For 
>> example, given:
>> 
>> extension Dictionary: P where Value == (Key) -> Bool { … }
>> 
>> Even though the result of evaluating this same-type requirement doesn’t need 
>> to be passed along to the witness table accessor, we still 

Re: [swift-dev] Equatable for two dimension array still not working (e.g. [[1]] == [[1]])

[Slava Pestov via swift-dev]

Try the master development snapshot. The changes have not been merged to 
swift-4.1-branch.

Slava

> On Dec 2, 2017, at 12:34 PM, Cao, Jiannan via swift-dev  
> wrote:
> 
> I used the swift-4.1-DEVELOPMENT-SNAPSHOT-2017-11-30-a-osx to test:
> 
> Welcome to Apple Swift version 4.1-dev (LLVM 05fee6ff60, Clang f0e38d2044, 
> Swift a1441d34f7). Type :help for assistance.
>   1> [[1]] == [[1]]
> error: repl.swift:1:7: error: binary operator '==' cannot be applied to two 
> '[[Int]]' operands
> [[1]] == [[1]]
> ~ ^  ~
> 
> repl.swift:1:7: note: overloads for '==' exist with these partially matching 
> parameter lists: (Any.Type?, Any.Type?), ((), ()), (Bool, Bool), (Character, 
> Character), (Character.UnicodeScalarView.Index, 
> Character.UnicodeScalarView.Index), (CodingUserInfoKey, CodingUserInfoKey), 
> (OpaquePointer, OpaquePointer), (AnyHashable, AnyHashable), (UInt8, UInt8), 
> (Int8, Int8), (UInt16, UInt16), (Int16, Int16), (UInt32, UInt32), (Int32, 
> Int32), (UInt64, UInt64), (Int64, Int64), (UInt, UInt), (Int, Int), 
> (AnyKeyPath, AnyKeyPath), (Unicode.Scalar, Unicode.Scalar), 
> (ObjectIdentifier, ObjectIdentifier), (String, String), (String.Index, 
> String.Index), (UnsafeMutableRawPointer, UnsafeMutableRawPointer), 
> (UnsafeRawPointer, UnsafeRawPointer), (UnicodeDecodingResult, 
> UnicodeDecodingResult), (_SwiftNSOperatingSystemVersion, 
> _SwiftNSOperatingSystemVersion), (AnyIndex, AnyIndex), 
> (ContiguousArray, ContiguousArray), (ArraySlice, 
> ArraySlice), (T?, T?), (T?, _OptionalNilComparisonType), 
> (_OptionalNilComparisonType, T?), ((A, B), (A, B)), ((A, B, C), (A, B, C)), 
> ((A, B, C, D), (A, B, C, D)), ((A, B, C, D, E), (A, B, C, D, E)), ((A, B, C, 
> D, E, F), (A, B, C, D, E, F)), (AutoreleasingUnsafeMutablePointer, 
> AutoreleasingUnsafeMutablePointer), (ClosedRangeIndex, 
> ClosedRangeIndex), (DoubleWidth, DoubleWidth), 
> (DoubleWidth.Words.Index, DoubleWidth.Words.Index), 
> (LazyDropWhileIndex, LazyDropWhileIndex), 
> (EmptyCollection, EmptyCollection), 
> (FlattenCollectionIndex, FlattenCollectionIndex), 
> (FlattenBidirectionalCollectionIndex, 
> FlattenBidirectionalCollectionIndex), (Set, 
> Set), (Dictionary.Keys, Dictionary.Keys), 
> ([Key : Value], [Key : Value]), (Set.Index, Set.Index), 
> (Dictionary.Index, Dictionary.Index), 
> (ManagedBufferPointer, ManagedBufferPointer Element>), (LazyPrefixWhileIndex, LazyPrefixWhileIndex), 
> (Range, Range), (CountableRange, CountableRange), 
> (ClosedRange, ClosedRange), (CountableClosedRange, 
> CountableClosedRange), (ReversedIndex, ReversedIndex), 
> (ReversedRandomAccessIndex, ReversedRandomAccessIndex), 
> (_UIntBuffer.Index, _UIntBuffer.Index), 
> (UnsafeMutablePointer, UnsafeMutablePointer), 
> (UnsafePointer, UnsafePointer), 
> (_ValidUTF8Buffer.Index, _ValidUTF8Buffer.Index), (Self, 
> Other), (Self, R)
> [[1]] == [[1]]
>   ^
> 
> ___
> 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] Protocol Devirtualizer Pass

[Slava Pestov via swift-dev]

Hi Raj,

The way I would approach this problem is first, turn a function taking a 
protocol value into one taking a protocol-constrained generic parameter. So

@inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{
 return a.increment(i:val)
}

Would become

@inline(always) internal func wrap_inc(a: SumProtocol, val: Int) -> Int {
  // opening an existential cannot be expressed in Swift, but it can in SIL…
  let _a = a open as T

  return _wrap_inc(_a, val)
}

@inline(never) internal func _wrap_inc(_a:T, val:Int) -> Int{
 let a: SomeProtocol = _a
 return a.increment(i:val)
}

(Note that the existing function signature specialization pass performs a 
similar transformation where it creates a new function with the same body as 
the old function but a different signature, and replaces the old function with 
a short thunk that transforms arguments and results and calls the new function.)

At this point, the existing “initialize existential with concrete type” 
peephole in the SILCombiner should eliminate the existential (but the peephole 
doesn’t work in 100% of cases yet):

@inline(always) internal func wrap_inc(a: SumProtocol, val: Int) -> Int {
  // opening an existential cannot be expressed in Swift, but it can in SIL…
  let _a = a open as T

  return _wrap_inc(_a, val)
}

@inline(never) internal func _wrap_inc(_a:T, val:Int) -> Int{
 return _a.increment(i:val)
}

Now, if I have a call to wrap_inc somewhere, 

internal let magic:SumProtocol = SumClass(base:10)
_ = wrap_inc(magic)

Then the optimizer will inline the thunk, giving you a call to _wrap_inc. The 
existential value built from the SumClass instance is immediately opened so it 
will be peepholed away. At this point you have a call of a generic function 
_wrap_inc with a concrete type SumClass, and the generic specializer can 
produce a specialization of it.

Notice how this approach combines several existing optimizations and only 
requires adding a relatively simple new transformation, and possibly improving 
some of the existing optimizations to cover more cases.

Slava

> On Nov 29, 2017, at 11:30 AM, Raj Barik via swift-dev  
> wrote:
> 
> Hi,
> 
> I am thinking about writing a Protocol Devirtualizer Pass that specializes 
> functions that take Protocols as arguments to transform them with concrete 
> types instead of protocol types when the concrete types can be determined 
> statically by some compiler analysis. This is the first step of the 
> transformation that I am proposing. My goal is to extend this to eliminate 
> the original function implementation and also to remove the corresponding 
> protocol type (by deleting it from the witness table), if possible. For 
> simple cases, where the protocol is only used for mocking for example and 
> that there is just one class that conforms to it, we should be able to 
> eliminate the protocol altogether. This is the second and final step of the 
> transformation. Does anyone see any issues with both these steps? Arnold from 
> Apple pointed out that there might be demangling issues when the protocol is 
> eliminated. Any ideas on how to fix the demangling issues? Moreover, would 
> such a pass be helpful to Swift folks?
> 
> Original code:
> 
> 
> protocol SumProtocol: class {
>   func increment(i:Int)  -> Int
> }
> 
> internal class SumClass: SumProtocol {
>   var a:Int
>   init(base:Int) {
> self.a = base
>   }
>   func increment(i:Int) -> Int {
>self.a += i
>return self.a
>   }
> }
> 
> @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{
>  return a.increment(i:val)
> }
> 
> internal let magic:SumProtocol = SumClass(base:10)
> print("c=\(wrap_inc(a:magic,val:10))")
> 
> 
> After Step 1:
> 
> 
> protocol SumProtocol: class {
>   func increment(i:Int)  -> Int
> }
> 
> internal class SumClass: SumProtocol {
>   var a:Int
>   init(base:Int) {
> self.a = base
>   }
>   func increment(i:Int) -> Int {
>self.a += i
>return self.a
>   }
> }
> 
> @inline(never) internal func wrap_inc(a:SumProtocol, val:Int) -> Int{
>  return a.increment(i:val)
> }
> 
> @inline(never) internal func wrap_inc_1(a:SumClass, val:Int) -> Int{
>  return a.increment(i:val)
> }
> 
> internal let magic:SumClass = SumClass(base:10)
> print("c=\(wrap_inc_1(a:magic,val:10))")
> 
> 
> After Step 2:
> 
> internal class SumClass {
>   var a:Int
>   init(base:Int) {
> self.a = base
>   }
>   func increment(i:Int) -> Int {
>self.a += i
>return self.a
>   }
> }
> 
> @inline(never) internal func wrap_inc(a:SumClass, val:Int) -> Int{
>  return a.increment(i:val)
> }
> 
> internal let magic:SumClass = SumClass(base:10)
> print("c=\(wrap_inc(a:magic,val:10))")
> 
> Any comments/thought on this transformation?
> 
> Best,
> Raj 
> ___
> 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:/

Re: [swift-dev] Potential contributions to compilation time reporting?

[Slava Pestov via swift-dev]

> On Nov 28, 2017, at 5:01 PM, Mark Lacey via swift-dev  
> wrote:
> 
> 
> 
>> On Nov 19, 2017, at 9:02 PM, Brian Gesiak via swift-dev > > wrote:
>> 
>> Thanks for the reply, Graydon, and for your other email on the topic 
>> !
>> 
>> I need to take more time to look into some of the things you mentioned, but 
>> I won't be able to do so in earnest for another few days. In the meantime, 
>> I'll just reply with a few uninformed opinions -- feel free not to respond 
>> to these :)
>> 
>> On Fri, Nov 17, 2017 at 12:54 AM, Graydon Hoare > > wrote:
>> Sadly, there's not always a 1:1 mapping between source entities and time 
>> like that. Certainly _some_ cases can be so egregious (say, typechecking 
>> time on an expression that's triggering an exponential-time inference) that 
>> they dominate compile time, and can be identified-and-fixed in isolation; 
>> but often the total amount of work attributable to a given source entity is 
>> spread around the compilation, occurs in multiple phases, emerges out of 
>> interaction between entities, overlaps with others, etc.
>> 
>> It's these particularly egregious cases that I had in mind when I wrote my 
>> email. Many blog posts on "how to reduce your Swift project compile times" 
>> suggest one of the following approaches:
>> 
>> 1. Use `-debug-time-function-bodies` and `-debug-time-expression-checking` 
>> to print a list of times, sort those lists in descending order of time 
>> spent, and add explicit types to, or otherwise simplify, the slowest 
>> functions and expressions.
>> 2. Use `-warn-long-function-bodies=` and 
>> `-warn-long-expression-type-checking=`. Compile the project several times, 
>> gradually lowering the thresholds passed to these options, in order to 
>> surface the slowest functions and expressions. Add explicit types to or 
>> otherwise simplify the slowest functions and expressions.
> 
> One of the drawbacks with the type checker timers is that they do not exclude 
> the time spent in client code called by the type checker, e.g. in 
> deserialization code. The result is that you can e.g. have a simple 
> expression involving a stdlib type like String, and have it be reported as 
> taking 500ms to type check, when in fact it’s nearly instantaneous to type 
> check, but we spent 500ms deserializing things while type checking that 
> expression. What gets really confusing about this is some of this 
> deserializing only happens if you don’t use explicit types, so adding an 
> explicit type to one of these expressions can mean that this expression is 
> now fast, but some other expression which was previously reported as being 
> fast now suddenly “regresses” and takes 500ms due to that deserialization 
> happening later.

On the flip side, I would argue that if referencing a single stdlib declaration 
like String results in 500ms spent in deserialization, we have a problem, even 
if it s a one-time cost. In multiple-frontend mode, every source file will end 
up paying the 500ms penalty.

> 
> I haven’t looked closely, but offhand I don’t know of a clean, robust, 
> maintainable way of excluding this time.
> 
> I’m a bit concerned about productizing these without solving that problem.
> 
> It’s also not necessarily reasonable that we’re doing this deserialization 
> when an explicit type is not used so there might be something useful to 
> investigate and fix there as well.
> 
> Mark
> 
>> 
>> My original idea was to expand or improve these options, since I think 
>> they'll continue to be useful for large Swift projects. But I'm certainly 
>> open to working on something else instead.
>>  
>> I don't have an especially strong feeling about the degree-of-support / 
>> stability of such features; I'm going to have to leave that part of your 
>> question to others.
>> 
>> Yeah, this is definitely still an open question of mine. In the meantime 
>> I'll try looking at some of the other approaches you've suggested (thanks!).
>> 
>>   1. See if you can leverage the existing counters and stats-gathering / 
>> reporting machinery in the compiler; for example the -trace-stats-events 
>> infrastructure lets you bundle together work done on behalf of a given 
>> source range and any changes to compiler counters during that work, as a 
>> single virtual "stats-event" in processing, and trace those events to a .csv 
>> file. Maybe something related to that would be helpful for the task you're 
>> interested in?
>> 
>> I wasn't aware of `-trace-stats-events`, thanks! When using 
>> `-stats-output-dir` with a primary-file compilation mode, I can see that the 
>> stats include the amount of time spent on each Swift module being produced. 
>> I'll need to take a closer look at how `-trace-stats-events` works, though 
>> -- I get an empty .csv file when I use that option in conjunction with 
>> `-stats-output-dir`, and I'm not s

Re: [swift-dev] [swift-users] Where to read about *.swiftmodule file format?

[Slava Pestov via swift-dev]

Hi Volodymyr,

The format is not documented anywhere and is subject to change. A good starting 
point is include/swift/Serialization/ModuleFormat.h, but I would first be 
curious to know what exactly you’re planning on doing with it.

It might be better to extend swift-ide-test and similar utilities to dump the 
information you need in an easy to parse format, and exec() them from your IDE, 
instead of attempting to parse swift modules directly.

Slava

> On Nov 28, 2017, at 7:00 AM, Volodymyr B via swift-users 
>  wrote:
> 
> Hi
> 
> Where to read about *.swiftmodule file format?
> 
> And *.swiftdoc 
> 
> I want to understand container of it.
> 
> would be good to have parser for third party IDEs.
> 
> Best regards,
> Volodymyr Boichentsov
> 
> 
> 
> 
> 
> 
> 
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-dev] Building Swift 2.2.1 on macOS High Sierra (10.13)

[Slava Pestov via swift-dev]

> On Nov 19, 2017, at 6:12 PM, leanne  wrote:
> 
> If I get where you're going, though, Slava, does building Swift 2.2.1 require 
> an older version of the Xcode Command Line Tools, then??? Is that why I might 
> need an older Xcode?

That’s my theory, yeah.

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

Re: [swift-dev] Building Swift 2.2.1 on macOS High Sierra (10.13)

[Slava Pestov via swift-dev]

What version of Xcode are you using to _build_ Swift 2.2? You might need an 
older Xcode for that.

Slava

> On Nov 19, 2017, at 11:24 AM, leanne  wrote:
> 
> Yes, I could, Slava. I was hoping not to, though. That's the point of using 
> swiftenv.
> 
> On Sat, Nov 18, 2017 at 6:24 PM, Slava Pestov  > wrote:
> Instead of building Swift yourself, can you download and run Xcode 7 instead?
> 
> Slava
> 
>> On Nov 18, 2017, at 7:19 PM, leanne via swift-dev > > wrote:
>> 
>> I'm using swiftenv (https://github.com/kylef/swiftenv 
>> ) to install Swift versions 2 and 3, so I 
>> can work with some older projects.
>> 
>> Swift 3.1.1 installed perfectly first try. Been through a few iterations, 
>> though, trying to install 2.2.1.
>> 
>> Installed CMake 3.9.4, Ninja 1.8.2, then Python 3.6.3. Seemed to almost make 
>> it through - then failed again, and I'm not sure what's happening with this 
>> one.
>> 
>> I'd appreciate any help you can offer! Here is the end of my log, starting 
>> with the failure:
>> 
>> [136/665] Building CXX object 
>> lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o
>> FAILED: lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>>   -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS 
>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/SILGen 
>> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/lib/SILGen 
>> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/include -Iinclude 
>> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/include
>>  -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include 
>> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/tools/clang/include
>>  
>> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/tools/clang/include
>>  -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/cmark/src 
>> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/build/Ninja-ReleaseAssert/cmark-macosx-x86_64/src
>>  -fno-stack-protector -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall 
>> -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
>> -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor 
>> -Werror=date-time -std=c++11 -fcolor-diagnostics -Wdocumentation 
>> -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -O3
>> -UNDEBUG  -fno-exceptions -fno-rtti -target x86_64-apple-macosx10.9 
>> -isysroot 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>>  -arch x86_64 -F 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/../../../Developer/Library/Frameworks
>>  -mmacosx-version-min=10.9 -O2 -momit-leaf-frame-pointer -g0 -UNDEBUG -MD 
>> -MT lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o -MF 
>> lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o.d -o 
>> lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o -c 
>> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/lib/SILGen/SILGenProfiling.cpp
>> In file included from 
>> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/lib/SILGen/SILGenProfiling.cpp:13:
>> In file included from 
>> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/lib/SILGen/SILGenProfiling.h:16:
>> In file included from 
>> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include/llvm/ADT/DenseMap.h:17:
>> In file included from 
>> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include/llvm/ADT/DenseMapInfo.h:17:
>> In file included from 
>> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include/llvm/ADT/ArrayRef.h:13:
>> In file included from 
>> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include/llvm/ADT/Hashing.h:48:
>> In file included from 
>> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/include/llvm/Support/DataTypes.h:35:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:305:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h:309:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1301:38:
>>  error: incomplete type 'swift::Expr' used in type trait expression
>> : public integral_constant {};
>>  ^
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1374:39:
>>  note: in instantiation of template class 
>> 'std::__1::is_abstract' requested here
>>  !is_abstract<_T2>::value> {};
>>   

Re: [swift-dev] Building Swift 2.2.1 on macOS High Sierra (10.13)

[Slava Pestov via swift-dev]

Instead of building Swift yourself, can you download and run Xcode 7 instead?

Slava

> On Nov 18, 2017, at 7:19 PM, leanne via swift-dev  wrote:
> 
> I'm using swiftenv (https://github.com/kylef/swiftenv 
> ) to install Swift versions 2 and 3, so I 
> can work with some older projects.
> 
> Swift 3.1.1 installed perfectly first try. Been through a few iterations, 
> though, trying to install 2.2.1.
> 
> Installed CMake 3.9.4, Ninja 1.8.2, then Python 3.6.3. Seemed to almost make 
> it through - then failed again, and I'm not sure what's happening with this 
> one.
> 
> I'd appreciate any help you can offer! Here is the end of my log, starting 
> with the failure:
> 
> [136/665] Building CXX object 
> lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o
> FAILED: lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>   -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
> -D__STDC_LIMIT_MACROS -Ilib/SILGen 
> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/lib/SILGen 
> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/include -Iinclude 
> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/include
>  -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include 
> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/tools/clang/include
>  
> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/tools/clang/include 
> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/cmark/src 
> -I/Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/build/Ninja-ReleaseAssert/cmark-macosx-x86_64/src
>  -fno-stack-protector -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall 
> -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor 
> -Werror=date-time -std=c++11 -fcolor-diagnostics -Wdocumentation 
> -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -O3
> -UNDEBUG  -fno-exceptions -fno-rtti -target x86_64-apple-macosx10.9 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>  -arch x86_64 -F 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/../../../Developer/Library/Frameworks
>  -mmacosx-version-min=10.9 -O2 -momit-leaf-frame-pointer -g0 -UNDEBUG -MD -MT 
> lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o -MF 
> lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o.d -o 
> lib/SILGen/CMakeFiles/swiftSILGen.dir/SILGenProfiling.cpp.o -c 
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/lib/SILGen/SILGenProfiling.cpp
> In file included from 
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/lib/SILGen/SILGenProfiling.cpp:13:
> In file included from 
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/lib/SILGen/SILGenProfiling.h:16:
> In file included from 
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include/llvm/ADT/DenseMap.h:17:
> In file included from 
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include/llvm/ADT/DenseMapInfo.h:17:
> In file included from 
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include/llvm/ADT/ArrayRef.h:13:
> In file included from 
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/llvm/include/llvm/ADT/Hashing.h:48:
> In file included from 
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/include/llvm/Support/DataTypes.h:35:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:305:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h:309:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1301:38:
>  error: incomplete type 'swift::Expr' used in type trait expression
> : public integral_constant {};
>  ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/type_traits:1374:39:
>  note: in instantiation of template class 
> 'std::__1::is_abstract' requested here
>  !is_abstract<_T2>::value> {};
>   ^
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/include/swift/Basic/NullablePtr.h:40:22:
>  note: in instantiation of template class 
> 'std::__1::is_convertible' requested here
> std::is_convertible::value,
>  ^
> /Users/username/.swiftenv/tmp/swiftenv-build-2.2.1/swift/include/swift/Basic/NullablePtr.h:30:7:
>  note: while substituting deduced template argument

Re: [swift-dev] AutomaticEnumValueKind Tuple of Literals

[Slava Pestov via swift-dev]

Hi Mohammed,

The ‘automatic enum value’ code path is used if you have code like this, where 
you declare a raw type but don’t assign raw values:

enum E : Int {
  case a
  case b
  case c
}

This only makes sense for a raw type of integer, and not string — or a tuple. 
Even if you have (Int, Int) as your raw type, it’s not clear how to 
automatically increment such a value, so I think you shouldn’t be hitting this 
code path at all if you have a tuple raw type.

Slava

> On Nov 18, 2017, at 1:07 PM, Mohammed Ennabah via swift-dev 
>  wrote:
> 
> I have been digging into the Swift library to solve the case where enum could 
> have a RawValue of tuples of literals. So far, I found that in 
> lib/Sema/TypeCheckDecl.cpp::3020 we do check the enum RawValue if it conforms 
> to a knownProtocolKind, and if true, we switch over to check whether it’s 
> ExpressibleByXXLiteral (XX could be String, Integer, etc..).
> Now, my questions are:
> I need to extend this condition to have a tuple of types that conforms to the 
> knownProtocolKind, and I’m not quite sure where to start. (Note: It’s better 
> to make the tuple conforms to a protocol type that is knownProtocolKind, so 
> the enum can be tuple of tuples.., let me know your thoughts please).
> We increment the RawValue if it’s of type Integer. What if the tuple of type 
> (Int, String), will we need to increment the Int part as well? I think yes, 
> but I’m asking to listen to your thoughts, too.
> 
> 
> - Mohammed
> ___
> 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 16.04 (swift 4.1) #251

[Slava Pestov via swift-dev]

I reverted Kelvin’s change in the swift-4.1-branch. Foundation auto merges from 
master to swift-4.1-branch but Swift does not, so the two repositories were out 
of sync. https://github.com/apple/swift-corelibs-foundation/pull/1327 


Slava

> On Nov 18, 2017, at 1:00 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-4.1-incremental-RA-linux-ubuntu-16_04 [#251]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-4.1-incremental-RA-linux-ubuntu-16_04/251/ 
> 
> Project:  oss-swift-4.1-incremental-RA-linux-ubuntu-16_04
> Date of build:Fri, 17 Nov 2017 23:38:16 -0600
> Build duration:   21 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 6476c4fdae88e00688d743af5130179a5b2329d8 by kelvinsthirteen:
> compatability with SE-0184 implementation
> 
> edit: Foundation/FileManager.swift
> edit: Foundation/NSConcreteValue.swift
> edit: Foundation/NSCFDictionary.swift
> edit: Foundation/Thread.swift
> edit: Foundation/Data.swift
> edit: Foundation/NSKeyedCoderOldStyleArray.swift
> edit: Foundation/NSOrderedSet.swift
> edit: Foundation/Dictionary.swift
> edit: Foundation/Set.swift
> edit: Foundation/Process.swift
> edit: Foundation/NSLock.swift
> edit: Foundation/NSDictionary.swift
> edit: TestFoundation/TestNSKeyedArchiver.swift
> edit: Foundation/NSUUID.swift
> edit: Foundation/NSSet.swift
> edit: Foundation/NSCFSet.swift
> edit: Foundation/NSCoder.swift
> edit: Foundation/NSString.swift
> edit: Foundation/Host.swift
> edit: Foundation/NSArray.swift
> edit: Foundation/NSSwiftRuntime.swift
> edit: Foundation/AffineTransform.swift
> edit: Foundation/NSRange.swift
> edit: Foundation/NSGeometry.swift
> edit: Foundation/JSONSerialization.swift
> edit: Foundation/String.swift

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

Re: [swift-dev] Highlighting other platforms for Swift?

[Slava Pestov via swift-dev]

> On Nov 15, 2017, at 11:35 AM, Ted Kremenek via swift-dev 
>  wrote:
> 
> That said, do you have specific ideas on how such efforts should be 
> highlighted on swift.org , and what should be the optics?

I think more prominent links to instructions for building Swift on other 
platforms would be great to have on the web site. Links to third party binary 
packages I’d be worried about because of the security implications...

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

Re: [swift-dev] No attribute(swiftcall) support on Linux?

[Slava Pestov via swift-dev]

This is while building the metadata unit tests — I’m assuming those are built 
with the host clang? Do we build the runtime with the Swift clang on Linux? If 
so, we should still be able to use swiftcall.

Slava

> On Nov 13, 2017, at 10:47 PM, Greg Parker via swift-dev  
> wrote:
> 
> I see that in our Linux builds clang complains that it does not support the 
> swiftcall attribute.
> 
> In file included from 
> /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/unittests/runtime/Metadata.cpp:13:
> 
> /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/include/swift/Runtime/Metadata.h:3015:1:
>  warning: unknown attribute 'swiftcall' ignored [-Wunknown-attributes]
> 
> How bad is this? Do we not use a custom calling convention on Linux platforms 
> today?
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> 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] Preparing metadata records for ABI stability

[Slava Pestov via swift-dev]

> On Nov 13, 2017, at 11:40 AM, John McCall via swift-dev  
> wrote:
> 
>   - I feel like we're not boxing ourselves in too much to assume a layout of 
> the generic requirements.  Having a base offset already imposes a pretty 
> steep compatibility requirement — e.g. even if we significantly generalized a 
> type's generic signature, we would still need to store old requirements (when 
> actually obeyed) in the appropriate places for the old signature, or else the 
> old pattern just doesn't work at all.  As long as we can extend that with 
> more information later, we don't really suffer from making layout assumptions 
> today.

Do you mean if we significantly generalized the schema for generic 
requirements, or if we changed the definition of a single type to be more 
general? I would rather the latter did not happen.

Accessing generic arguments efficiently is important for extension methods, I 
think. In fact right now even thin functions recover metadata from a thick 
metatype argument if its the last parameter, although perhaps this is not 
intentional.

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

Re: [swift-dev] SR-3423 Enum RawValue Tuple of Literals

[Slava Pestov via swift-dev]

> On Nov 12, 2017, at 5:37 PM, Mohammed Ennabah via swift-dev 
>  wrote:
> 
> Hi All,
> 
> I’m working on SR-3423, the issue basically is Swift does not allow using 
> literals when they are represented as tuples. Now when I went through the 
> codebase, I found that (AFAIK) it can be fixed by either
> a) giving tuples of literals a LiteralExpr, so there will be something like 
> TupleLiteralExpr when they hold literal values.
> Or b) changing the condition “The raw value must be syntactically a simple 
> literal” which stated in lib/Parse/ParseDecl.cpp::5223 to comprise a case 
> where the raw value is tuples of literal.
> I think that the second case (b) is more specific about the issue, but will 
> it have downsides in the future?

I think b) is the way to go.

Slava

> ___
> 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] deprecating -Ounchecked

[Slava Pestov via swift-dev]

> On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev  
> wrote:
> 
> Random question: when did you introduce -Osize, and why didn’t it go through 
> the evolution process?  If this is a major flag that you expect users to 
> interact with (not some obscure debugging feature) then it is part of the 
> “UI" of Swift and seems subject to swift-evolution’s process.

Are compiler flags within the scope of the evolution process? -Osize has no 
effect on source compatibility or any other user-visible aspect of the language 
itself.

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

Re: [swift-dev] deprecating -Ounchecked

[Slava Pestov via swift-dev]

> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev  
> wrote:
> 
> So if we replace Ounchecked with an option -unsafe-remove-checks (similar to 
> -assume-single-threaded), as Johannes suggested, this is more like a “at your 
> own risk” thing (regarding performance). For example, it might happen that 
> users see perf regressions from one release to another, using this option.

I would suggest going further and removing the code for -unsafe-remove-checks 
altogether. Even untested code has a cost in terms of maintainability.

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

Re: [swift-dev] How does a standard collection know when its storage has to die?

[Slava Pestov via swift-dev]

These types are essentially single-field structs. The underlying storage is 
referenced from this field, which has a reference type. While structs cannot 
have user-defined destructors, the compiler knows when a value of struct type 
goes out of scope and destroys its fields, which for reference types decrements 
their reference count.

Slava

> On Oct 25, 2017, at 3:29 PM, Daryle Walker via swift-dev 
>  wrote:
> 
> OK, so the standard collections (Array, Set, Dictionary) are value types with 
> remote storage. Since they don’t have de-initializers, how would any 
> reference count get any notification to eventually de-allocate ? Or is the 
> memory leaked? Or is some sort of secret system-provided de-initalizer added?
> 
> Just thinking of a undiscriminated union idea and wondering how to prevent 
> this kind of leak. 
> 
> Sent from my iPhone
> ___
> 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 16.04 - Long Test (master) #485

[Slava Pestov via swift-dev]

> On Oct 24, 2017, at 4:26 PM, Xi Ge via swift-dev  wrote:
> 
> This could be due to one of the following commit. Could someone shed some 
> lights on what’s going on?
> Git (git g...@github.com :apple/swift.git)
> 
> [ClangImporter] Don't add duplicate search paths (detail 
> )
> [ClangImporter] Only suppress specific diags in synthetic buffers (detail 
> )
I’m going to guess it’s one of these two.

Slava___
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) #1113

[Slava Pestov via swift-dev]

There has been a missing dependency here forever. Can someone well versed in 
cmake take a look? It should be an easy fix.

Slava

> On Oct 17, 2017, at 11:54 AM, Pavel Yaskevich via swift-dev 
>  wrote:
> 
> This is my changes - they require a clean build (because I changed TypeRef 
> but didn’t change anything in swift-reflection-dump itself), is there any way 
> to do that?
> 
>> On Oct 17, 2017, at 11:51 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1113]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1113/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Tue, 17 Oct 2017 13:36:58 -0500
>> Build duration:  15 min
>> Identified problems:
>> 
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all errors:
>> Indication 1 
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 2 test(s), Passed: 10003 test(s), Total: 10005 test(s)
>> Failed: Swift(linux-x86_64).Reflection.capture_descriptors.sil 
>> 
>> Failed: Swift(linux-x86_64).Reflection.typeref_decoding.swift 
>> 
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 483 test(s), Total: 483 test(s)
>> 
>> Changes
>> 
>> Commit 8f26fb88d4e0e03bbdfadb560b96f00079205b19 by pyaskevich:
>> [Mangling] Improve handling of the variadic function parameters
>> 
>> edit: test/SILGen/default_arguments_imported.swift
>> edit: test/Serialization/function.swift
>> edit: test/Reflection/typeref_decoding.swift
>> edit: test/SourceKit/DocSupport/doc_clang_module.swift.response
>> edit: stdlib/public/Reflection/TypeRef.cpp
>> edit: test/SILGen/scalar_to_tuple_args.swift
>> edit: test/Reflection/Inputs/ConcreteTypes.swift
>> edit: test/IRGen/big_types_corner_cases.swift
>> edit: test/Reflection/capture_descriptors.sil
>> edit: test/SILGen/errors.swift
>> edit: test/Demangle/Inputs/manglings.txt
>> edit: test/SILGen/mangling.swift
>> edit: test/SILGen/opaque_values_silgen.swift
>> edit: lib/Demangling/NodePrinter.cpp
>> edit: lib/AST/ASTMangler.cpp
>> edit: test/SIL/Serialization/deserialize_generic.sil
>> edit: test/SILGen/retaining_globals.swift
>> 
>> Commit 7dce4bfda9e31a877cded78019b4b43f2110c0ca by ankit_aggarwal:
>> [PinsStore] Add support for loading PinsStore schema 1
>> 
>> edit: Tests/WorkspaceTests/PinsStoreTests.swift
>> edit: Sources/Workspace/PinsStore.swift
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

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

[Slava Pestov via swift-dev]

Another dispatch failure:

Foundation/NSData.swift:19:8: error: module file was created by an older 
version of the compiler; rebuild 'Dispatch' and try again: 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/buildbot_incremental/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule

import Dispatch
   ^

Note that my patches listed below don’t even change the module format number, 
so this error is a result of stale build artifacts from a previous build on the 
same machine.

Slava

> On Oct 9, 2017, at 9:54 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#944]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/944/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Mon, 09 Oct 2017 23:47:16 -0500
> Build duration:   8 min 14 sec
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9969 test(s), Total: 9969 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 483 test(s), Total: 483 test(s)
> 
> Changes
> 
> Commit 39f9ede29b3451c2d6fe0e6889df2ee7a366c5a4 by spestov:
> SIL: Add SILFunctionType::getWitnessMethodClass() accessor
> 
> edit: lib/SIL/SILFunctionType.cpp
> edit: include/swift/AST/Types.h
> 
> Commit c2f2eb6c3cc221ec6b1ed8ededb0659763817d54 by spestov:
> SILOptimizer: Devirtualizer support for witness thunks with a
> 
> edit: lib/SILOptimizer/Utils/Devirtualize.cpp
> add: test/SILOptimizer/devirt_class_witness_method.sil
> 
> Commit e1b33b1a914abbfc0c356ee8507035e38aba1a93 by spestov:
> IRGen: Fix bug in @convention(witness_method) 'Self' metadata
> 
> edit: test/IRGen/witness_method.sil
> edit: lib/IRGen/GenProto.cpp
> 
> Commit 717a7f52f87a25fcacbf52db044e6e5d427227f3 by spestov:
> Sema: Compute RequirementEnvironment when we are matching a witness
> 
> edit: lib/Sema/TypeCheckProtocol.cpp
> 
> Commit 861c46c218868d485fce313a7a0d543335c95ffd by spestov:
> Sema: Track if the protocol witness for a class conformance is in a
> 
> edit: lib/Sema/TypeCheckProtocol.cpp
> 
> Commit 5afaadfbc8b191660f3ab8c206d4624bb191953f by spestov:
> Sema: Requirement environments for protocol extension members in class
> 
> edit: lib/Sema/TypeCheckProtocol.cpp
> edit: test/Interpreter/protocol_extensions.swift
> edit: test/SILGen/protocol_extensions.swift
> edit: test/SILGen/witnesses_class.swift
> 
> Commit 7bc5ac1248bdbbb8a434718fb1cabb45c9017eac by spestov:
> Sema: Factor out ConformanceChecker::checkNonFinalClassWitness() from
> 
> edit: lib/Sema/TypeCheckProtocol.cpp
> 
> Commit d7dbc23337bcb37ab3a495236c3edb0e068b80c5 by spestov:
> Sema: ConformanceChecker::Adoptee is always nominal
> 
> edit: lib/Sema/TypeCheckProtocol.cpp
> 
> Commit 7cbd0c0b3708b7895872b3f09eb9426c08a03580 by spestov:
> Sema: Lift restriction on classes conforming to protocols with default
> 
> edit: include/swift/AST/DiagnosticsSema.def
> add: test/decl/protocol/conforms/self.swift
> edit: lib/Sema/TypeCheckProtocol.cpp
> 
> Commit e96352661bd43cce73b503b8931efeef8b37d929 by spestov:
> Fix REQUIRES: line in
> 
> edit: 
> validation-test/compiler_crashers_fixed/26725-llvm-smallvectorimpl-swift-diagnosticargument-operator.swift
> 
> Commit a3c4882bec68f04855564184411125ca4780cd5f by spestov:
> Sema: Temporary workaround for recently-introduced GSB bug
> 
> edit: lib/Sema/TypeCheckProtocol.cpp

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

Re: [swift-dev] Reducing array abstraction

[Slava Pestov via swift-dev]

> On Oct 7, 2017, at 2:01 PM, Chris Lattner  wrote:
> 
> Right.  If we ignore source compatibility for the moment, it seems clear that 
> the best callee side representation for varargs is a borrowing array slice 
> (like llvm::ArrayRef or UnsafeBufferPointer).  This provides the essential 
> abstraction needed by varargs without forcing an onerous representation on 
> the caller, and without implying any reference counting operations.  This 
> would allow passing an Array, an ArraySlice, a StaticArray, or anything else 
> with contiguous elements.
> 
>> What if I declare my vararg as shared:
>> 
>> func takesArgs(_ xs: shared Int…)
> 
> This seems like a great way to address the source compatibility issue: a 
> normal varargs argument could be passed as an Array for compatibility with 
> existing source, and a “borrowed Int…” could be passed more efficiently, 
> allowing folks to opt into that.

I talked about this with Joe today and he came up with an excellent idea.

We could still change the ABI for varargs so that at the SIL level, the caller 
passes an UnsafePointer to a stack allocated buffer together with an element 
count, instead of a reference to the array. Then, as a transitional step, we 
could have the callee just always first box the varargs into a heap-allocated 
Swift.Array on entry into the function.

This has the advantage that it gives us a better ABI going forward without 
impacting source compatibility. Then we can design “tear-off arrays” or 
whatever we want to do there later, and stage the new behavior in with a new 
keyword, -swift-version flag or some implementation that maintains perfect 
backward compatibility with the current semantics.

Also, even without the language change, constructing the vararg array inside 
the callee will theoretically allow the optimizer to optimize it better, 
eliminating the heap allocation or performing scalar replacement on array 
elements.

What do you think? It would be a great project for an external contributor who 
is already familiar with the code base ;-)

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

Re: [swift-dev] Failure: Swift master branch build failing on x86 (Ubuntu 16.04).

[Slava Pestov via swift-dev]

Hi Atul,

The master branch is tested in CI, so any build failures are likely due to 
configuration problems on your end. While testing the swift-4.0-branch would 
provide an interesting data point, I would not expect it to work if building 
master fails.

Slava

> On Oct 8, 2017, at 10:35 PM, Atul Sowani via swift-dev  
> wrote:
> 
> I still have no luck building swift on x86 using the master branch. Is it 
> recommended to use the master branch at all (considering a lot of fixes would 
> be coming in) or is it desirable to use 4.0 branch instead as a general rule?
> 
> Thanks,
> Atul.
> 
> On Fri, Oct 6, 2017 at 7:03 PM, Atul Sowani via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> Thanks Alex! I used the clean/reset command and then tried rebuilding it, but 
> got the very same error. I am using master branch, latest (top-of-the-tree) 
> version:
> 
> git clone https://github.com/apple/swift.git 
> 
> ./swift/utils/update-checkout --clone
> cd swift
> utils/build-script -c -m -R --verbose-build
> 
> Hope this is correct.
> 
> Thanks,
> Atul.
> 
> On Fri, Oct 6, 2017 at 5:51 PM, Alex Blewitt  > wrote:
> 
> 
> > On 6 Oct 2017, at 12:42, Atul Sowani via swift-dev  > > wrote:
> >
> > Hi,
> >
> > Swift "master" branch is failing to build on x86 running Ubuntu 16,04 with 
> > following error.
> 
> Most of the recent builds appear to be working:
> 
> https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-linux-ubuntu-16_04-master-next/
>  
> 
> 
> > I am using following build command from inside swift-source/swift directory:
> > utils/build-script -c -m -R --verbose-build
> 
> What version of the 'swift' project do you have checked out? Have you done a 
> clean/reset to make sure those aren't issues at the moment?
> 
> You can run swift/utils/update-checkout --clean --reset-to-remote --scheme 
> master (which will get rid of any cruft if you haven't got anything you need 
> to keep) and then re-run the build to see if that resolves the errors.
> 
> Alex
> 
> 
> ___
> 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] Reducing array abstraction

[Slava Pestov via swift-dev]

> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev 
>  wrote:
> 
> This question is somewhere between swift-dev and swift-users, not sure where 
> best to post this.  
> 
> I’m working on a project that wants to get very low-abstraction penalty array 
> operations, particularly with varargs.

It’s awesome to hear you’re still using Swift ;-)

>  Given the currently language limitations (no fixed size arrays), the best 
> I’ve been able to come up with is something like this, where “lowlevelAPI” 
> contains the heavy lifting (and is assumed to be opaque), and the “safeAPI” 
> wrappers exist merely to provide a convenient safe wrapper for clients:
> 
> 
> 
> Given whole module optimization of the program, we should in principle, be 
> able to optimize this down to the equivalent of an LLVM array alloca in the 
> clients, a few stores to it, then passing the pointers to the LLVM alloca 
> into lowlevelAPI.  However, Swift is not doing this, not even with:
> 
> $ swiftc array_abstraction.swift -emit-sil -o - -O 
> 
> In this trivial case (with constant initializers) it does do the “array 
> outlining” optimization, but this is no where near the abstraction level it 
> could be.
> 
> Is there a better way to achieve this, and if not, is there any planned work 
> (perhaps aligned with the ABI stability efforts) to improve vararg array 
> performance to be able to avoid heap abstractions?  Any individual call to a 
> vararg array is a known length, so it is a perfect candidate for a stack 
> allocation.

In fact I filed an internal radar about this a while ago, but the discussion 
didn’t go anywhere because we had bigger fish to fry. I think the main 
difficulty is that we would need some kind of “copy-on-escape” sequence type. 
Iterating over the vararg inside the callee should be efficient, but if I then 
take the value and store it somewhere else, it would need to copy the buffer 
from the stack to the heap.

Also there were source stability implications because people assume the vararg 
argument inside the function body is literally a Swift.Array.

Perhaps the work being done on ownership can help here though. In the ownership 
manifesto, John describes a ‘shared’ attribute on function parameters. What if 
I declare my vararg as shared:

func takesArgs(_ xs: shared Int…)

This means the caller is passing along a borrowed value, not the value itself. 
With today’s vararg implementation this would just pass the Array at +0, 
but perhaps this can be the extension point where we introduce the 
stack-allocated varargs that you propose, and say that a ‘shared’ vararg 
argument actually has a more efficient representation. This allows it to be 
introduced additively without breaking ABI or source compatibility.

What do you think?

Slava


> 
> -Chris
> 
> 
> ___
> 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] Should non-final classes be allowed to conform to Collection?

[Slava Pestov via swift-dev]

Actually I think I figured out a solution. If the witness has ‘Self’ in a 
non-covariant position, we use the concrete type for Self. Otherwise, we do it 
the new way. This makes both examples in 
https://gist.github.com/slavapestov/f455c6184b402f3ffc656f904f1e5d59 
<https://gist.github.com/slavapestov/f455c6184b402f3ffc656f904f1e5d59> work.

Sorry for the noise!

Slava

> On Oct 6, 2017, at 12:46 AM, Slava Pestov  wrote:
> 
> I just tried this and it causes major breakage with associated type inference 
> and the expression checker so its probably more trouble than its worth.
> 
> So back to the three options:
> 
> 1) Do nothing, and give up on fixing https://bugs.swift.org/browse/SR-617 
> <https://bugs.swift.org/browse/SR-617> for now
> 2) Finish https://github.com/apple/swift/pull/12174 
> <https://github.com/apple/swift/pull/12174> and make the new semantics only 
> take effect in -swift-version 5
> 3) ??? Magic
> 
> Slava
> 
>> On Oct 6, 2017, at 12:37 AM, Slava Pestov > <mailto:spes...@apple.com>> wrote:
>> 
>> Another solution is to change the Collection protocol as follows,
>> 
>> protocol Collection {
>>   associatedtype ConformingType = Self
>>   associatedtype Iterator = IndexingIterator
>> 
>>   …
>> }
>> 
>> extension Collection where Iterator == IndexingIterator {
>>   func makeIterator() -> IndexingIterator { … }
>> }
>> 
>> I believe this will fix the source compatibility issue and also make ‘for x 
>> in Derived()’ type check. The downside is that the witness table for a 
>> Collection conformance now stores an additional associated type for the 
>> static conforming class type. However that’s exactly what you need to store 
>> somewhere to make this work for non-final classes.
>> 
>> Slava
>> 
>>> On Oct 6, 2017, at 12:25 AM, Slava Pestov via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Consider this code,
>>> 
>>> class Base : Collection {
>>>   var startIndex: Int { return 0 }
>>> 
>>>   var endIndex: Int { return 10 }
>>> 
>>>   func index(after i: Int) -> Int { return i + 1 }
>>> 
>>>   subscript(index: Int) -> Int { return index }
>>> }
>>> 
>>> We infer the associated type ‘Iterator’ as ‘IndexingIterator’. I can 
>>> use an instance of Base as a sequence just fine:
>>> 
>>> for x in Base() {} // OK
>>> 
>>> Now if I subclass Base, the associated type is still 
>>> ‘IndexingIterator’:
>>> 
>>> class Derived : Base {}
>>> 
>>> However the implementation of makeIterator is defined in a constrained 
>>> extension by the standard library,
>>> 
>>> extension Collection where Self.Iterator == IndexingIterator {
>>>   func makeIterator() -> IndexingIterator { … }
>>> }
>>> 
>>> So I cannot call it on a subclass:
>>> 
>>> for x in Derived() {} // fails
>>> 
>>> The error is bizarre, "'IndexingIterator' is not convertible to 
>>> 'IndexingIterator’” — I’m not doing a conversion here.
>>> 
>>> If you try to call makeIterator() directly, you get an ambiguity error 
>>> instead:
>>> 
>>> col.swift:17:5: error: ambiguous reference to member 'makeIterator()'
>>> _ = Derived().makeIterator()
>>> ^
>>> Swift.Collection:6:17: note: found this candidate
>>> public func makeIterator() -> IndexingIterator
>>> ^
>>> Swift.Sequence:5:17: note: found this candidate
>>> public func makeIterator() -> Self
>>> ^
>>> 
>>> Now I couldn’t come up with an example where the code compiles but crashes 
>>> at runtime because of a type mismatch, but it’s not outside the realm of 
>>> possibility.
>>> 
>>> With my PR here the conformance itself no longer type checks: 
>>> https://github.com/apple/swift/pull/12174 
>>> <https://github.com/apple/swift/pull/12174>
>>> 
>>> col.swift:1:7: error: type 'Base' does not conform to protocol 'Collection'
>>> class Base : Collection {
>>>   ^
>>> Swift.Sequence:5:17: note: candidate has non-matching type ' () -> 
>>> Self' [with Element = Int, Index = Int, IndexDistance = Int, Iterator = 
>>> IndexingIterator, SubSequence = Slice, Indices = 
>>> DefaultIndices]
>>>

Re: [swift-dev] Should non-final classes be allowed to conform to Collection?

[Slava Pestov via swift-dev]

I just tried this and it causes major breakage with associated type inference 
and the expression checker so its probably more trouble than its worth.

So back to the three options:

1) Do nothing, and give up on fixing https://bugs.swift.org/browse/SR-617 
<https://bugs.swift.org/browse/SR-617> for now
2) Finish https://github.com/apple/swift/pull/12174 
<https://github.com/apple/swift/pull/12174> and make the new semantics only 
take effect in -swift-version 5
3) ??? Magic

Slava

> On Oct 6, 2017, at 12:37 AM, Slava Pestov  wrote:
> 
> Another solution is to change the Collection protocol as follows,
> 
> protocol Collection {
>   associatedtype ConformingType = Self
>   associatedtype Iterator = IndexingIterator
> 
>   …
> }
> 
> extension Collection where Iterator == IndexingIterator {
>   func makeIterator() -> IndexingIterator { … }
> }
> 
> I believe this will fix the source compatibility issue and also make ‘for x 
> in Derived()’ type check. The downside is that the witness table for a 
> Collection conformance now stores an additional associated type for the 
> static conforming class type. However that’s exactly what you need to store 
> somewhere to make this work for non-final classes.
> 
> Slava
> 
>> On Oct 6, 2017, at 12:25 AM, Slava Pestov via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> Hi all,
>> 
>> Consider this code,
>> 
>> class Base : Collection {
>>   var startIndex: Int { return 0 }
>> 
>>   var endIndex: Int { return 10 }
>> 
>>   func index(after i: Int) -> Int { return i + 1 }
>> 
>>   subscript(index: Int) -> Int { return index }
>> }
>> 
>> We infer the associated type ‘Iterator’ as ‘IndexingIterator’. I can 
>> use an instance of Base as a sequence just fine:
>> 
>> for x in Base() {} // OK
>> 
>> Now if I subclass Base, the associated type is still 
>> ‘IndexingIterator’:
>> 
>> class Derived : Base {}
>> 
>> However the implementation of makeIterator is defined in a constrained 
>> extension by the standard library,
>> 
>> extension Collection where Self.Iterator == IndexingIterator {
>>   func makeIterator() -> IndexingIterator { … }
>> }
>> 
>> So I cannot call it on a subclass:
>> 
>> for x in Derived() {} // fails
>> 
>> The error is bizarre, "'IndexingIterator' is not convertible to 
>> 'IndexingIterator’” — I’m not doing a conversion here.
>> 
>> If you try to call makeIterator() directly, you get an ambiguity error 
>> instead:
>> 
>> col.swift:17:5: error: ambiguous reference to member 'makeIterator()'
>> _ = Derived().makeIterator()
>> ^
>> Swift.Collection:6:17: note: found this candidate
>> public func makeIterator() -> IndexingIterator
>> ^
>> Swift.Sequence:5:17: note: found this candidate
>> public func makeIterator() -> Self
>> ^
>> 
>> Now I couldn’t come up with an example where the code compiles but crashes 
>> at runtime because of a type mismatch, but it’s not outside the realm of 
>> possibility.
>> 
>> With my PR here the conformance itself no longer type checks: 
>> https://github.com/apple/swift/pull/12174 
>> <https://github.com/apple/swift/pull/12174>
>> 
>> col.swift:1:7: error: type 'Base' does not conform to protocol 'Collection'
>> class Base : Collection {
>>   ^
>> Swift.Sequence:5:17: note: candidate has non-matching type ' () -> 
>> Self' [with Element = Int, Index = Int, IndexDistance = Int, Iterator = 
>> IndexingIterator, SubSequence = Slice, Indices = 
>> DefaultIndices]
>> public func makeIterator() -> Self
>> ^
>> Swift.Collection:6:17: note: candidate has non-matching type ' () -> 
>> IndexingIterator' [with Element = Int, Index = Int, IndexDistance = 
>> Int, Iterator = IndexingIterator, SubSequence = Slice, Indices = 
>> DefaultIndices]
>> public func makeIterator() -> IndexingIterator
>> 
>> I found one example in our code base where this pattern comes up, and that’s 
>> SyntaxCollection in tools/SwiftSyntax/SyntaxCollection.swift. It has no 
>> subclasses so making it final works there.
>> 
>> This was reported externally as https://bugs.swift.org/browse/SR-1863 
>> <https://bugs.swift.org/browse/SR-1863>. I’m not sure if the user expects it 
>> to work or just to produce a reasonable diagnostic instructing them to make 
>> the class fin

Re: [swift-dev] Should non-final classes be allowed to conform to Collection?

[Slava Pestov via swift-dev]

Another solution is to change the Collection protocol as follows,

protocol Collection {
  associatedtype ConformingType = Self
  associatedtype Iterator = IndexingIterator

  …
}

extension Collection where Iterator == IndexingIterator {
  func makeIterator() -> IndexingIterator { … }
}

I believe this will fix the source compatibility issue and also make ‘for x in 
Derived()’ type check. The downside is that the witness table for a Collection 
conformance now stores an additional associated type for the static conforming 
class type. However that’s exactly what you need to store somewhere to make 
this work for non-final classes.

Slava

> On Oct 6, 2017, at 12:25 AM, Slava Pestov via swift-dev  
> wrote:
> 
> Hi all,
> 
> Consider this code,
> 
> class Base : Collection {
>   var startIndex: Int { return 0 }
> 
>   var endIndex: Int { return 10 }
> 
>   func index(after i: Int) -> Int { return i + 1 }
> 
>   subscript(index: Int) -> Int { return index }
> }
> 
> We infer the associated type ‘Iterator’ as ‘IndexingIterator’. I can 
> use an instance of Base as a sequence just fine:
> 
> for x in Base() {} // OK
> 
> Now if I subclass Base, the associated type is still ‘IndexingIterator’:
> 
> class Derived : Base {}
> 
> However the implementation of makeIterator is defined in a constrained 
> extension by the standard library,
> 
> extension Collection where Self.Iterator == IndexingIterator {
>   func makeIterator() -> IndexingIterator { … }
> }
> 
> So I cannot call it on a subclass:
> 
> for x in Derived() {} // fails
> 
> The error is bizarre, "'IndexingIterator' is not convertible to 
> 'IndexingIterator’” — I’m not doing a conversion here.
> 
> If you try to call makeIterator() directly, you get an ambiguity error 
> instead:
> 
> col.swift:17:5: error: ambiguous reference to member 'makeIterator()'
> _ = Derived().makeIterator()
> ^
> Swift.Collection:6:17: note: found this candidate
> public func makeIterator() -> IndexingIterator
> ^
> Swift.Sequence:5:17: note: found this candidate
> public func makeIterator() -> Self
> ^
> 
> Now I couldn’t come up with an example where the code compiles but crashes at 
> runtime because of a type mismatch, but it’s not outside the realm of 
> possibility.
> 
> With my PR here the conformance itself no longer type checks: 
> https://github.com/apple/swift/pull/12174 
> <https://github.com/apple/swift/pull/12174>
> 
> col.swift:1:7: error: type 'Base' does not conform to protocol 'Collection'
> class Base : Collection {
>   ^
> Swift.Sequence:5:17: note: candidate has non-matching type ' () -> 
> Self' [with Element = Int, Index = Int, IndexDistance = Int, Iterator = 
> IndexingIterator, SubSequence = Slice, Indices = 
> DefaultIndices]
> public func makeIterator() -> Self
> ^
> Swift.Collection:6:17: note: candidate has non-matching type ' () -> 
> IndexingIterator' [with Element = Int, Index = Int, IndexDistance = 
> Int, Iterator = IndexingIterator, SubSequence = Slice, Indices = 
> DefaultIndices]
> public func makeIterator() -> IndexingIterator
> 
> I found one example in our code base where this pattern comes up, and that’s 
> SyntaxCollection in tools/SwiftSyntax/SyntaxCollection.swift. It has no 
> subclasses so making it final works there.
> 
> This was reported externally as https://bugs.swift.org/browse/SR-1863 
> <https://bugs.swift.org/browse/SR-1863>. I’m not sure if the user expects it 
> to work or just to produce a reasonable diagnostic instructing them to make 
> the class final.
> 
> What does everyone think of this?
> 
> 1) Can anyone suggest a way to make it work, so that ‘for x in Derived()’ 
> type checks and the correct Self type (Base, not Derived) for the 
> substitution?
> 
> 2) Should we just ban such ’non-covariant’ conformances? There is precedent 
> for this — in Swift 3, we used to allow non-final classes to conform to 
> protocols whose requirements had same-type constraints with the right hand 
> side equal to ‘Self’, and Doug closed this hole in Swift 4. My PR is 
> essentially a more comprehensive fix for this hole.
> 
> 3) Should we allow the hole to remain in place, admitting non-final classes 
> that model Collection, at the cost of not being able to ever fix 
> https://bugs.swift.org/browse/SR-617 <https://bugs.swift.org/browse/SR-617>?
> 
> Slava
> 
> ___
> 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] Should non-final classes be allowed to conform to Collection?

[Slava Pestov via swift-dev]

Hi all,

Consider this code,

class Base : Collection {
  var startIndex: Int { return 0 }

  var endIndex: Int { return 10 }

  func index(after i: Int) -> Int { return i + 1 }

  subscript(index: Int) -> Int { return index }
}

We infer the associated type ‘Iterator’ as ‘IndexingIterator’. I can use 
an instance of Base as a sequence just fine:

for x in Base() {} // OK

Now if I subclass Base, the associated type is still ‘IndexingIterator’:

class Derived : Base {}

However the implementation of makeIterator is defined in a constrained 
extension by the standard library,

extension Collection where Self.Iterator == IndexingIterator {
  func makeIterator() -> IndexingIterator { … }
}

So I cannot call it on a subclass:

for x in Derived() {} // fails

The error is bizarre, "'IndexingIterator' is not convertible to 
'IndexingIterator’” — I’m not doing a conversion here.

If you try to call makeIterator() directly, you get an ambiguity error instead:

col.swift:17:5: error: ambiguous reference to member 'makeIterator()'
_ = Derived().makeIterator()
^
Swift.Collection:6:17: note: found this candidate
public func makeIterator() -> IndexingIterator
^
Swift.Sequence:5:17: note: found this candidate
public func makeIterator() -> Self
^

Now I couldn’t come up with an example where the code compiles but crashes at 
runtime because of a type mismatch, but it’s not outside the realm of 
possibility.

With my PR here the conformance itself no longer type checks: 
https://github.com/apple/swift/pull/12174 


col.swift:1:7: error: type 'Base' does not conform to protocol 'Collection'
class Base : Collection {
  ^
Swift.Sequence:5:17: note: candidate has non-matching type ' () -> Self' 
[with Element = Int, Index = Int, IndexDistance = Int, Iterator = 
IndexingIterator, SubSequence = Slice, Indices = 
DefaultIndices]
public func makeIterator() -> Self
^
Swift.Collection:6:17: note: candidate has non-matching type ' () -> 
IndexingIterator' [with Element = Int, Index = Int, IndexDistance = Int, 
Iterator = IndexingIterator, SubSequence = Slice, Indices = 
DefaultIndices]
public func makeIterator() -> IndexingIterator

I found one example in our code base where this pattern comes up, and that’s 
SyntaxCollection in tools/SwiftSyntax/SyntaxCollection.swift. It has no 
subclasses so making it final works there.

This was reported externally as https://bugs.swift.org/browse/SR-1863 
. I’m not sure if the user expects it to 
work or just to produce a reasonable diagnostic instructing them to make the 
class final.

What does everyone think of this?

1) Can anyone suggest a way to make it work, so that ‘for x in Derived()’ type 
checks and the correct Self type (Base, not Derived) for the substitution?

2) Should we just ban such ’non-covariant’ conformances? There is precedent for 
this — in Swift 3, we used to allow non-final classes to conform to protocols 
whose requirements had same-type constraints with the right hand side equal to 
‘Self’, and Doug closed this hole in Swift 4. My PR is essentially a more 
comprehensive fix for this hole.

3) Should we allow the hole to remain in place, admitting non-final classes 
that model Collection, at the cost of not being able to ever fix 
https://bugs.swift.org/browse/SR-617 ?

Slava

___
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.04 (master) #897

[Slava Pestov via swift-dev]

We keep seeing this failure in the bots:

src/libdispatch.so: error: undefined reference to 
‘_T0s17_assertionFailures5NeverOs12StaticStringV_SSAE4fileSu4lines6UInt32V5flagstFTfq4nxnnn_n'

A clean build fixes it. However, it comes back, because if the bot builds the 
4.0 branch and then goes and builds master, the problem returns.

Can somebody look at this?

Slava

> On Oct 5, 2017, at 10:11 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#897]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/897/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Fri, 06 Oct 2017 00:05:17 -0500
> Build duration:   7 min 26 sec
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9964 test(s), Total: 9964 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 483 test(s), Total: 483 test(s)
> 
> Changes
> 
> Commit c272d41e2f392d2b97c9bd55d819be67912f01d0 by spestov:
> Re-apply "SIL: Remove special meaning for
> 
> edit: stdlib/public/core/REPL.swift
> edit: stdlib/public/core/AssertCommon.swift
> edit: stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb
> edit: test/SILOptimizer/Inputs/linker_pass_input.swift
> edit: stdlib/public/core/Print.swift
> edit: stdlib/public/core/StringBridge.swift
> edit: stdlib/public/core/StringComparable.swift
> edit: test/SILOptimizer/string_switch.swift
> edit: stdlib/public/core/StringSwitch.swift
> edit: stdlib/public/core/HashedCollections.swift.gyb
> edit: lib/SILOptimizer/Utils/Local.cpp
> edit: stdlib/public/core/DebuggerSupport.swift
> edit: lib/SIL/Linker.cpp
> edit: test/SILOptimizer/linker.swift
> edit: docs/HighLevelSILOptimizations.rst
> edit: stdlib/public/core/StringHashable.swift
> delete: test/SILOptimizer/specialization_of_stdlib_binary_only.swift
> edit: stdlib/public/core/OutputStream.swift
> edit: lib/SILOptimizer/IPO/GlobalOpt.cpp
> 
> Commit 5e67f755e044f7a3c143f85c3f1b73d9c1043939 by rlevenstein:
> Remove the -sil-serialize-all option
> 
> edit: lib/Frontend/CompilerInvocation.cpp
> edit: lib/SILGen/SILGen.h
> edit: lib/Serialization/SerializeSIL.cpp
> edit: stdlib/private/StdlibCollectionUnittest/CMakeLists.txt
> edit: include/swift/SIL/SILModule.h
> edit: include/swift/AST/SILOptions.h
> edit: stdlib/private/StdlibUnicodeUnittest/CMakeLists.txt
> edit: include/swift/Option/FrontendOptions.td
> edit: lib/SILGen/SILGenType.cpp
> edit: lib/Frontend/Frontend.cpp
> edit: stdlib/private/StdlibUnittest/CMakeLists.txt
> edit: docs/Lexicon.rst
> edit: lib/FrontendTool/FrontendTool.cpp
> 
> Commit dd85e69e7fa36c132a6af0a2abad80ca85127c33 by rlevenstein:
> Update the tests after removing the -sil-serialize-all option
> 
> edit: test/SIL/Serialization/Inputs/nontransparent.swift
> edit: test/Serialization/always_inline.swift
> edit: test/Serialization/witnesstable-function-deserialization.swift
> edit: test/Serialization/resilience.swift
> edit: test/SIL/Serialization/deserialize_generic.sil
> edit: test/SIL/Serialization/perf_inline_without_inline_all.swift
> edit: test/SIL/Serialization/visibility.sil
> edit: test/Serialization/noinline.swift
> edit: test/SIL/Serialization/witness_tables.sil
> edit: test/SIL/Serialization/Inputs/vtable_deserialization_input.swift
> edit: utils/swift-project-settings.el
> edit: 
> test/SIL/Serialization/init_existential_inst_deserializes_witness_tables.swift
> edit: test/SIL/Serialization/specializer_can_deserialize.swift
> edit: test/sil-func-extractor/load-serialized-sil.swift
> edit: test/SILGen/witness_tables_serialized.swift
> edit: test/Serialization/duplicate_normalprotocolconformance.swift
> edit: test/sil-opt/sil-opt.swift
> edit: test/Serialization/basic_sil_objc.swift
> edit: test/SILGen/Inputs/ModuleA.swift
> edit: test/Serialization/default-witness-table-deserialization.swift
> edit: test/SIL/Serialization/function_param_convention.sil
> edit: test/SILGen/Inputs/ModuleB.swift
> edit: test/Serialization/basic_sil.swift
> edit: test/Serialization/global_init.swift
> edit: test/SIL/Serialization/shared_function_serialization.sil
> edit: test/Serialization/Inputs/def_noinline.swift
> edit: test/SILOptimizer/dead_witness_module.swift
> edit: test/Serialization/Inputs/def_basic.sil
> edit: test/Serialization/serialize_attr.swift
> edit: test/SIL/Serialization/projection_lowered_type_parse.sil
> edit: test/SIL/Serialization/deserialize_generic_marker.sil
> edit: test/SIL/Serialization/Inputs/def_generic_marker.swift
> edit: test/SILOptimizer/specialize_cg_update_crash.sil
> edit: test/SIL/Serialization/Inputs/def_generic.swift
> edi

Re: [swift-dev] Builtin.loadRaw

[Slava Pestov via swift-dev]

Hi Sam,

The builtin is defined in lib/SILGen/SILGenBuiltin.cpp, look for the function 
named emitBuiltinLoadRaw().

However I suspect the problem in this case is not that the builtin is 
implemented incorrectly (it eventually lowers to an LLVM load instruction) but 
that something further upstream is going wrong, perhaps with alignment or 
endianness.

Can you tell us which unit tests are failing specifically?

Slava

> On Sep 28, 2017, at 2:16 PM, Sam Ding via swift-dev  
> wrote:
> 
> I am testing a test case "KeyPath.swift" on s390x for v4.0 . It is found that 
> " Builtin.loadRaw" as the below of 
> "stdlib/public/core/UnsafeRawPointer.swift.gyb" returns a different value 
> than that on x86-64. 
> @_inlineable
> public func load(fromByteOffset offset: Int = 0, as type: T.Type) -> T {
> _debugPrecondition(0 == (UInt(bitPattern: self + offset)
> & (UInt(MemoryLayout.alignment) - 1)),
> "load from misaligned raw pointer")
> 
> return Builtin.loadRaw((self + offset)._rawValue) // return a different value 
> on s390x vs x86-64
> }
> My debugger (lldb) does not guide me to the detailed of " Builtin.loadRaw". 
> Searching "loadRaw" and finding
> swift/include/swift/AST/Builtins.def:BUILTIN_SIL_OPERATION(LoadRaw, 
> "loadRaw", Special)
> 
> But I could not find the definition of this "LoadRaw" from the whole swift v4.
> Can anyone give me a hint where its implementation is?
> 
> Thanks,
> 
> 
> Sam Ding,
> Linux on z Systems Open Source Ecosystem
> IBM Toronto Lab, 
> email: samd...@ca.ibm.com
> phone: (905)413-2947
> ___
> 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 - Long Test (master) #816

[Slava Pestov via swift-dev]

You’re right, because it’s due to my changes. This should fix it: 
https://github.com/apple/swift/pull/12131 


Slava

> On Sep 26, 2017, at 1:13 PM, Pavel Yaskevich via swift-dev 
>  wrote:
> 
> Hi guys,
> 
>This doesn’t seem to be caused by my changes - test failure is at 
> runtime/./SwiftRuntimeTests/MetadataTest.getGenericMetadata
> 
> Best Regards, Pavel.
> 
>> On Sep 26, 2017, at 1:01 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#816]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/816/
>>  
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04-long-test
>> Date of build:   Tue, 26 Sep 2017 14:18:11 -0500
>> Build duration:  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 80e4a2226b4c11cffeef49b9ab58dc3336644544 by pyaskevich:
>> [ConstraintGraph] Don't try to contract edge of parameter bindings with
>> 
>> edit: lib/Sema/CSBindings.cpp
>> edit: test/Constraints/closures.swift
>> edit: lib/Sema/ConstraintGraph.cpp
>> edit: lib/Sema/CSSolver.cpp
>> edit: test/Sema/immutability.swift
>> edit: lib/Sema/CSSimplify.cpp
>> delete: validation-test/Sema/type_checker_perf/fast/rdar22282851.swift
>> add: validation-test/Sema/type_checker_perf/slow/rdar22282851.swift
>> edit: lib/Sema/ConstraintSystem.h
> 
> ___
> 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: 1. OSS - Swift ASAN - OS X (master) #293

[Slava Pestov via swift-dev]

This should fix it: https://github.com/apple/swift/pull/12119 
<https://github.com/apple/swift/pull/12119>

Slava

> On Sep 25, 2017, at 9:55 PM, Slava Pestov via swift-dev  
> wrote:
> 
> This is from my changes. I think I know what the problem is, I’ll test a fix 
> now.
> 
> Slava
> 
>> On Sep 25, 2017, at 9:38 PM, no-re...@swift.org <mailto:no-re...@swift.org> 
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-ASAN-RA-osx [#293]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/293/ 
>> <https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/293/>
>> Project: oss-swift-incremental-ASAN-RA-osx
>> Date of build:   Mon, 25 Sep 2017 20:02:29 -0500
>> Build duration:  3 hr 36 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 
>> <https://ci.swift.org//job/oss-swift-incremental-ASAN-RA-osx/293/consoleFull#753924207ba62d58e-7248-467b-91e0-c7508d5cf947>
>> Tests:
>> 
>> Name: Swift(macosx-x86_64)
>> Failed: 0 test(s), Passed: 9927 test(s), Total: 9927 test(s)
>> Name: Swift-Unit
>> Failed: 1 test(s), Passed: 523 test(s), Total: 524 test(s)
>> Failed: 
>> Swift-Unit.runtime/_/SwiftRuntimeTests.MetadataTest.getGenericMetadata 
>> <https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/293/testReport/junit/Swift-Unit/runtime___SwiftRuntimeTests/MetadataTest_getGenericMetadata>
>> 
>> Changes
>> 
>> Commit 5fe76898d53255a1bbb50afe72a333b198b03ccf by lance_parker:
>> Make Bool conform to CVarArg protocol
>> 
>> edit: stdlib/public/core/VarArgs.swift
>> 
>> Commit 6056ebede18f76b319fad8c7e41304c88ab2cf60 by lance_parker:
>> Add tests for Bool’s conformance to CVarArg
>> 
>> add: test/stdlib/Inputs/VariadicBool/module.map
>> add: test/stdlib/Inputs/VariadicBool/variadicBool.h
>> add: test/stdlib/Inputs/VariadicBool/variadicBool.c
>> add: validation-test/stdlib/BoolDiagnostics.swift
>> add: validation-test/stdlib/Bool.swift
>> 
>> Commit 9fa2cc819228b32465cf831a006ea584b1a9b07e by lance_parker:
>> removed uneeded compiler flags
>> 
>> edit: validation-test/stdlib/Bool.swift
>> 
>> Commit 59f7bfe50245e41e4b9548c705252a6dece4966c by rlevenstein:
>> Provide a comment clarifying why there could be an infinite loop and how
>> 
>> edit: lib/SIL/SILBuilder.cpp
>> 
>> Commit 9745ec82693f7b4498aaf17a8bc6e187d16fa366 by rjmccall:
>> Build fix for LLDB: resolve ambiguity with operator delete so that
>> 
>> edit: include/swift/SIL/SILInstruction.h
>> 
>> Commit 07b92322350807d66022f7546be10752884291e1 by lance_parker:
>> Correctly handle big endian systems, updated the comment for va_arg
>> 
>> edit: validation-test/stdlib/Bool.swift
>> edit: stdlib/public/core/VarArgs.swift
>> edit: test/stdlib/Inputs/VariadicBool/variadicBool.c
>> 
>> Commit 9880d8eb9c4886c092991a2142490746faf956ea by eeckstein:
>> Fix output of function name in crash trace.
>> 
>> edit: lib/SILOptimizer/PassManager/PassManager.cpp
>> 
>> Commit 1b960d58b7f28c2bd6e92aac5546b338e5d16531 by mgottesman:
>> [benchmark] Extract multisource benchmark cmake code into helper
>> 
>> edit: benchmark/cmake/modules/AddSwiftBenchmarkSuite.cmake
>> 
>> Commit 5dfbec05c4bff40074d833993ebb8797aab0df08 by mgottesman:
>> [benchmark] Allow for swift3 and swift4 multi source benchmarks
>> 
>> edit: benchmark/cmake/modules/AddSwiftBenchmarkSuite.cmake
>> edit: benchmark/CMakeLists.txt
>> 
>> Commit 5707014b2e6bc946a753474275edacc4b21fc679 by spestov:
>> IRGen: Remove an unnecessary cast
>> 
>> edit: lib/IRGen/NominalMetadataVisitor.h
>> 
>> Commit 5c0c660727227029ef5c2089f7be8f36e5fae9a1 by spestov:
>> IRGen: Emit nested generic context information in the nominal type
>> 
>> edit: include/swift/Runtime/Metadata.h
>> edit: include/swift/ABI/MetadataValues.h
>> edit: lib/IRGen/GenMeta.cpp
>> edit: test/IRGen/generic_classes.sil
>> edit: test/IRGen/generic_structs.sil
>> edit: test/IRGen/enum.sil
>> edit: test/IRGen/generic_vtable.swift
>> 
>> Commit 704b8566a9555f6e5170ccd442f48f86b8f76388 by spestov:
>> IRGen: Stop fulfilling generic parameters from the parent type
>> 
>> add: test/IRGen/nested_generics.swift
>> edit: lib/IRGen/GenProto.cpp
>> edit: lib/IRGen/GenMeta.cpp
>> 
>> Commit 9bdb71b6143e69284e9ad8bb46553733e5a7064e by spesto

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

[Slava Pestov via swift-dev]

This is from my changes. I think I know what the problem is, I’ll test a fix 
now.

Slava

> On Sep 25, 2017, at 9:38 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-ASAN-RA-osx [#293]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/293/ 
> 
> Project:  oss-swift-incremental-ASAN-RA-osx
> Date of build:Mon, 25 Sep 2017 20:02:29 -0500
> Build duration:   3 hr 36 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 0 test(s), Passed: 9927 test(s), Total: 9927 test(s)
> Name: Swift-Unit
> Failed: 1 test(s), Passed: 523 test(s), Total: 524 test(s)
> Failed: 
> Swift-Unit.runtime/_/SwiftRuntimeTests.MetadataTest.getGenericMetadata 
> 
> 
> Changes
> 
> Commit 5fe76898d53255a1bbb50afe72a333b198b03ccf by lance_parker:
> Make Bool conform to CVarArg protocol
> 
> edit: stdlib/public/core/VarArgs.swift
> 
> Commit 6056ebede18f76b319fad8c7e41304c88ab2cf60 by lance_parker:
> Add tests for Bool’s conformance to CVarArg
> 
> add: test/stdlib/Inputs/VariadicBool/module.map
> add: test/stdlib/Inputs/VariadicBool/variadicBool.h
> add: test/stdlib/Inputs/VariadicBool/variadicBool.c
> add: validation-test/stdlib/BoolDiagnostics.swift
> add: validation-test/stdlib/Bool.swift
> 
> Commit 9fa2cc819228b32465cf831a006ea584b1a9b07e by lance_parker:
> removed uneeded compiler flags
> 
> edit: validation-test/stdlib/Bool.swift
> 
> Commit 59f7bfe50245e41e4b9548c705252a6dece4966c by rlevenstein:
> Provide a comment clarifying why there could be an infinite loop and how
> 
> edit: lib/SIL/SILBuilder.cpp
> 
> Commit 9745ec82693f7b4498aaf17a8bc6e187d16fa366 by rjmccall:
> Build fix for LLDB: resolve ambiguity with operator delete so that
> 
> edit: include/swift/SIL/SILInstruction.h
> 
> Commit 07b92322350807d66022f7546be10752884291e1 by lance_parker:
> Correctly handle big endian systems, updated the comment for va_arg
> 
> edit: validation-test/stdlib/Bool.swift
> edit: stdlib/public/core/VarArgs.swift
> edit: test/stdlib/Inputs/VariadicBool/variadicBool.c
> 
> Commit 9880d8eb9c4886c092991a2142490746faf956ea by eeckstein:
> Fix output of function name in crash trace.
> 
> edit: lib/SILOptimizer/PassManager/PassManager.cpp
> 
> Commit 1b960d58b7f28c2bd6e92aac5546b338e5d16531 by mgottesman:
> [benchmark] Extract multisource benchmark cmake code into helper
> 
> edit: benchmark/cmake/modules/AddSwiftBenchmarkSuite.cmake
> 
> Commit 5dfbec05c4bff40074d833993ebb8797aab0df08 by mgottesman:
> [benchmark] Allow for swift3 and swift4 multi source benchmarks
> 
> edit: benchmark/cmake/modules/AddSwiftBenchmarkSuite.cmake
> edit: benchmark/CMakeLists.txt
> 
> Commit 5707014b2e6bc946a753474275edacc4b21fc679 by spestov:
> IRGen: Remove an unnecessary cast
> 
> edit: lib/IRGen/NominalMetadataVisitor.h
> 
> Commit 5c0c660727227029ef5c2089f7be8f36e5fae9a1 by spestov:
> IRGen: Emit nested generic context information in the nominal type
> 
> edit: include/swift/Runtime/Metadata.h
> edit: include/swift/ABI/MetadataValues.h
> edit: lib/IRGen/GenMeta.cpp
> edit: test/IRGen/generic_classes.sil
> edit: test/IRGen/generic_structs.sil
> edit: test/IRGen/enum.sil
> edit: test/IRGen/generic_vtable.swift
> 
> Commit 704b8566a9555f6e5170ccd442f48f86b8f76388 by spestov:
> IRGen: Stop fulfilling generic parameters from the parent type
> 
> add: test/IRGen/nested_generics.swift
> edit: lib/IRGen/GenProto.cpp
> edit: lib/IRGen/GenMeta.cpp
> 
> Commit 9bdb71b6143e69284e9ad8bb46553733e5a7064e by spestov:
> Runtime: Stop looking at parent type metadata in
> 
> edit: test/stdlib/TypeName.swift
> edit: stdlib/public/runtime/Demangle.cpp
> 
> Commit 61639cf9713aef480be4b8bb05569383cb45216a by spestov:
> RemoteAST: Stop looking at parent metadata field
> 
> edit: include/swift/Reflection/TypeRefBuilder.h
> edit: lib/RemoteAST/RemoteAST.cpp
> edit: include/swift/Remote/MetadataReader.h
> edit: include/swift/Reflection/ReflectionContext.h
> 
> Commit 453a5bc431317659a01e89a1322e7906d2cdf91e by spestov:
> IRGen: Remove Fulfillment::searchParentTypeMetadata()
> 
> edit: lib/IRGen/Fulfillment.cpp
> edit: lib/IRGen/GenProto.cpp
> edit: lib/IRGen/Fulfillment.h
> 
> Commit 0fa9f761b18672bee9528ad490feec02692c6241 by spestov:
> IRGen: Remove NominalParent metadata path component type
> 
> edit: lib/IRGen/GenProto.cpp
> edit: lib/IRGen/MetadataPath.h
> 
> Commit 3ab5b6fa198ddf574323cdbbc1d97c107598c822 by spestov:
> IRGen/Runtime: Remove parent field from type metadata
> 
> edit: test/IRGen/keypaths.sil
> edit: 

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

[Slava Pestov via swift-dev]

For PR testing, a clean build fixed the issue for me.

Slava

> On Sep 19, 2017, at 11:08 AM, Joe Shajrawi via swift-dev 
>  wrote:
> 
> libdispatch is still failing to build on some platforms: 
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10//634/console
>  
> 
> 
> + /usr/bin/cmake --build 
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64
>  -- -j8 all swift-stdlib-linux-x86_64
> [1/58] Performing build step for 'libdispatch'
> FAILED: 
> tools/SourceKit/libdispatch-prefix/src/libdispatch-stamp/libdispatch-build 
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/libdispatch-linux-x86_64/src/libdispatch.so
>  
> cd 
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/libdispatch-linux-x86_64
>  && /usr/bin/cmake --build . && /usr/bin/cmake -E touch 
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/tools/SourceKit/libdispatch-prefix/src/libdispatch-stamp/libdispatch-build
> Error: could not load cache
> [2/58] Building CXX object lib/Basic/CMakeFiles/swiftBasic.dir/Version.cpp.o
> ninja: build stopped: subcommand failed.
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 1, aborting
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 1, aborting
> 
> 
> Regards,
> —Joe |  | 📧 shajr...@apple.com  | 📱(+1) 
> 408-930-5203
> 
> 
> 
>> On Sep 18, 2017, at 7:17 PM, Saleem Abdulrasool > > wrote:
>> 
>> PR#11994
>> 
>> On Mon, Sep 18, 2017 at 7:13 PM, Saleem Abdulrasool via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> Ugh, I think I see what the issue is.  The build-script-impl wrapper is 
>> pretty intricate and I missed the conditional check since it was pretty 
>> similar to the one near it.  I guess the test for the original change didnt 
>> notice it due to caching effects.  I'll have a fix up for this momentarily.
>> 
>> On Mon, Sep 18, 2017 at 6:59 PM, Saleem Abdulrasool via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> Yeah, Im looking into this.  That is a really weird error.  It seems like it 
>> would be related to the the switch to CMake for libdispatch.
>> 
>> On Mon, Sep 18, 2017 at 6:34 PM, Vedant Kumar via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> I don't think I have changed this or control it:
>> --install-destdir is required to install products.
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>>  fatal error: command terminated with a non-zero exit status 1, aborting
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>>  fatal error: command terminated with a non-zero exit status 1, aborting
>> 
>> vedant
>> 
>>> On Sep 18, 2017, at 6:32 PM, no-re...@swift.org  
>>> wrote:
>>> 
>>> New issue found!
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#596]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/596/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_04
>>> Date of build:  Mon, 18 Sep 2017 19:25:52 -0500
>>> Build duration: 1 hr 7 min
>>> Tests:
>>> 
>>> Name: Swift(linux-x86_64)
>>> Failed: 0 test(s), Passed: 9899 test(s), Total: 9899 test(s)
>>> Name: Swift-Unit
>>> Failed: 0 test(s), Passed: 461 test(s), Total: 461 test(s)
>>> 
>>> Changes
>>> 
>>> Commit 7e0311ad2cf4f688518aed84a665b6c8a50eaefc by vsk:
>>> [Coverage] Use gap regions to select better line exec counts
>>> 
>>> edit: include/llvm/ProfileData/InstrProfData.inc
>>> edit: tools/llvm-cov/SourceCoverageViewText.cpp
>>> edit: lib/ProfileData/Coverage/CoverageMappingReader.cpp
>>> edit: lib/ProfileData/Coverage/CoverageMapping.cpp
>>> edit: docs/CoverageMappingFormat.rst
>>> edit: tools/llvm-cov/SourceCoverageViewHTML.cpp
>>> edit: tools/llvm-cov/SourceCoverageView.cpp
>>> edit: include/llvm/ProfileData/Coverage/CoverageMapping.h
>>> edit: test/tools/llvm-cov/deferred-region.cpp
>>> edit: lib/ProfileData/Coverage/CoverageMappingWriter.cpp
>>> edit: test/tools/llvm-cov/Inputs/deferred-regions.covmapping
>>> 
>>> Commit 9a8caaf5b6cd207d61e0867ea46650d45a3e5adf by vsk:
>>> [profile] Update InstrProfData.inc
>>> 
>>> edit: lib/profile/InstrProfData.inc
>>> 
>>> Commit 223e2eacb73b51efd6284bfb15ac1ef9b596a2e6 by vsk:
>>> [cmake] Make it possible to build and test profile without sanitizer

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

[Slava Pestov via swift-dev]

Greg,

Does this look OK?

https://github.com/apple/swift/pull/12002 


> On Sep 19, 2017, at 11:37 AM, no-reply--- via swift-dev  
> wrote:
> 
> [FAILURE] oss-swift-package-osx [#311]
> 
> Build URL:https://ci.swift.org/job/oss-swift-package-osx/311/ 
> 
> Project:  oss-swift-package-osx
> Date of build:Tue, 19 Sep 2017 11:32:26 -0500
> Build duration:   2 hr 5 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit c95598db554f8c36d9a50745c2491936e94e4524 by devteam.codafi:
> Vim plugin: expand highlighting coverage (#11444)
> 
> edit: utils/vim/syntax/swift.vim
> 
> Commit 66b91774c8c0087e4f901877cd713a4e1451 by atrick:
> [sil-opaque-values] Teach the SIL cloner to skip trivial copy/destroy.
> 
> add: test/SILOptimizer/specialize_opaque.sil
> edit: include/swift/SIL/TypeSubstCloner.h
> 
> Commit e272564d63e5e65767a38d13cf26dbf46894ddfb by atrick:
> [sil-opaque-values] Fix UpdateSSA to handle checked_cast_value_br.
> 
> edit: lib/SILOptimizer/Utils/CFG.cpp
> add: test/SILOptimizer/simplify_cfg_opaque.sil
> 
> ___
> 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] Unit tests for the Swift project

[Slava Pestov via swift-dev]

> On Sep 12, 2017, at 11:29 PM, Alwyn Concessao  wrote:
> 
> Okay.I see a couple of Swift files and .gyb files inside test/stdlib.I've 
> made changes to the RangeReplaceableCollection protocol of the Swift 
> stdlib.How can I write unit tests for that?Can I generate an Xcode project 
> for the unit test files?

You can run unit tests by using build-script for example,

./utils/build-script -T

You can also run lit.py directly to only run selected tests. See 
docs/Testing.md for details.

Slava

> 
> Thank you.
> 
> Regards,
> Alwyn
> 
> On Wednesday, 13 September 2017, 7:39:08 AM IST, Slava Pestov 
>  wrote:
> 
> 
> Take a look at test/stdlib/. Unit tests use the SwiftUnittest framework, you 
> should be able to get started by looking at existing examples.
> 
> Slava
> 
>> On Sep 12, 2017, at 5:35 AM, Alwyn Concessao via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Hey Swift devs,
>> 
>> So I have been able to clone the Swift project from Github and built the 
>> project successfully.I've just added some code to the Swift std library and 
>> I want to test the added functionality by writing some unit tests.But I'm 
>> stuck with going about doing this.How can I write unit tests for the Swift 
>> standard library?
>> 
>> Thank you!
>> 
>> Regards,
>> Alwyn
>> ___
>> 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] Value-type bound protocols?

[Slava Pestov via swift-dev]

> On Sep 13, 2017, at 12:23 PM, Matthew Johnson via swift-dev 
>  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Sep 13, 2017, at 11:56 AM, David Zarzycki via swift-dev 
>>  wrote:
>> 
>> 
>> 
>>> On Sep 13, 2017, at 13:53, David Sweeris  wrote:
>>> 
>>> 
 On Sep 13, 2017, at 09:54, David Zarzycki via swift-dev 
  wrote:
 
 Hello,
 
 As a part of a research project that I’m working on, I’ve started bumping 
 into the need for value-type bound protocols (as opposed to the existing 
 class bound protocols). Is this something that would be worth proposing 
 formally? Or should I just keep the patch I have on my research branch?
>>> 
>>> I think it'd be worth a proposal, especially if can talk about why you 
>>> needed it.
>> 
>> While I look forward to talking about my research, I’m not ready to do in 
>> the near future.
>> 
>> That being said, value-type bound protocols seem independently useful and 
>> that is why I emailed the list.
>> 
>> I think the use case for this is generic algorithms. Why? Because it can be 
>> hard to impossible to write *robust* generic code when you don’t know 
>> whether an abstract type copies by value or by reference during 
>> assignment/initialization. With class-bound protocols, you can guarantee 
>> reference semantics, but there is no analogous feature for ensuring value 
>> semantics. I have a small (~150 line) patch that fixes this.
> 
> Value types and value semantics are not the same.  Most people who have asked 
> for this capability actually want a constraint for value semantics, not value 
> types.  Is that what you're asking for as well?

Right. For instance, if I have a struct containing a field of reference type, 
is this struct a ‘value type’?

Slava

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

Re: [swift-dev] Unit tests for the Swift project

[Slava Pestov via swift-dev]

Take a look at test/stdlib/. Unit tests use the SwiftUnittest framework, you 
should be able to get started by looking at existing examples.

Slava

> On Sep 12, 2017, at 5:35 AM, Alwyn Concessao via swift-dev 
>  wrote:
> 
> Hey Swift devs,
> 
> So I have been able to clone the Swift project from Github and built the 
> project successfully.I've just added some code to the Swift std library and I 
> want to test the added functionality by writing some unit tests.But I'm stuck 
> with going about doing this.How can I write unit tests for the Swift standard 
> library?
> 
> Thank you!
> 
> Regards,
> Alwyn
> ___
> 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] What can you change in a fixed-contents struct?

[Slava Pestov via swift-dev]

> On Sep 6, 2017, at 7:57 PM, Brent Royal-Gordon via swift-dev 
>  wrote:
> 
>> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev > > wrote:
>> 
>> Now, we don't plan to stick to C's layout for structs, even fixed-contents 
>> structs. We'd really like users to not worry about manually packing things 
>> into trailing alignment space. But we still need a way to lay out fields 
>> consistently; if you have two stored properties with the same type, one of 
>> them has to go first. There are two ways to do this: sort by name, and sort 
>> by declaration order. That means we can either allow reordering or allow 
>> renaming, but not both. Which do people think is more important?
> 
> This is going against the grain, but I think we should order by name and 
> therefore allow reordering, but not renaming. If an API is public, renaming 
> is obviously going to be source-breaking and could easily be ABI-breaking; I 
> don't think it's that hard to explain that renaming can also be ABI-breaking 
> when you've declared your type's layout is part of your module's ABI.

However, @fixedContents structs can also contain private stored properties. 
Renaming a private property is not source-breaking (but if we sort by name when 
performing layout, it will be ABI breaking).

> As for the keyword…maybe `public(layout)` or `public(storage)`? People are 
> familiar with the idea that you have to be careful when you change something 
> that's public, so it wouldn't be surprising that a type with a public layout 
> would be sensitive to changes to its memory layout.

I’m hesitant to use a keyword rather than an @attribute for this, because (for 
the most part) attributes don’t change the language semantics of a declaration, 
only its implementation (of course there are exceptions, like @objc which 
introduces restrictions, etc).

Slava

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] What can you change in a fixed-contents struct?

[Slava Pestov via swift-dev]

> On Sep 6, 2017, at 11:09 AM, David Zarzycki via swift-dev 
>  wrote:
> 
> I see. Would “@fixedSize” or “@abi(size)” be better names? In other words, 
> the developer promises that whatever size the struct is now, it will be that 
> way forever?
> 
> Also, wouldn’t the Pair example below require that ‘A’ also be 
> @fixedContents? Otherwise what does @fixedContents mean if the elements 
> aren’t fixed?

We don’t require ‘transitive’ fragility with generic value types containing 
other types. Otherwise, Optional would have to require that T is 
fixedContents, which is too restrictive.

Slava

> 
> Dave
> 
> 
>> On Sep 6, 2017, at 13:44, Jordan Rose > > wrote:
>> 
>> I don't think that's the right way to think about it either. It's purely an 
>> optimization tool to say "I won't add anything else to this struct", which 
>> means the compiler can avoid indirection when manipulating the struct across 
>> module boundaries. We could implement it with dynamic offset symbols and 
>> still see some benefit, but in this case we really ought to be able to get 
>> all the way to C-level performance.
>> 
>> The name hasn't been formalized; this will all go through swift-evolution at 
>> some point. We thought about "fixed-layout" in the past, but that doesn't 
>> have the right connotations for something like Pair:
>> 
>> @fixedContents
>> public struct Pair {
>>   public var first: A
>>   public var second: A
>>   public init(first: A, second: A) { … }
>> }
>> 
>> This has known properties, but the layout depends on the generic argument, 
>> and if the generic argument is itself a type with unknown size then the 
>> actual layout won't be known until runtime.
>> 
>> Jordan
>> 
>> 
>>> On Sep 6, 2017, at 10:40, David Zarzycki >> > wrote:
>>> 
>>> Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the 
>>> “hard” user-experience model I brought up feels wrong for CGPoint, etc. 
>>> (For non-Apple people, CGPoint is a struct of two doubles on 64-bit 
>>> machines add two floats on 32-bit machines.)
>>> 
>>> It wasn’t obvious to me from context that @fixedContents wasn’t / isn’t for 
>>> people trying to design a comprehensive ABI (disk, wire, etc), but just the 
>>> machine specific in memory ABI. I wish the name was better, but nothing 
>>> better seems obvious. (“@inMemoryABI”?)
>>> 
>>> Dave
>>> 
 On Sep 6, 2017, at 13:11, Jordan Rose >>> > wrote:
 
 I'd be okay with allowing the ABI attributes to control ordering, but I 
 would definitely not require them on every fixed-contents struct. We hope 
 making a struct fixed-contents isn't something people have to do too 
 often, but we don't want to drop them all the way into "hard" land when 
 they do it. That is, "CGPoint" can't already be "hard mode".
 
 Jordan
 
 
> On Sep 6, 2017, at 05:13, David Zarzycki  > wrote:
> 
> Hi Jordan,
> 
> I really doubt that “belt and suspenders” ABI attributes would drive 
> people to C, but reasonable people can certainly disagree on that.
> 
> Bertrand, when he was at Apple, used to say that “easy things should be 
> easy, and hard things should be possible”.
> 
> I think ABI related attributes fall into the latter category. In 
> particular, I think that trying to make ABI attributes too convenient 
> only does programmers a disservice in the long run because most 
> programmers aren't experts, and the cost of ignorance is huge when trying 
> to do ABI design.
> 
> With these thoughts in mind, I think that is reasonable for the language 
> to say: “If you want explicit control over a dimension of ABI decisions, 
> then you must deal with all of the associated complexity. Here is a 
> pointer to the documentation on dimension X that you were/are trying to 
> explicitly manage. If that is ’too hard’ for you, then you probably 
> shouldn’t be locking down this dimension of complexity yet.”
> 
> Dave
> 
>> On Sep 5, 2017, at 20:11, Jordan Rose > > wrote:
>> 
>> Hm. This is definitely an option, but I don't think it's really an 
>> acceptable user experience. This feels like it'll drive people all the 
>> way to declaring their types in C because Swift makes it too hard.
>> 
>> We do expect to have a tool to diff old and new modules at some point, 
>> but we could do something even simpler here: make a public symbol with 
>> the struct's layout in its name. That way, even 'nm' can tell if the 
>> symbol disappears. (Of course, public symbols do have a small cost, 
>> since this might not actually be the best idea.)
>> 
>> Another idea would be to restrict @fixedContents to require that all 
>> stored properties appear contiguously in the struct, possibly even 
>> pinned

Re: [swift-dev] What can you change in a fixed-contents struct?

[Slava Pestov via swift-dev]

> On Sep 5, 2017, at 6:37 PM, Nevin Brackett-Rozinsky via swift-dev 
>  wrote:
> 
> On Tue, Sep 5, 2017 at 6:08 PM, Slava Pestov via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> We expect that “define your struct in C” is still the way to go for layout 
> compatibility with other languages and systems.
> 
> Are there plans (however tentative) to eventually make it possible to specify 
> the exact memory layout of a struct in Swift?

It’s not clear what ‘exact memory layout’ means. In C, you don’t get to specify 
the exact layout either — there are rules around alignment and padding and some 
non-standard attributes for controlling them, but that’s not quite the same 
thing.

> It seems like something we will have to tackle in order for Swift to become a 
> serious systems-level programming language.

We do plan on documenting Swift’s struct (and tuple) layout algorithms as part 
of ABI stability, because we will need to freeze them (at least for types that 
cross resilience boundaries) to actually have a stable ABI. So you could, with 
knowledge of the layout algorithm, define a struct and make assumptions about 
it’s layout in memory, based on your knowledge of the algorithm as it is 
implemented in the version of Swift you are using. Not quite the same as 
explicitly specifying a layout, though.

Slava

> 
> Nevin
> ___
> 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] What can you change in a fixed-contents struct?

[Slava Pestov via swift-dev]

> On Sep 5, 2017, at 1:01 PM, David Zarzycki via swift-dev 
>  wrote:
> 
> Hi Jordan,
> 
> Thanks for thinking about this. For whatever it may be worth, I’m concerned 
> about 1) the ability to reorder declarations and 2) the “either/or” nature of 
> this proposal.
> 
> First, reordering: The ability to reorder declarations is deeply ingrained 
> into the subconsciousness of Swift programmers and for good reasons.

There are a couple of other places where ordering of declarations matters in 
the ABI. The two most important ones I can think of right now are virtual 
methods and protocol methods. Both are called by performing an indexed lookup 
into a vtable. For methods, we were thinking that the ordering should first 
sort by availability annotation, and then by the mangled name of the method. 
This would allow re-ordering as well as adding new methods, as long as they had 
a ‘newer’ availability than anything that has come before.

However, I like the idea of an @_abi (or similar) attribute as an escape hatch 
of some kind, in case we screw something up.

Slava

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

Re: [swift-dev] What can you change in a fixed-contents struct?

[Slava Pestov via swift-dev]

> On Sep 5, 2017, at 2:48 PM, Thomas Roughton via swift-dev 
>  wrote:
> 
> Having an explicit @abi annotation could also go some way to addressing the 
> issue of manual layout with structs. I’m primarily thinking of graphics 
> contexts, wherein you need to declare e.g. a struct with vertex layout, and 
> then that needs to be specified when passed to the GPU. The current solution 
> is to declare in C code and import into Swift, which is cumbersome; having 
> @fixedContents structs be the method of choice when a deterministic layout is 
> needed seems to make sense. If combined with a hypothetical 
> MemoryLayout.offsetOf(property) Swift would, I think, meet that need.

@fixedContents is not meant for this purpose. We don’t want to guarantee that 
the layout matches what you would write in C. Of course once the ABI is stable, 
the layout of a fixed contents struct will be fixed — it just might not be what 
your GPU expects.

So perhaps @fixedContents is not the best name. We expect that “define your 
struct in C” is still the way to go for layout compatibility with other 
languages and systems.

> 
> I guess my closing question is: under what circumstances would a user declare 
> a @fixedContents struct and not care about its layout in memory; in other 
> words, where might a novice need to use this feature?


It’s more about performance. By promising to the compiler that you will not 
change the layout of the struct, uses of the struct from other modules can use 
more efficient access patterns (for example, direct loads/stores of properties 
instead of calling accessors).

Slava

> 
> Thomas
> 
>> On 6/09/2017, at 8:01 AM, David Zarzycki via swift-dev > > wrote:
>> 
>> Hi Jordan,
>> 
>> Thanks for thinking about this. For whatever it may be worth, I’m concerned 
>> about 1) the ability to reorder declarations and 2) the “either/or” nature 
>> of this proposal.
>> 
>> First, reordering: The ability to reorder declarations is deeply ingrained 
>> into the subconsciousness of Swift programmers and for good reasons. I think 
>> adding localized declaration order sensitivity is likely to be very brittle 
>> and regrettable in the long run. I also think this problem is made worse by 
>> having a type declaration context attribute because it can easily get lost 
>> in the noise of nontrivial declarations. The net result is that people will 
>> frequently forget about local order sensitivity. Yes, the compiler can 
>> engage in heroics and compare the previous module ABI and the new module ABI 
>> for conflicts, but that seems risky, complex, slow, and differently error 
>> prone.
>> 
>> Second, the “either/or” nature of this proposal: What do you think about a 
>> lightweight “belt and suspenders” solution whereby @fixedContents requires 
>> that stored properties be lightly annotated with their layout order? For 
>> example:
>> 
>> @fixedContents(3) struct Foo {
>>   @abi(0) var x: Int
>>   func a() {
>> // a thousand lines of ABI layout distraction
>>   }
>>   @abi(1) var y: Double
>>   func b() {
>> // another thousand lines of ABI layout distraction
>>   }
>>   @abi(2) var z: String
>> }
>> 
>> That would enable both renaming and reordering, would it not? This approach 
>> would also aid the compiler in quickly detecting hastily added/deleted 
>> declarations too because the count of @abi([0-9]+) declarations wouldn’t 
>> match the number passed to @fixedContents.
>> 
>> Dave
>> 
>> 
>> 
>>> On Sep 5, 2017, at 14:59, Jordan Rose via swift-dev >> > wrote:
>>> 
>>> Hey, all. In preparation for the several proposals we have to come this 
>>> year, I cleaned up docs/LibraryEvolution.rst 
>>>  a little bit based on what's 
>>> changed in Swift 4. This is mostly just mentioning things about generic 
>>> subscripts, but there is one issue that I remember John bringing up some 
>>> time in this past year: once you've made a struct fixed-contents, what can 
>>> you change about its stored properties?
>>> 
 To opt out of this flexibility, a struct may be marked '@fixedContents'. 
 This promises that no stored properties will be added to or removed from 
 the struct, even non-public ones.
>>> 
>>> Interestingly, this means that you can have non-public members of a 
>>> fixed-contents struct. This is actually pretty sensible: it's the 
>>> equivalent of a C++ class with non-public fields but a defaulted, inlinable 
>>> copy constructor. Any inlinable members can access these properties 
>>> directly as well; it's just outsiders that can't see them. But if inlinable 
>>> code can reference these things, and if we really want them to be fast, 
>>> that means they have to have a known offset at compile-time.
>>> 
>>> Now, we don't plan to stick to C's layout for structs, even fixed-contents 
>>> structs. We'd really like users to not worry about manually packing things 
>>> into trailing alignment spac

Re: [swift-dev] Advice for implementing "literal values as generic types"

[Slava Pestov via swift-dev]

> On Aug 29, 2017, at 2:21 PM, David Sweeris  wrote:
> 
> 
>> On Aug 29, 2017, at 1:49 PM, Slava Pestov > > wrote:
>> 
>> 
>>> On Aug 29, 2017, at 11:03 AM, David Sweeris via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Hi everyone! I'm trying to implement literal values as generic types.
>> 
>> Can you briefly explain what you mean by this?
>> 
>> Are you referring to let-polymorphism, like
>> 
>> let fn = { $0 }
>> let f1: (Int) -> Int = fn
>> let f2: (Float) -> Float = fn
> 
> No, I mean so that a vector's or matrix's dimensions can be part of its type 
> (strawman syntax and protocol name, but this is pretty much what I'll be 
> trying to support, at least at first):

I think instead of modeling these generic parameters as types, you should look 
into generalizing GenericSignatures to contain ‘literal requirements’. Right 
now, we have four kinds of requirements:

- A is a subclass of B
- A conforms to B
- A is the same type as B
- A has a known layout

All of these except for the last one have a generic parameter as their right 
hand side. All of them have a generic parameter on their left hand side. I 
think what you want is to add a new ‘value parameter’ that is not a type, but 
instead has a value. Requirements would be placed on these to constrain them to 
known kinds of literals (integers, strings, etc).

> struct Vector {
>   var elements: [T]
>   init() {
> elements = [T](repeating: 0, count: L)
>   }
> }
> 
> let vect = Vector()
> 
> And, once that's working, I'm going to add support simple "type functions":
> func join  (_ lhs: Vector, _ rhs: Vector) -> 
> Vector {...}
> I think restricting the supported "type functions" to expressions that could 
> be evaluated by the compiler's "constant folding" code would be a reasonable 
> place to start,

The compiler’s constant folding operates on SIL instructions, not Exprs 
directly. However constant folding is not generally what you want for this, 
because constant folding is a ‘best effort’ kind of optimization (it may or may 
not fold your calculation down to a constant) and also it produces code that 
evaluates the result (even if its a constant) and not the result itself.

I think if you want to explore type-level computation like this, you should 
define a very small subset of the language which can be computed by the type 
checker like this.

> until we figure out what we want to do about "pure"/"constexpr" stuff... even 
> just "+" for numeric and string literals, and "-" for numeric literals, seems 
> like a reasonable starting goal, and I think that'd be simple enough to 
> implement (famous last words, right?)... It's all academic until I get the 
> simple cases working first, though.
> 
> Anyway, I think it'll be worth writing up as a proposal, once it's working 
> and I've figured out how to present these "literal types" to Swift's type 
> system (I'd like to keep it as a literal of some sort, so that, say, `L` in 
> this example could be used to set the value of any type that conforms to 
> `ExpressibleByIntegerLiteral`).
> 
> - Dave Sweeris
> 

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

Re: [swift-dev] Advice for implementing "literal values as generic types"

[Slava Pestov via swift-dev]

> On Aug 29, 2017, at 11:03 AM, David Sweeris via swift-dev 
>  wrote:
> 
> Hi everyone! I'm trying to implement literal values as generic types.

Can you briefly explain what you mean by this?

Are you referring to let-polymorphism, like

let fn = { $0 }
let f1: (Int) -> Int = fn
let f2: (Float) -> Float = fn

Slava

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

Re: [swift-dev] Making a protocol's associated type concrete via inheritance

[Slava Pestov via swift-dev]

This is not supported right now but it is within the realm of possibility of 
things that we can support.

The restriction on using protocols as types is artificial — it was put in place 
to avoid confusing users. So it is a matter of tweaking the logic which 
diagnosed unsupported protocol types to somehow check for fully-constrained 
associated types instead.

Slava

> On Aug 27, 2017, at 2:54 PM, Jarod Long via swift-dev  
> wrote:
> 
> Apologies for any terminology that I'm not using correctly, but I'm wondering 
> if there's any way to make this work in Swift 4:
> 
> ```
> protocol P1 {
> associatedtype Thing
> func makeThing() -> Thing
> }
> 
> protocol P2: P1 where Thing == String {}
> 
> func test(_ p2: P2) { // Can only use P2 as a generic constraint even though 
> P2.Thing should be known to be String
> print(p2.makeThing())
> }
> ```
> 
> I want P2 to conform to P1 and make its associated type concrete so that it 
> can be used directly. If this isn't possible right now, are there any plans 
> for something like this to be added in the future? I've looked through the 
> generics manifesto, but I didn't see anything that seemed to address this 
> issue.
> 
> Thanks!
> 
> Jarod
> ___
> 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 module format

[Slava Pestov via swift-dev]

> On Aug 24, 2017, at 10:56 PM, John McCall via swift-dev  
> wrote:
> 
> Or if you really want to avoid the FFI, you could take our current ASTDumper 
> output, which is currently pseudo-machine-readable, and make it actually 
> machine-readable.  The elegant approach there would be to take the entire 
> dumper and remove its pervasive dependence on an output stream; instead, it 
> would be rewritten to make calls on a SAX-like streaming interface, and there 
> would just be a standard implementation that formatted things as XML / JSON / 
> our weird s-expression format.

… I would love it if ASTDumper supported a Clang-like tree view in addition to 
(or instead of, if we also get JSON output?) the faux s-expression output. I 
know I’m supposed to like Lisp, but I personally find our dump output rather 
hard to read.

Slava___
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) #254

[Slava Pestov via swift-dev]

I think this is a transient failure because my patch changed ABI — can someone 
clean the workspace?

> On Aug 24, 2017, at 6:17 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#254]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/254/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Thu, 24 Aug 2017 20:00:21 -0500
> Build duration:   18 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9855 test(s), Total: 9855 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 443 test(s), Total: 443 test(s)
> 
> Changes
> 
> Commit d73712d79bbe37fd855747306669b168e8ce03a0 by spestov:
> IRGen/Runtime: Initialize generic and resilient class vtables from
> 
> edit: stdlib/public/runtime/Metadata.cpp
> edit: include/swift/Runtime/Metadata.h
> edit: test/IRGen/generic_types.swift
> edit: lib/IRGen/GenMeta.cpp
> edit: test/IRGen/generic_classes.sil

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

Re: [swift-dev] swift module format

[Slava Pestov via swift-dev]

Yeah, it’s important to keep in mind we don’t have a stable module format right 
now, so anything developed Swift 4 will likely need to be revised again with 
the next version.

The C++ API is not stable either, but approach could be to dump the ‘generated 
interface’ using swift-ide-tool or similar, and parse the text. Also, it’s 
worth taking a look at swift-api-digester too.

Slava

> On Aug 24, 2017, at 4:35 PM, Argyrios Kyrtzidis via swift-dev 
>  wrote:
> 
> Hi,
> 
> What are you trying to do exactly ? Have you considered reading the decls 
> with a tool using the C++ APIs (load a module and iterate over the decls) ?
> I think that would be easier and more future-proof.
> 
>> On Aug 22, 2017, at 11:57 AM, Coder via swift-dev  
>> wrote:
>> 
>> Hello,
>> 
>> I’m working on extracting information from .swiftmodule files. Currently I 
>> can read all blocks and records but I’m having trouble identifying all DECLs 
>> in the DECLS_AND_TYPES_BLOCK. Below is a bcanalyzer dump of a swifmodule 
>> file created from this one line of code:
>> 
>> class Example {} 
>> 
>> A couple questions:
>> 
>> • The DECL_OFFSETS record contains 6 indexes but I only count 5 DECLs 
>> (class, destructor, constructor, 2 param). Where is the 6th?
>> • According to documentation, the DECL_OFFSETS point to records in the 
>> DECLS_AND_TYPES_BLOCK blob but offset indexes show below (the “op” 
>> attributes) are larger than the blob length. Where do the indexes start from?
>> 
>> Sorry if this is the wrong place to ask and thanks for any help,
>> Aaron
>> 
>> 
>> 
>> 
>> - bcanalyzer dump -
>> 
>> 
>> 
>> 
>>blob data = 'tool'
>>blob data = '3.1/Apple Swift 
>> version 3.1 (swiftlang-802.0.53 clang-802.0.42)'
>>blob data = 'x86_64-apple-macosx10.9'
>>   
>> 
>>   
>> 
>> 
>>blob data = 'Swift'
>>blob data = 'SwiftOnoneSupport'
>> 
>> 
>> 
>> 
>> 
>> 
>>   > op8=1/> record string = ''
>>   
>>   
>>   
>>record string = ''
>>   
>>   
>>   
>>   > op7=0 op8=3 op9=0 op10=2/> record string = ''
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>
>> record string = ''
>>   
>>   
>> 
>> 
>>blob data = unprintable, 30 bytes.
>> 
>> 
>>   > op5=74671/>
>>   > op5=74375 op6=74452/>
>>   
>>   
>>record string = ''
>>record string = ''
>>record string = 'T'
>>record string = ''
>>blob data = unprintable, 40 bytes.
>>blob data = unprintable, 44 bytes.
>> 
>> 
>> ___
>> 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] Build Failure with Xcode 9.0 beta 5

[Slava Pestov via swift-dev]

> On Aug 16, 2017, at 6:21 PM, David Sweeris via swift-dev 
>  wrote:
> 
> Does it hurt anything to have both betas installed? I'm in the process of 
> installing the 4th beta now. Once that's done, I'm going to build the Xcode 
> project. I'd like to reinstall beta 5 after that, but not if that'll keep me 
> from compiling the compiler.

It’s totally fine to have multiple versions of Xcode installed. You can use the 
command-line ‘xcode-select’ tool to select between them.

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

Re: [swift-dev] Portable stdlib

[Slava Pestov via swift-dev]

> On Aug 14, 2017, at 9:44 AM, Andy Best via swift-dev  
> wrote:
> 
> Hey,
> 
> I'm currently looking at building a portable version of the standard library 
> (for targeting microcontrollers, kernel dev, etc).

I’m a bit confused about your terminology. By “portable” do you mean no 
dependencies on libc or POSIX?

> 
> The easiest way to cross compile Swift at the moment (that I can find) is to 
> get swiftc to generate LLVM IR (-emit-ir), and use clang to build and cross 
> compile. This obviously leaves the problem that there won't be a standard lib 
> to link against on the target.

There’s a PR open to add cross-compilation support to the build system: 
https://github.com/apple/swift/pull/1398 
 It would be great if you or someone 
else would dust it off and get it merged in.

> 
> I figured that the best way to accomplish this would probably be to implement 
> whatever stubs are necessary for the target (e.g. all the libc calls).
> 
> I am struggling to find the best way to build the standard library though. 
> I've got a copy of the stdlib files, have run gyb over all of the templates, 
> and am attempting to get swiftc to compile everything and output a giant IR 
> file.
> 
> I was wondering if there was an easier way to go about building a custom 
> libswiftcore?
> 
> It would obviously be great to be able to use Swift in this way without an 
> OS, as it would open up a lot of opportunities for use of the language 
> (embedded development, etc).

Slava

> 
> 
> Thanks,
> 
> Andy
> ___
> 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] Is swift.org/contributing/ stale?

[Slava Pestov via swift-dev]

I think it’s still up to date. You need commit access to trigger CI, and to 
merge PRs. Otherwise you’ll have to ask someone with commit access to do that 
for you.

Slava

> On Aug 14, 2017, at 1:14 PM, David Zarzycki via swift-dev 
>  wrote:
> 
> On the swift.org/contributing/ web page, under “Commit Access”, the section 
> talks about commit access in a way that suggests that it was written before 
> mandatory continuous integration testing was added. Is this true? Can 
> somebody update the page? If CI is not required, then is there something I 
> need to do before pushing a commit?
> 
> Thanks!
> Dave
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] switches versus the visitor pattern?

[Slava Pestov via swift-dev]

I’ve seen some switches over TypeKind more easily expressed as a series of 
if/else if statements also.

However unless you come across an ugly switch that you want to refactor while 
working on something else, I probably wouldn’t spend time actively seeking them 
out and changing them. I don’t think switching over the kind is considered a 
code smell in itself.

Slava

> On Aug 11, 2017, at 2:48 PM, David Zarzycki via swift-dev 
>  wrote:
> 
> Hello,
> 
> Before I spend time creating patches, are there arguments against converting 
> exhaustive switch statements to the visitor pattern in the Swift source base? 
> In particular, I’m curious about switches that reason about the TypeKind enum.
> 
> Thanks,
> – Dave
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] 107 lines of "dead" code in ConstraintSystem::performMemberLookup?

[Slava Pestov via swift-dev]

I see you’re two steps ahead of me already: 
https://github.com/apple/swift/pull/11397 


This looks good, nice catch!

Slava

> On Aug 8, 2017, at 8:45 PM, Slava Pestov  wrote:
> 
> 
>> On Aug 8, 2017, at 3:34 PM, David Zarzycki via swift-dev 
>>  wrote:
>> 
>> In ConstraintSystem::performMemberLookup(), constructors with “simple” names 
>> have a dedicated lookup path. In contrast, constructors with compound names 
>> are handled by the normal lookup. If I delete this code and let the normal 
>> lookup path handle both simple and compound named constructors, I find that 
>> all 10,214 validation tests pass on my machine (albeit with slightly 
>> different error messages in three test files).
> 
> I would suggest running the source compatibility test suite also (see “pull 
> request testing” in https://swift.org/source-compatibility/), but it is quite 
> possible the code is indeed unnecessary.
> 
>> 
>> Is the test suite missing a test for this code path and if so, what? Or 
>> should it be scheduled for deletion after identical error messages can be 
>> generated by the normal lookup path?
> 
> Are the new error messages worse or just different? If the latter there’s 
> really no requirement to keep them identical.
> 
> Slava
> 
>> 
>> Dave
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 

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

Re: [swift-dev] 107 lines of "dead" code in ConstraintSystem::performMemberLookup?

[Slava Pestov via swift-dev]

> On Aug 8, 2017, at 3:34 PM, David Zarzycki via swift-dev 
>  wrote:
> 
> In ConstraintSystem::performMemberLookup(), constructors with “simple” names 
> have a dedicated lookup path. In contrast, constructors with compound names 
> are handled by the normal lookup. If I delete this code and let the normal 
> lookup path handle both simple and compound named constructors, I find that 
> all 10,214 validation tests pass on my machine (albeit with slightly 
> different error messages in three test files).

I would suggest running the source compatibility test suite also (see “pull 
request testing” in https://swift.org/source-compatibility/), but it is quite 
possible the code is indeed unnecessary.

> 
> Is the test suite missing a test for this code path and if so, what? Or 
> should it be scheduled for deletion after identical error messages can be 
> generated by the normal lookup path?

Are the new error messages worse or just different? If the latter there’s 
really no requirement to keep them identical.

Slava

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

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

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

[Slava Pestov via swift-dev]

> On Jul 30, 2017, at 5:47 PM, John McCall  wrote:
> 
>> On Jul 29, 2017, at 7:35 PM, Slava Pestov > > wrote:
>>> On Jul 29, 2017, at 12:53 PM, John McCall via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
 On Jul 29, 2017, at 12:48 AM, Andrew Trick >>> > wrote:
> On Jul 28, 2017, at 8:13 PM, John McCall  > wrote:
>> On Jul 28, 2017, at 11:11 PM, John McCall via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>>> On Jul 28, 2017, at 10:38 PM, Andrew Trick >> > wrote:
 On Jul 28, 2017, at 3:15 PM, John McCall >>> > wrote:
> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> 
> 
>> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> The Swift runtime currently maintains globally unique pointer 
>> identities for type metadata and protocol conformances. This makes 
>> checking type equivalence a trivial pointer equality comparison, but 
>> most operations on generic values do not really care about exact 
>> type identity and only need to invoke value or protocol witness 
>> methods or consult other data in the type metadata structure. I 
>> think it's worth reevaluating whether having globally unique type 
>> metadata objects is the correct design choice. Maintaining global 
>> uniqueness of metadata instances carries a number of costs. Any code 
>> that wants type metadata for an instance of a generic type, even a 
>> fully concrete one, must make a potentially expensive runtime call 
>> to get the canonical metadata instance. This also greatly 
>> complicates our ability to emit specializations of type metadata, 
>> value witness tables, or protocol witness tables for concrete 
>> instances of generic types, since specializations would need to be 
>> registered with the runtime as canonical metadata objects, and it 
>> would be difficult to do this lazily and still reliably favor 
>> specializations over more generic witnesses. The lack of witness 
>> table specializations leaves an obnoxious performance cliff for 
>> instances of generic types that end up inside existential containers 
>> or cross into unspecialized code. The runtime also obligates 
>> binaries to provide the canonical metadata for all of their public 
>> types, along with all the dependent value witnesses, class methods, 
>> and protocol witness tables, meaning a type abstraction can never be 
>> completely "zero-cost" across modules.
>> 
>> On the other hand, if type metadata did not need to be unique, then 
>> the compiler would be free to emit specialized type metadata and 
>> protocol witness tables for fully concrete non-concrete value types 
>> without consulting the runtime. This would let us avoid runtime 
>> calls to fetch metadata in specialized code, and would make it much 
>> easier for us to implement witness specialization. It would also 
>> give us the ability to potentially extend the "inlinable" concept to 
>> public fragile types, making it a client's responsibility to emit 
>> metadata for the type when needed and keeping the type from 
>> affecting its home module's ABI. This could significantly reduce the 
>> size and ABI surface area of the standard library, since the 
>> standard library contains a lot of generic lightweight adapter types 
>> for collections and other abstractions that are intended to be 
>> optimized away in most use cases.
>> 
>> There are of course benefits to globally unique metadata objects 
>> that we would lose if we gave up uniqueness. Operations that do 
>> check type identity, such as comparison, hashing, and dynamic 
>> casting, would have to perform more expensive checks, and nonunique 
>> metadata objects would need to carry additional information to 
>> enable those checks. It is likely that class objects would have to 
>> remain globally unique, if for no other reason than that the 
>> Objective-C runtime requires it on Apple platforms. Having multiple 
>> equivalent copies of type metadata has the potential to increase the 
>> working set of an app in some situations, although it's likely that 
>> redundant compiler-emitted copies of value type metadata would at 
>> least be able to live in constant pages mapped from disk instead of 
>> getting dynamically instantiated by the runtime like everything is 
>> today. There could also 

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

[Slava Pestov via swift-dev]

> On Jul 28, 2017, at 4:07 PM, Jordan Rose via swift-dev  
> wrote:
> 
> My point is we can't use our usual mangling in the string, because that 
> contains type names.
> 

We could invent a ‘mangling’ format (either using the existing demangler with a 
special flag or something else) where types inside the module are encoded as a 
pointer to a nominal type descriptor or something.

This would be useful for remote reflection as well, for secrecy and efficiency 
reasons.

Also being able to build metadata from a mangling will allow the standard 
library’s Mirror type to use the reflection metadata, instead of a ‘field type 
accessor’ which is emitted by IRGen for each value type, saving on code size.

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

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

[Slava Pestov via swift-dev]

> On Jul 29, 2017, at 12:53 PM, John McCall via swift-dev  
> wrote:
> 
>> On Jul 29, 2017, at 12:48 AM, Andrew Trick > > wrote:
>>> On Jul 28, 2017, at 8:13 PM, John McCall >> > wrote:
 On Jul 28, 2017, at 11:11 PM, John McCall via swift-dev 
 mailto:swift-dev@swift.org>> wrote:
> On Jul 28, 2017, at 10:38 PM, Andrew Trick  > wrote:
>> On Jul 28, 2017, at 3:15 PM, John McCall > > wrote:
>>> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> 
 On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev 
 mailto:swift-dev@swift.org>> wrote:
 
 The Swift runtime currently maintains globally unique pointer 
 identities for type metadata and protocol conformances. This makes 
 checking type equivalence a trivial pointer equality comparison, but 
 most operations on generic values do not really care about exact type 
 identity and only need to invoke value or protocol witness methods or 
 consult other data in the type metadata structure. I think it's worth 
 reevaluating whether having globally unique type metadata objects is 
 the correct design choice. Maintaining global uniqueness of metadata 
 instances carries a number of costs. Any code that wants type metadata 
 for an instance of a generic type, even a fully concrete one, must 
 make a potentially expensive runtime call to get the canonical 
 metadata instance. This also greatly complicates our ability to emit 
 specializations of type metadata, value witness tables, or protocol 
 witness tables for concrete instances of generic types, since 
 specializations would need to be registered with the runtime as 
 canonical metadata objects, and it would be difficult to do this 
 lazily and still reliably favor specializations over more generic 
 witnesses. The lack of witness table specializations leaves an 
 obnoxious performance cliff for instances of generic types that end up 
 inside existential containers or cross into unspecialized code. The 
 runtime also obligates binaries to provide the canonical metadata for 
 all of their public types, along with all the dependent value 
 witnesses, class methods, and protocol witness tables, meaning a type 
 abstraction can never be completely "zero-cost" across modules.
 
 On the other hand, if type metadata did not need to be unique, then 
 the compiler would be free to emit specialized type metadata and 
 protocol witness tables for fully concrete non-concrete value types 
 without consulting the runtime. This would let us avoid runtime calls 
 to fetch metadata in specialized code, and would make it much easier 
 for us to implement witness specialization. It would also give us the 
 ability to potentially extend the "inlinable" concept to public 
 fragile types, making it a client's responsibility to emit metadata 
 for the type when needed and keeping the type from affecting its home 
 module's ABI. This could significantly reduce the size and ABI surface 
 area of the standard library, since the standard library contains a 
 lot of generic lightweight adapter types for collections and other 
 abstractions that are intended to be optimized away in most use cases.
 
 There are of course benefits to globally unique metadata objects that 
 we would lose if we gave up uniqueness. Operations that do check type 
 identity, such as comparison, hashing, and dynamic casting, would have 
 to perform more expensive checks, and nonunique metadata objects would 
 need to carry additional information to enable those checks. It is 
 likely that class objects would have to remain globally unique, if for 
 no other reason than that the Objective-C runtime requires it on Apple 
 platforms. Having multiple equivalent copies of type metadata has the 
 potential to increase the working set of an app in some situations, 
 although it's likely that redundant compiler-emitted copies of value 
 type metadata would at least be able to live in constant pages mapped 
 from disk instead of getting dynamically instantiated by the runtime 
 like everything is today. There could also be subtle source-breaking 
 behavior for code that bitcasts metatype values to integers or 
 pointers and expects bit-level equality to indicate type equality. 
 It's unlikely to me that giving up uniqueness would buy us any 
 simplification to the runtime, since the runtime would still need to 
 b

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

[Slava Pestov via swift-dev]

Hi David,

I reverted your PR because it appears to have broken the build: 
https://github.com/apple/swift-corelibs-libdispatch/pull/278 


Please take a look when you get a chance.

Slava

> On Jul 13, 2017, at 9:02 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#3550]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/3550/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Thu, 13 Jul 2017 20:36:13 -0700
> Build duration:   27 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 e86428559a86303ad18498617970cf5bfb405c33 by Itai Ferber:
> Expose synthesized members in AST lookups
> 
> edit: include/swift/AST/LazyResolver.h
> edit: lib/AST/NameLookup.cpp
> add: test/decl/protocol/special/coding/class_codable_member_lookup.swift
> edit: lib/Sema/DerivedConformanceCodingKey.cpp
> edit: lib/Sema/DerivedConformanceRawRepresentable.cpp
> add: test/decl/protocol/special/coding/class_codable_member_type_lookup.swift
> add: test/decl/protocol/special/coding/struct_codable_member_type_lookup.swift
> edit: lib/Sema/TypeCheckDecl.cpp
> edit: lib/Sema/TypeChecker.h
> 
> Commit acb33fa4c94a8c6bac69573020a320840b671bab by Michael Gottesman:
> [di] Split the main di test into 4 files, depending on the type of
> 
> add: test/SILOptimizer/definite_init_markuninitialized_derivedself.sil
> delete: test/SILOptimizer/definite_init.sil
> add: test/SILOptimizer/definite_init_markuninitialized_delegatingself.sil
> add: test/SILOptimizer/definite_init_markuninitialized_rootself.sil
> add: test/SILOptimizer/definite_init_markuninitialized_var.sil
> 
> Commit 294a213cf0de4192bec6a354d59ff25c5fcf07df by David Grove:
> test suite fixes to prep for enabling additional warnings
> 
> edit: tests/dispatch_group.c
> edit: tests/dispatch_queue_finalizer.c
> edit: tests/bsdtestharness.c
> edit: tests/dispatch_c99.c
> edit: tests/dispatch_timer_bit31.c
> edit: tests/dispatch_io_net.c
> edit: tests/dispatch_timer_set_time.c
> edit: tests/dispatch_apply.c
> edit: tests/dispatch_sema.c
> edit: tests/dispatch_starfish.c
> edit: tests/linux_port.h
> edit: tests/bsdtests.h
> edit: tests/dispatch_timer_short.c
> edit: tests/dispatch_timer.c
> edit: tests/bsdtests.c
> edit: tests/dispatch_select.c
> edit: tests/dispatch_after.c
> edit: tests/dispatch_data.c
> edit: tests/dispatch_api.c
> edit: tests/dispatch_timer_bit63.c

___
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.04 (master) #3925

[Slava Pestov via swift-dev]

FWIW I filed rdar://33276769  to track the issue internally.

> On Jul 12, 2017, at 3:44 PM, Pavel Yaskevich  wrote:
> 
> Log says:
> 
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script-impl:
>  line 262: 27497 Segmentation fault  "$@"
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 139, aborting
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 1, aborting
> 
> Mishal, could you please check what happened?
> 
> On Wed, Jul 12, 2017 at 3:39 PM,  > wrote:
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#3925]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/3925/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_04
> Date of build:Wed, 12 Jul 2017 14:31:21 -0700
> Build duration:   1 hr 8 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9630 test(s), Total: 9630 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 441 test(s), Total: 441 test(s)
> 
> Changes
> 
> Commit 481401f6c3c754c5e88b496b2353f2488fb4b584 by Pavel Yaskevich:
> [QoI] Don't try to lookup members on incorrect type during Objective-C
> 
> add: validation-test/compiler_crashers_2_fixed/0113-rdar33044867.swift
> edit: lib/Sema/TypeCheckExprObjC.cpp
> 
> 

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

Re: [swift-dev] Pathway to becoming an effective contributor

[Slava Pestov via swift-dev]

> On Jun 21, 2017, at 2:12 PM, Natthan Leong via swift-dev 
>  wrote:
> 
> Hi,
> 
> As someone who also recently started contributing, I was surprised to discover
> how much computing power was needed to build Swift. My first few build 
> attempts
> on a mid-2014 rMBP took more than an hour with 100% CPU utilization which is
> unsustainable for future participation.

A clean build of LLVM, swift, and the standard library takes a while, but most 
of the time you shouldn’t have to rebuild everything from scratch.

For example if I’m just iterating on the compiler, I can edit a couple of 
source files and run ‘ninja swift’ and have a new compiler binary ready to test 
in a few seconds. I only rebuild the standard library if absolutely necessary, 
since that takes longer, but even then ‘ninja swift-stdlib’ is only a few 
minutes.

Also I always do release builds during normal development, only doing a debug 
build if I have to run the debugger which isn’t very often. Release builds 
produce a faster swiftc, so the standard library is built faster, and also they 
link faster.

Finally, it is possible to run only a subset of the validation tests while 
you’re iterating on a specific feature, instead of having to wait the ~15 
minutes for ‘ninja check-swift-validation’, by directly invoking lit.

Slava

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

Re: [swift-dev] CI failure: .../TestFoundation: undefined symbol: _T0ScN

[Slava Pestov via swift-dev]

It’s an incremental build issue. The bots don’t always rebuild Foundation, or 
something. I think we need to clean the workspace out.

Slava

> On May 13, 2017, at 12:13 AM, Boris Buegling via swift-dev 
>  wrote:
> 
> Hi everyone,
> 
> I am seeing a CI failure on llbuild for seemingly unrelated reasons and I am 
> unsure how to deal with it:
> 
> + env 
> LD_LIBRARY_PATH=//usr//lib/swift/:/home/buildnode/jenkins/workspace/swift-llbuild-PR-Linux-smoke-test/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation:/home/buildnode/jenkins/workspace/swift-llbuild-PR-Linux-smoke-test/Ninja-ReleaseAssert/xctest-linux-x86_64:/home/buildnode/jenkins/workspace/swift-llbuild-PR-Linux-smoke-test/Ninja-ReleaseAssert/libdispatch-linux-x86_64/src/.libs:
>  
> /home/buildnode/jenkins/workspace/swift-llbuild-PR-Linux-smoke-test/Ninja-ReleaseAssert/foundation-linux-x86_64/TestFoundation/TestFoundation
> /home/buildnode/jenkins/workspace/swift-llbuild-PR-Linux-smoke-test/Ninja-ReleaseAssert/foundation-linux-x86_64/TestFoundation/TestFoundation:
>  symbol lookup error: 
> /home/buildnode/jenkins/workspace/swift-llbuild-PR-Linux-smoke-test/Ninja-ReleaseAssert/foundation-linux-x86_64/TestFoundation/TestFoundation:
>  undefined symbol: _T0ScN
> 
> Happens when running Foundation tests on 
> https://github.com/apple/swift-llbuild/pull/147
> 
> Log of the failure: 
> https://ci.swift.org/job/swift-llbuild-PR-Linux-smoke-test/179/console
> 
> $ xcrun swift-demangle _T0ScN
> _T0ScN ---> type metadata for Swift.UnicodeScalar
> 
> Any recommendations or hints?
> 
> Thanks,
> Boris
> ___
> 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] PR review process

[Slava Pestov via swift-dev]

I found three PRs from you and looked at two. I’m fine with merging them once 
the tests pass so I assigned them to myself as a reminder.

I’m assuming this one is not ready yet though: 
https://github.com/apple/swift/pull/8793 
<https://github.com/apple/swift/pull/8793>

Slava

> On May 4, 2017, at 2:40 PM, Slava Pestov via swift-dev  
> wrote:
> 
> Hi Pavol,
> 
> Bug us mercilessly if you need something reviewed.
> 
> Slava
> 
>> On May 4, 2017, at 9:26 AM, Pavol Vaskovic via swift-dev 
>>  wrote:
>> 
>> Hello!
>> 
>> What is the process for getting a PR reviewed and merged into Swift? My 
>> experience so far is inconsistent. Sometimes I get a response in a few 
>> hours, discussion starts and I know I'm not wasting effort. At the moment I 
>> have 2 PRs open. One for 8 days without response. 
>> 
>> I understand that Apple folks are pretty busy before WWDC… 
>> 
>> I was told that I should be patient and wait a week before asking for a 
>> review again.
>> 
>> Is there a way to improve upon the current state of affairs?
>> 
>> Best regards
>> Pavol Vaskovic 
>> ___
>> 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] PR review process

[Slava Pestov via swift-dev]

Hi Pavol,

Bug us mercilessly if you need something reviewed.

Slava

> On May 4, 2017, at 9:26 AM, Pavol Vaskovic via swift-dev 
>  wrote:
> 
> Hello!
> 
> What is the process for getting a PR reviewed and merged into Swift? My 
> experience so far is inconsistent. Sometimes I get a response in a few hours, 
> discussion starts and I know I'm not wasting effort. At the moment I have 2 
> PRs open. One for 8 days without response. 
> 
> I understand that Apple folks are pretty busy before WWDC… 
> 
> I was told that I should be patient and wait a week before asking for a 
> review again.
> 
> Is there a way to improve upon the current state of affairs?
> 
> Best regards
> Pavol Vaskovic 
> ___
> 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] Miscompile with protocol compositions

[Slava Pestov via swift-dev]

And here’s a test case that crashes at runtime in Swift 3.1 and asserts on an 
asserts-on build that does not involve protocol compositions, only protocol 
refinement and a class constraint:

protocol P {
  func bar()
}

// Comment out the 'class ,' to make the problem go away
protocol Q : class, P {}

extension P {
  mutating func foo() {
bar()
  }
}

class C : Q {
  let x: Int = 100

  func bar() {
print(x) // crash here
  }
}

func takesQ(q: Q) {
  var qq = q
  qq.foo()
}

takesQ(q: C())

> On Apr 27, 2017, at 12:35 AM, Slava Pestov via swift-dev 
>  wrote:
> 
> Hi all,
> 
> I’ve spent most of the last two days debugging various issues with property 
> and subscript accesses on class-constrained existentials and I’ve just now 
> realized the root cause is a much more fundamental issue.
> 
> Consider the following code:
> 
> protocol P {
>  var x: Int { get set }
> 
>  init()
> }
> 
> func takesP(p: inout P & AnyObject) {
>  p.x = 1
> }
> 
> Note that ‘takesP’ has a class-constrained existential type as a parameter. 
> You can replace AnyObject with any class protocol, it won’t change anything 
> below.
> 
> Also, the init() requirement in the protocol will come into play later — for 
> now, just consider the ‘var x’, which has a mutating setter.
> 
> The above code compiles fine. Let’s take a look at the SILGen though:
> 
>  %2 = load [copy] %0 : $*AnyObject & P
>  %3 = open_existential_ref %2 : $AnyObject & P to 
> $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P
> ...
>  %8 = alloc_stack $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject 
> & P
>  store %3 to [init] %8 : $*@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") 
> AnyObject & P
>  %10 = witness_method $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") 
> AnyObject & P, #P.x!setter.1, %3 : 
> $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P : 
> $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (Int, @inout τ_0_0) -> ()
>  %11 = apply %10<@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & 
> P>(%7, %8) : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (Int, 
> @inout τ_0_0) -> ()
> 
> So we load the ‘AnyObject & P’ existential value from our inout argument, 
> then in order to call the protocol requirement for x’s setter, which takes 
> the ‘self’ value as an indirect argument, we allocate a box on the stack, 
> store the reference into the box, call the requirement with the address of 
> the box as the value of ‘self’, and destroy the box. We never write the 
> result back to the inout.
> 
> So consider the following implementation of a concrete type conforming to P:
> 
> extension P {
>  var x: Int {
>get { return 0 }
>set {
>  self = Self()
>}
>  }
> }
> 
> class C : P {
>  required init() {}
> }
> 
> Note that the mutating setter for ‘x’ assigns to ‘self’, which is totally 
> fine — it’s defined in a protocol extension of a non-class protocol P.
> 
> Let’s try to use our concrete class type with our function takesP():
> 
> let c = C()
> var cc = c
> 
> takesP(p: &cc)
> 
> print(c === cc)
> 
> When you compile and run this, it outputs ‘true’, which is not what you would 
> expect from reading the code, since the setter re-assigns ‘self’.
> 
> Ok, maybe we can just tell people that if your class conforms to a non-class 
> protocol, then assignments to ‘self’ inside implementations of the protocol 
> requirement are not allowed, and are silently dropped.
> 
> Now look at how we compile this version of takesP:
> 
> extension P {
>  mutating func foo() {
>self = Self()
>  }
> }
> 
> func takesP(p: inout P & AnyObject) {
>  p.foo()
> }
> 
> Here instead of calling a mutating setter, we call a mutating method.
> 
> If we look at the SILGen, there is no stack allocation anymore, instead we 
> pass the class reference directly as an inout argument, which is wrong:
> 
>  %7 = open_existential_ref %6 : $AnyObject & P to 
> $@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & P
>  %8 = witness_method $@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") 
> AnyObject & P, #P.foo!1, %7 : 
> $@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & P : 
> $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (@inout τ_0_0) -> ()
>  %9 = apply %8<@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & 
> P>(%7) : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (@inout τ_0_0) 
> -> ()
> 
> In a no-

[swift-dev] Miscompile with protocol compositions

[Slava Pestov via swift-dev]

Hi all,

I’ve spent most of the last two days debugging various issues with property and 
subscript accesses on class-constrained existentials and I’ve just now realized 
the root cause is a much more fundamental issue.

Consider the following code:

protocol P {
  var x: Int { get set }

  init()
}

func takesP(p: inout P & AnyObject) {
  p.x = 1
}

Note that ‘takesP’ has a class-constrained existential type as a parameter. You 
can replace AnyObject with any class protocol, it won’t change anything below.

Also, the init() requirement in the protocol will come into play later — for 
now, just consider the ‘var x’, which has a mutating setter.

The above code compiles fine. Let’s take a look at the SILGen though:

  %2 = load [copy] %0 : $*AnyObject & P
  %3 = open_existential_ref %2 : $AnyObject & P to 
$@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P
...
  %8 = alloc_stack $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & 
P
  store %3 to [init] %8 : $*@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") 
AnyObject & P
  %10 = witness_method $@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") 
AnyObject & P, #P.x!setter.1, %3 : 
$@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & P : 
$@convention(witness_method) <τ_0_0 where τ_0_0 : P> (Int, @inout τ_0_0) -> ()
  %11 = apply %10<@opened("52860F0E-2B19-11E7-8595-34363BD08DA0") AnyObject & 
P>(%7, %8) : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (Int, @inout 
τ_0_0) -> ()

So we load the ‘AnyObject & P’ existential value from our inout argument, then 
in order to call the protocol requirement for x’s setter, which takes the 
‘self’ value as an indirect argument, we allocate a box on the stack, store the 
reference into the box, call the requirement with the address of the box as the 
value of ‘self’, and destroy the box. We never write the result back to the 
inout.

So consider the following implementation of a concrete type conforming to P:

extension P {
  var x: Int {
get { return 0 }
set {
  self = Self()
}
  }
}

class C : P {
  required init() {}
}

Note that the mutating setter for ‘x’ assigns to ‘self’, which is totally fine 
— it’s defined in a protocol extension of a non-class protocol P.

Let’s try to use our concrete class type with our function takesP():

let c = C()
var cc = c

takesP(p: &cc)

print(c === cc)

When you compile and run this, it outputs ‘true’, which is not what you would 
expect from reading the code, since the setter re-assigns ‘self’.

Ok, maybe we can just tell people that if your class conforms to a non-class 
protocol, then assignments to ‘self’ inside implementations of the protocol 
requirement are not allowed, and are silently dropped.

Now look at how we compile this version of takesP:

extension P {
  mutating func foo() {
self = Self()
  }
}

func takesP(p: inout P & AnyObject) {
  p.foo()
}

Here instead of calling a mutating setter, we call a mutating method.

If we look at the SILGen, there is no stack allocation anymore, instead we pass 
the class reference directly as an inout argument, which is wrong:

  %7 = open_existential_ref %6 : $AnyObject & P to 
$@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & P
  %8 = witness_method $@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") 
AnyObject & P, #P.foo!1, %7 : $@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") 
AnyObject & P : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (@inout 
τ_0_0) -> ()
  %9 = apply %8<@opened("F78B53CA-2B18-11E7-A73C-34363BD08DA0") AnyObject & 
P>(%7) : $@convention(witness_method) <τ_0_0 where τ_0_0 : P> (@inout τ_0_0) -> 
()

In a no-asserts build, like Swift 3.1 GM, this produces a binary which crashes 
at runtime. In an asserts build, we hit an assertion in Sema:

Assertion failed: (fromType->is() && "Can only convert lvalues to 
inout"), function coerceObjectArgumentToType, file 
/Users/slava/new/swift/lib/Sema/CSApply.cpp, line 6336.

There seem to be two fundamental problems here:

1) Sema models the base expression of a mutating member as an RValue, because 
it checks if the base expression type has reference semantics, not the *self 
type of the member*.

2) SIL cannot express an inout access performed on the payload of class 
existential.

#1 is easy enough to fix, and allows my code examples involving subclass 
existentials to type check without hitting the LValue assertion.

#2 is more fundamental. At first I thought it would be sufficient to change 
SILGen to only use class existential representation for protocol compositions 
where *all* members are class-constrained, instead of protocol compositions 
where *any* member is class-constrained. However this is insufficient because a 
class-constrained protocol can refine a non-class constrained protocol.

We could say that a class-constrained protocol only uses class existential 
representation if all protocols it inherits also use class existential 
representation. Basically, split up ProtocolDecl::require

[swift-dev] IRGen's swift_rt_* functions

[Slava Pestov via swift-dev]

Hi all,

Now that we’re using swiftcc, does IRGen still need to emit the swift_rt_* 
wrappers around runtime calls? They look like no-ops at this point since the 
runtime entry points themselves should be swiftcc with the callee save variant?

Slava
___
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) #2124

[Slava Pestov via swift-dev]

This is most definitely not your fault, because it is my fault, from the 
subclass existential runtime changes. I first saw the failure a few days ago 
but it slipped my mind. Will look at it now.

Slava

> On Apr 18, 2017, at 6:01 PM, Jordan Rose via swift-dev  
> wrote:
> 
>  TEST 'Swift-Unit :: 
> runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata' FAILED 
> 
> 
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/unittests/runtime/Metadata.cpp:462:
>  Failure
>   Expected: ab
>   Which is: 0x53e6e0
> To be equal to: ba
>   Which is: 0x53e7d0
> 
> 
> This can't possibly be my commit.
> 
> 
>> On Apr 18, 2017, at 18:01, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#2124]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/2124/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04
>> Date of build:   Tue, 18 Apr 2017 17:25:59 -0700
>> Build duration:  35 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 e88e93cabf72ba487362a6b25a8674c72d6f77e1 by Jordan Rose:
>> Use PrettyStackTrace to say /which/ SIL function already exists.
>> 
>> edit: lib/SIL/SILFunction.cpp
> 
> ___
> 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 - Long Test (master) #2126

[Slava Pestov via swift-dev]

This could be a regression from https://github.com/apple/swift/pull/8770 
. I’ll take a look.

> On Apr 14, 2017, at 9:08 PM, Andrew Trick via swift-dev  
> wrote:
> 
> > runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED
> 
> This is unrelated to my commit and recovered on the next build. Is it 
> spurious? Can CI be taught to recognize known spurious asserts?
> 
> -Andy
> 
> 
>> On Apr 14, 2017, at 7:51 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#2126]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/2126/
>>  
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04-long-test
>> Date of build:   Fri, 14 Apr 2017 19:18:26 -0700
>> Build duration:  33 min
>> Identified problems:
>> 
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all errors:
>> Indication 1 
>> 
>> Changes
>> 
>> Commit 915b3198107fb1f0c200e433227dcca7c9943343 by Andrew Trick:
>> [AccessEnforce] must handle `undef` before diagnostics.
>> 
>> edit: lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp
>> edit: test/SILOptimizer/access_enforcement_selection.swift
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] IRGen variadic function declaration

[Slava Pestov via swift-dev]

Please don’t use @_silgen_name. Soon it will only be available within the 
standard library.

Instead, write C wrappers around your intrinsics and create a Clang module that 
you can import from Swift. If you define the wrappers as static inline 
functions in a header file there won’t be any runtime overhead.

Slava

> On Apr 11, 2017, at 2:27 PM, Richard Wei via swift-dev  
> wrote:
> 
> Hello,
> 
> I’m trying to declare (using _silgen_name) a Swift function that maps onto an 
> IR intrinsic with argument (i32, …). Is there a way to emit the exact 
> variadic function from Swift?
> 
> -Richard
> ___
> 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] Compiler crash when optimisation enabled

[Slava Pestov via swift-dev]

Correction — the PR is for swift-3.1-branch, not master. The fix went into 
master in February so the latest master snapshots (not 4.0 snapshots, which 
isn’t a thing that exists) should have it already.

https://github.com/apple/swift/commit/2307145c0ef7daaefe4fe0ac20fedb17f0b22730 
<https://github.com/apple/swift/commit/2307145c0ef7daaefe4fe0ac20fedb17f0b22730>

Slava

> On Apr 7, 2017, at 7:55 PM, Slava Pestov via swift-dev  
> wrote:
> 
> There’s a chance this might already be fixed — 
> https://github.com/apple/swift/pull/8588 
> <https://github.com/apple/swift/pull/8588>. Do you mind trying a 4.0 snapshot 
> when it rolls around (probably tomorrow)?
> 
> Slava
> 
>> On Apr 7, 2017, at 8:32 AM, Mark Woollard via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> https://bugs.swift.org/browse/SR-4528 <https://bugs.swift.org/browse/SR-4528>
>> 
>>> On 7 Apr 2017, at 16:22, Johannes Weiß >> <mailto:johanneswe...@apple.com>> wrote:
>>> 
>>> fantastic, that's definitely a Swift/LLVM bug. From what I can see the most 
>>> relevant bit is
>>> 
>>> --- SNIP ---
>>>>  "output": "PHI node operands are not the same type as the result!\n  %384 
>>>> = phi %CSo7UIColor* [ %395, %394 ], [ %377, %379 ], !dbg !469\nPHI node 
>>>> operands are not the same type as the result!\n  %395 = phi %CSo7UIColor* 
>>>> [ %349, %346 ], [ %377, %378 ], !dbg !469\nPHI node operands are not the 
>>>> same type as the result!\n  %738 = phi %CSo7UIColor* [ %749, %748 ], [ 
>>>> %731, %733 ], !dbg !517\nPHI node operands are not the same type as the 
>>>> result!\n  %749 = phi %CSo7UIColor* [ %703, %700 ], [ %731, %732 ], !dbg 
>>>> !517\nPHI node operands are not the same type as the result!\n  %1109 = 
>>>> phi %CSo7UIColor* [ %1125, %1124 ], [ %1102, %1104 ], !dbg !562\nPHI node 
>>>> operands are not the same type as the result!\n  %1125 = phi %CSo7UIColor* 
>>>> [ %1074, %1071 ], [ %1102, %1103 ], !dbg !562\nPHI node operands are not 
>>>> the same type as the result!\n  %1462 = phi %CSo7UIColor* [ %1478, %1477 
>>>> ], [ %1455, %1457 ], !dbg !604\nPHI node operands are not the same type as 
>>>> the result!\n  %1478 = phi %CSo7UIColor* [ %1427, %1424 ], [ %1455, %1456 
>>>> ], !dbg !604\nLLVM ERROR: Broken function found, compilation aborted!\n",
>>> --- SNAP ---
>>> 
>>> I'm sure the Swift developers will be most interested in a bug report will 
>>> all this info.
>>> 
>>> Cheers,
>>>  Johannes
>>> 
>>>> On 7 Apr 2017, at 15:39, Mark Woollard >>> <mailto:mark.wooll...@mac.com>> wrote:
>>>> 
>>>> Looks like running in Terminal may give you a lot more of a clue, got the 
>>>> following output:
>>>> 
>>>> 17227
>>>> {
>>>>  "kind": "began",
>>>>  "name": "compile",
>>>>  "command": 
>>>> "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/bin\/swift
>>>>  -frontend -emit-bc 
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppearanceManager.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppAgenciesRequest.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppOperatorsResponse.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/ProductOptionsManager.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/GeoJSON.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/PlacePointPropertiesService.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/ColorTheme.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/Dip.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppSearchRequest.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/CodeableAgency.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppSearchResponse.swift
>>>>  
>>>> \/Users\/markw\/UrbanThings\/zt

Re: [swift-dev] Compiler crash when optimisation enabled

[Slava Pestov via swift-dev]

There’s a chance this might already be fixed — 
https://github.com/apple/swift/pull/8588 
. Do you mind trying a 4.0 snapshot 
when it rolls around (probably tomorrow)?

Slava

> On Apr 7, 2017, at 8:32 AM, Mark Woollard via swift-dev  
> wrote:
> 
> https://bugs.swift.org/browse/SR-4528 
> 
>> On 7 Apr 2017, at 16:22, Johannes Weiß > > wrote:
>> 
>> fantastic, that's definitely a Swift/LLVM bug. From what I can see the most 
>> relevant bit is
>> 
>> --- SNIP ---
>>>  "output": "PHI node operands are not the same type as the result!\n  %384 
>>> = phi %CSo7UIColor* [ %395, %394 ], [ %377, %379 ], !dbg !469\nPHI node 
>>> operands are not the same type as the result!\n  %395 = phi %CSo7UIColor* [ 
>>> %349, %346 ], [ %377, %378 ], !dbg !469\nPHI node operands are not the same 
>>> type as the result!\n  %738 = phi %CSo7UIColor* [ %749, %748 ], [ %731, 
>>> %733 ], !dbg !517\nPHI node operands are not the same type as the result!\n 
>>>  %749 = phi %CSo7UIColor* [ %703, %700 ], [ %731, %732 ], !dbg !517\nPHI 
>>> node operands are not the same type as the result!\n  %1109 = phi 
>>> %CSo7UIColor* [ %1125, %1124 ], [ %1102, %1104 ], !dbg !562\nPHI node 
>>> operands are not the same type as the result!\n  %1125 = phi %CSo7UIColor* 
>>> [ %1074, %1071 ], [ %1102, %1103 ], !dbg !562\nPHI node operands are not 
>>> the same type as the result!\n  %1462 = phi %CSo7UIColor* [ %1478, %1477 ], 
>>> [ %1455, %1457 ], !dbg !604\nPHI node operands are not the same type as the 
>>> result!\n  %1478 = phi %CSo7UIColor* [ %1427, %1424 ], [ %1455, %1456 ], 
>>> !dbg !604\nLLVM ERROR: Broken function found, compilation aborted!\n",
>> --- SNAP ---
>> 
>> I'm sure the Swift developers will be most interested in a bug report will 
>> all this info.
>> 
>> Cheers,
>>  Johannes
>> 
>>> On 7 Apr 2017, at 15:39, Mark Woollard >> > wrote:
>>> 
>>> Looks like running in Terminal may give you a lot more of a clue, got the 
>>> following output:
>>> 
>>> 17227
>>> {
>>>  "kind": "began",
>>>  "name": "compile",
>>>  "command": 
>>> "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/bin\/swift
>>>  -frontend -emit-bc 
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppearanceManager.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppAgenciesRequest.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppOperatorsResponse.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/ProductOptionsManager.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/GeoJSON.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/PlacePointPropertiesService.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/ColorTheme.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/Dip.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppSearchRequest.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/CodeableAgency.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/AppSearchResponse.swift
>>>  
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/CheckerShared\/DipObjCAdapter.swift
>>>  -target arm64-apple-ios8.0 -Xllvm -aarch64-use-tbi -enable-objc-interop 
>>> -sdk 
>>> \/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Developer\/SDKs\/iPhoneOS10.3.sdk
>>>  -I 
>>> \/Users\/markw\/Library\/Developer\/Xcode\/DerivedData\/ZipTrip-fnpqeenuvfvjnbcckyfzwkgbdlxn\/Build\/Intermediates\/ArchiveIntermediates\/ZipTrip\/BuildProductsPath\/Release-iphoneos
>>>  -F 
>>> \/Users\/markw\/Library\/Developer\/Xcode\/DerivedData\/ZipTrip-fnpqeenuvfvjnbcckyfzwkgbdlxn\/Build\/Intermediates\/ArchiveIntermediates\/ZipTrip\/BuildProductsPath\/Release-iphoneos
>>>  -F \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios -F 
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/..\/Fabric -F 
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/..\/GoogleMaps -F 
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/..\/Facebook -F 
>>> \/Users\/markw\/UrbanThings\/zt\/checker_frameworks_ios\/..\/GoogleSignIn 
>>> -application-extension -g -import-underlying-module -module-cache-path 
>>> \/Users\/markw\/Library\/Developer\/Xcode\/DerivedData\/ModuleCache -D 
>>> RELEASE -serialize-debugging-options -Xcc 
>>> -I\/Users\/markw\/Library\/Developer\/Xcode\/DerivedData\/ZipTrip-fnpqeenuvfvjnbcckyfzwkgbdlxn\/Build\/Intermediates\/ArchiveIntermediates\/ZipTrip\/IntermediateBuildFilesPath\/Checker.build\/Release-iphoneos\/CheckerShared.build\/swift-overrides.hmap
>>>  -Xcc

Re: [swift-dev] Unexpected Expr type

[Slava Pestov via swift-dev]

Here’s what the AST looks like in this case — there is a ParenExpr but it’s 
inside a LoadExpr — we’re semantically loading the largest sub-expression 
that’s an lvalue, which here is ‘(x)’ not ‘x’:

  (assign_expr
(declref_expr type='@lvalue Int' accessKind=write location=x.swift:3:1 
range=[x.swift:3:1 - line:3:1] decl=x.(file).v@x.swift:1:5 direct_to_storage 
function_ref=unapplied specialized=no)
(load_expr implicit type='(Int)' location=x.swift:3:6 
range=[x.swift:3:5 - line:3:7]
  (paren_expr type='(@lvalue Int)' accessKind=read location=x.swift:3:6 
range=[x.swift:3:5 - line:3:7]
(declref_expr type='@lvalue Int' accessKind=read 
location=x.swift:3:6 range=[x.swift:3:6 - line:3:6] decl=x.(file).v@x.swift:1:5 
direct_to_storage function_ref=unapplied specialized=no)))

Slava

> On Apr 6, 2017, at 4:02 PM, Halen Wooten via swift-dev  
> wrote:
> 
> Hi Jordan,
> 
> Thanks for your reply. I tried the `dyn_cast(src)`, but it
> gives me null. Here's what I've added:
> 
> bool TypeChecker::diagnoseSelfAssignment(const Expr *E) {
> 
>  ...
> 
>  auto src = AE->getSrc();
>  auto parenSrc = dyn_cast(src);
>  if (parenSrc)
>return false;
> 
> ...
> 
> }
> 
> 
> 
> On Thu, Apr 6, 2017 at 6:49 PM, Jordan Rose  wrote:
>> Hi, Halen. Welcome to the compiler. :-) What you're seeing is that we don't
>> usually use C++'s normal RTTI mechanism, but instead go with a "Kind" field
>> that's checked by the custom 'cast', 'dyn_cast', and 'isa' functions. (More
>> information in the LLVM Programmer's Manual.) The debugger doesn't know
>> about this, so it just always shows the base class to be conservative. If
>> you're debugging, you can call dump() to see what kind of Expr it really is,
>> and then cast the pointer down to the right type as needed. In your actual
>> code, you can check `isa(src)`, or `dyn_cast(src)` if
>> you then need to manipulate the ParenExpr.
>> 
>> Hope that helps,
>> Jordan
>> 
>> 
>> On Apr 6, 2017, at 15:30, Halen Wooten via swift-dev 
>> wrote:
>> 
>> Hi swift devs,
>> 
>> I'm working on SR-4464 to learn how to contribute to Swift. I think I
>> have the solution, but I'm getting unexpected results.
>> 
>> I'm using the swift repl within Xcode for testing. Here's my test code.
>> 
>> var name = "name"
>> name = (name)
>> 
>> In TypeChecker::diagnoseSelfAssignment in CSDiag.cpp, the src of the
>> AssignExpr is a plain Expr *, but I would expect it to be a ParenExpr
>> *. Could someone help me figure out what's happening?
>> 
>> Thanks,
>> Halen
>> ___
>> 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] PR test failing with clang compile error

[Slava Pestov via swift-dev]

I have a fix pending in this PR: https://github.com/apple/swift/pull/8594 
<https://github.com/apple/swift/pull/8594>

But I’m surprised this wasn’t caught in CI.

Slava

> On Apr 6, 2017, at 2:58 PM, Mishal Shah  wrote:
> 
> Hi Slave, 
> 
> This started after following commits:
> 
> https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/ 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/>
> Git (clang)
> 
> Change -ffp-contract=fast test to run on Aarch64 (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> Remove -ffp-contract=fast from this test (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> Encapsulate FPOptions and use it consistently (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> Use FPContractModeKind universally (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> Use 'unsigned' for enum bitfields (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> Set FMF for -ffp-contract=fast (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> Add #pragma clang fp (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> Fix sphinx warning from r299470 (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> Another attempt to fix the sphinx warning from r299470 (detail 
> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>)
> 
> Thanks, 
> Mishal Shah
>> On Apr 6, 2017, at 2:53 PM, Slava Pestov via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> Hi all,
>> 
>> I’m hitting this in github PR testing:
>> 
>> /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/swift/lib/ClangImporter/ImportDecl.cpp:994:34:
>>  error: no matching constructor for initialization of 'clang::BinaryOperator'
>> 
>>auto cSetterExpr = new (Ctx) clang::BinaryOperator(cSetterMemberExpr,
>> ^ ~~
>> /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2929:3:
>>  note: candidate constructor not viable: no known conversion from 'bool' to 
>> 'clang::FPOptions' for 8th argument
>>  BinaryOperator(Expr *lhs, Expr *rhs, Opcode opc, QualType ResTy,
>>  ^
>> /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:3085:3:
>>  note: candidate constructor not viable: requires 9 arguments, but 8 were 
>> provided
>>  BinaryOperator(Expr *lhs, Expr *rhs, Opcode opc, QualType ResTy,
>>  ^
>> /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:3100:3:
>>  note: candidate constructor not viable: requires 2 arguments, but 8 were 
>> provided
>>  BinaryOperator(StmtClass SC, EmptyShell Empty)
>>  ^
>> /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2947:12:
>>  note: candidate constructor not viable: requires single argument 'Empty', 
>> but 8 arguments were provided
>>  explicit BinaryOperator(EmptyShell Empty)
>>   ^
>> /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2913:7:
>>  note: candidate constructor (the implicit copy constructor) not viable: 
>> requires 1 argument, but 8 were provided
>> class BinaryOperator : public Expr {
>>  ^
>> /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2913:7:
>>  note: candidate constructor (the implicit move constructor) not viable: 
>> requires 1 argument, but 8 were provided
>> 1 error generated.
>> 
>> Is there a Clang/LLVM merge in progress or something?
>> 
>> Slava
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 

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

[swift-dev] PR test failing with clang compile error

[Slava Pestov via swift-dev]

Hi all,

I’m hitting this in github PR testing:

/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/swift/lib/ClangImporter/ImportDecl.cpp:994:34:
 error: no matching constructor for initialization of 'clang::BinaryOperator'

auto cSetterExpr = new (Ctx) clang::BinaryOperator(cSetterMemberExpr,
 ^ ~~
/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2929:3:
 note: candidate constructor not viable: no known conversion from 'bool' to 
'clang::FPOptions' for 8th argument
  BinaryOperator(Expr *lhs, Expr *rhs, Opcode opc, QualType ResTy,
  ^
/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:3085:3:
 note: candidate constructor not viable: requires 9 arguments, but 8 were 
provided
  BinaryOperator(Expr *lhs, Expr *rhs, Opcode opc, QualType ResTy,
  ^
/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:3100:3:
 note: candidate constructor not viable: requires 2 arguments, but 8 were 
provided
  BinaryOperator(StmtClass SC, EmptyShell Empty)
  ^
/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2947:12:
 note: candidate constructor not viable: requires single argument 'Empty', but 
8 arguments were provided
  explicit BinaryOperator(EmptyShell Empty)
   ^
/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2913:7:
 note: candidate constructor (the implicit copy constructor) not viable: 
requires 1 argument, but 8 were provided
class BinaryOperator : public Expr {
  ^
/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/llvm/tools/clang/include/clang/AST/Expr.h:2913:7:
 note: candidate constructor (the implicit move constructor) not viable: 
requires 1 argument, but 8 were provided
1 error generated.

Is there a Clang/LLVM merge in progress or something?

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

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

[Slava Pestov via swift-dev]

I thought this was my changes but then it cleared up on the next build.

Xi, I filed rdar://31234811  with some information. Since 
you’re the build czar can you keep an eye on this bot and see if this test 
fails again?

Slava

> On Mar 23, 2017, at 8:32 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#9017]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9017/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Thu, 23 Mar 2017 20:10:41 -0700
> Build duration:   21 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 1 test(s), Passed: 9095 test(s), Total: 9096 test(s)
> Failed: 
> Swift(macosx-x86_64).stdlib/Slice.Slice_Of_MinimalCollection_WithPrefix.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
> 
> Changes
> 
> Commit 38f27c04964f0ed4ce7da7701e499fce16c5c929 by Slava Pestov:
> Sema: Always add synthesized accessors in the same spot
> 
> edit: test/SILGen/guaranteed_self.swift
> edit: test/SILGen/specialize_attr.swift
> edit: test/SILGen/materializeForSet.swift
> edit: lib/Sema/CodeSynthesis.cpp
> edit: test/DebugInfo/generic_enum_closure.swift
> edit: test/SILGen/addressors.swift
> edit: test/SILGen/ivar_destroyer.swift
> edit: test/IRGen/class_resilience.swift
> edit: test/SILGen/dynamic.swift
> 
> Commit c94e6b8a5e36039be1d7f25e5e853eca48f0b697 by Slava Pestov:
> SIL: Add new SILVTableVisitor
> 
> add: include/swift/SIL/SILVTableVisitor.h
> 
> Commit b42675c2352017b698c6e4ed01368b9988a5d3f4 by Slava Pestov:
> IRGen: Use SILVTableVisitor instead of bespoke member traversal
> 
> edit: lib/IRGen/GenMeta.cpp
> edit: lib/IRGen/ClassMetadataLayout.h
> edit: lib/IRGen/GenMeta.h
> 
> Commit 1a9fe1fb7405ed4846f66a1a612875bd45507372 by Slava Pestov:
> SILGen: Use SILVTableVisitor instead of bespoke member traversal
> 
> edit: test/SILGen/errors.swift
> edit: test/SILGen/ivar_destroyer.swift
> edit: test/SILGen/dynamic.swift
> edit: test/SILGen/functions.swift
> edit: test/SILGen/final.swift
> edit: lib/SIL/SILDeclRef.cpp
> edit: test/DebugInfo/initializer.swift
> edit: test/SILGen/sil_locations_top_level.swift
> edit: test/SILGen/objc_attr_NSManaged.swift
> edit: lib/SILGen/SILGenType.cpp
> edit: test/SILGen/lifetime.swift
> edit: test/SILGen/SILDeclRef.swift
> edit: test/SILGen/complete_object_init.swift

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

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

[Slava Pestov via swift-dev]

This needs someone to clean the workspace.

> On Feb 20, 2017, at 9:30 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2035]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2035/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Mon, 20 Feb 2017 21:18:48 -0800
> Build duration:   11 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8996 test(s), Total: 8996 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 341 test(s), Total: 341 test(s)
> 
> Changes
> 
> Commit 33a8ce6e7bff6fdc7b4b58585c67e998a0153efd by spestov:
> AST: Canonicalize types with respect to generic signature when mangling
> 
> edit: test/SILGen/generic_witness.swift
> edit: test/SILGen/nested_generics.swift
> edit: test/SILGen/same_type_abstraction.swift
> edit: include/swift/AST/Mangle.h
> edit: test/SourceKit/DocSupport/doc_clang_module.swift.response
> edit: lib/AST/ASTMangler.cpp
> edit: lib/AST/Mangle.cpp
> edit: test/SILGen/constrained_extensions.swift
> edit: include/swift/AST/ASTMangler.h
> edit: test/SILGen/generic_tuples.swift

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

Re: [swift-dev] Profiling ARC

[Slava Pestov via swift-dev]

> On Feb 16, 2017, at 6:48 PM, Jiho Choi via swift-dev  
> wrote:
> 
> Hi,
> 
> I was curious about the overhead of ARC and started profiling some benchmarks 
> found in the Computer Language Benchmark Game 
> (http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift 
> ).  
> So far, it seems that ARC sequence optimization is surprisingly good and most 
> benchmarks don't have to perform ARC operations as often as I expected.  I 
> have some questions regarding this finding.
> 
> I compiled all benchmarks with "-O -wmo" flags and counted the number of 
> calls to ARC runtime (e.g., swift_rt_swift_retain) using Pin.
> 
> 1. Reference counting is considered to have high overhead due to frequent 
> counting operations which also have to be atomic.  At least for the 
> benchmarks I tested, it is not the case and there is almost no overhead.  Is 
> it expected behavior?  Or is it because the benchmarks are too simple (they 
> are all single-file programs)?  How do you estimate the overhead of ARC would 
> be?

It is possible that the optimizer eliminated many reference counting operations 
here. Also my understanding is that while atomic operations are more expensive 
than non-atomic operations, the real cost only comes into play if you actually 
have contention due to bouncing cache lines. In a single-threaded workload the 
overhead is not that great.

> 
> 2. I also tried to compile the same benchmarks with "-Xfrontend 
> -assume-single-threaded" to measure the overhead of atomic operations.  
> Looking at the source code of this experimental pass and SIL optimizer's 
> statistic, the pass seems to work as expected to convert all ARC operations 
> in user code into nonatomic.  However, even when using this flag, there are 
> some atomic ARC runtime called from the user code (not library).  More 
> strangely, SIL output said all ARC operations in the user code have turned 
> into nonatomic.  The documentation says ARC operations are never implicit in 
> SIL.  So if there is no atomic ARC at SIL-level, I expect the user code would 
> never call atomic ARC runtime.  Am I missing something?

IRGen still emits atomic reference counting operations when it produces value 
witness operations. I think there’s a PR open right now to address this: 
https://github.com/apple/swift/pull/7421 


> 
> 3. Are there more realistic benchmarks available?  Swift's official 
> benchmarks also seem pretty small.

Contributions are welcome :-)

> 
> Thanks,
> Jiho
> ___
> 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 16.10 (master) #1892

[Slava Pestov via swift-dev]

I’ve seen this before. It would be useful if we kept all old CI logs in an 
easily searchable form.

Slava

> On Feb 13, 2017, at 1:28 PM, Jordan Rose via swift-dev  
> wrote:
> 
> clang-4.0: error: unable to execute command: Bus error
> clang-4.0: error: linker command failed due to signal (use -v to see 
> invocation)
> 
> This pretty much can't be Arnold's commit. I'm going to wait a build to see 
> if it happens again.
> 
> Jordan
> 
>> On Feb 13, 2017, at 13:25, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1892]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1892/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Mon, 13 Feb 2017 13:12:16 -0800
>> Build duration:  13 min
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Regression test failed: This build failed because a regression test in the 
>> test suite FAILed. Below is a list of all errors:
>> Indication 1 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 1 test(s), Passed: 8964 test(s), Total: 8965 test(s)
>> Failed: Swift(linux-x86_64).AutolinkExtract.import_archive.swift 
>> 
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 307 test(s), Total: 307 test(s)
>> 
>> Changes
>> 
>> Commit 7ea00ab6d76ed49176bf57b55ad6342d4a83d592 by aschwaighofer:
>> swiftcc: Don't emit tail calls from callers with swifterror parameters
>> 
>> edit: test/CodeGen/AArch64/swifterror.ll
>> edit: test/CodeGen/ARM/swifterror.ll
>> edit: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
>> edit: test/CodeGen/X86/swifterror.ll
> 
> ___
> 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] Why doesn't CaptureListExpr hold a ClosureExpr?

[Slava Pestov via swift-dev]

> On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch  wrote:
> 
> Thanks to the magic of git blame:
> 
>   
> https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b
>  
> 
> 
> 
> > Unless you think there’s something to be gained, I’m not sure it’s worth it…
> 
> I was going for idiot-proof-ness of the AST types. I'd never heard of 
> CaptureListExpr before and would've just assumed it was part of ClosureExpr. 
> But it looks like the change was pretty intentional. (Maybe someone can share 
> what rdar://19146761 was?)

"This crashes the compiler, we’re not setting up declcontext’s right:

func f(a : () -> ()) {}

class C {
  var i = 42

  func g() {
f({ [myI = {i}] in () })
  }
}"

> 
> On Tue, Feb 7, 2017 at 9:27 PM, John McCall  > wrote:
>> On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> I don't think it would be a very big parser change to invert the 
>> relationship. Maybe I'll try it out and put up another PR.
>> 
>> On the other hand, noticed the header comment says:
>> 
>> /// ...Because the capture list is evaluated outside of the closure, this
>> /// CaptureList wraps the ClosureExpr.  The dynamic semantics are that 
>> evaluates
>> /// the variable bindings from the capture list, then evaluates the
>> /// subexpression (the closure itself) and returns the result.
> 
> I think the original representation just made the captures part of the 
> ClosureExpr, and IIRC Chris changed it to this intentionally.  I don't 
> remember why; maybe it was causing problems for some tooling that wanted to 
> walk the expression tree and find uses of the variable?  It's certainly 
> kindof weird for IRGen.
> 
> John.
> 
>> 
>> 🤷‍
>> 
>> On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov > > wrote:
>> 
>>> On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch >> > wrote:
>>> 
>>> PR'd:  https://github.com/apple/swift/pull/7326 
>>> 
>>> 
>>> Although I would also ask: why is CaptureListExpr a parent of ClosureExpr 
>>> and not a child?
>> 
>> I think it’s kind of arbitrary. You could also argue that they should be one 
>> and the same AST node. I think right now it’s just a property of how the 
>> parser works, the capture list comes first, before the closure body?
>> 
>> Slava
>> 
>>> 
>>> Jacob
>>> 
>>> On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov >> > wrote:
>>> 
 On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev 
 mailto:swift-dev@swift.org>> wrote:
 
 I just learned about CaptureListExpr when working on some diagnostics. Is 
 there a particular reason that its member "closureBody" is an Expr* and 
 not a ClosureExpr*? There seems to be only one place it's built 
 ,
  and the body is always a ClosureExpr.
 
 I can see one minor place 
 
  where it might be less convenient to have a ClosureExpr, but otherwise 
 there doesn't seem to be much of a reason to keep it generalized to Expr*.
>>> 
>>> Since autoclosures cannot have capture lists, I think the change you’re 
>>> suggesting makes sense.
>>> 
>>> Slava
>>> 
 
 Jacob
 ___
 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] Why doesn't CaptureListExpr hold a ClosureExpr?

[Slava Pestov via swift-dev]

> On Feb 7, 2017, at 9:18 PM, Jacob Bandes-Storch  wrote:
> 
> I don't think it would be a very big parser change to invert the 
> relationship. Maybe I'll try it out and put up another PR.

Unless you think there’s something to be gained, I’m not sure it’s worth it…

> 
> On the other hand, noticed the header comment says:
> 
> /// ...Because the capture list is evaluated outside of the closure, this
> /// CaptureList wraps the ClosureExpr.  The dynamic semantics are that 
> evaluates
> /// the variable bindings from the capture list, then evaluates the
> /// subexpression (the closure itself) and returns the result.

This makes sense, but as I understand it, evaluating the closure itself has no 
side-effects so this is irrelevant.

Slava

> 
> 🤷‍
> 
> On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov  > wrote:
> 
>> On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch > > wrote:
>> 
>> PR'd:  https://github.com/apple/swift/pull/7326 
>> 
>> 
>> Although I would also ask: why is CaptureListExpr a parent of ClosureExpr 
>> and not a child?
> 
> I think it’s kind of arbitrary. You could also argue that they should be one 
> and the same AST node. I think right now it’s just a property of how the 
> parser works, the capture list comes first, before the closure body?
> 
> Slava
> 
>> 
>> Jacob
>> 
>> On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov > > wrote:
>> 
>>> On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> I just learned about CaptureListExpr when working on some diagnostics. Is 
>>> there a particular reason that its member "closureBody" is an Expr* and not 
>>> a ClosureExpr*? There seems to be only one place it's built 
>>> ,
>>>  and the body is always a ClosureExpr.
>>> 
>>> I can see one minor place 
>>> 
>>>  where it might be less convenient to have a ClosureExpr, but otherwise 
>>> there doesn't seem to be much of a reason to keep it generalized to Expr*.
>> 
>> Since autoclosures cannot have capture lists, I think the change you’re 
>> suggesting makes sense.
>> 
>> Slava
>> 
>>> 
>>> Jacob
>>> ___
>>> 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] Why doesn't CaptureListExpr hold a ClosureExpr?

[Slava Pestov via swift-dev]

> On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch  wrote:
> 
> PR'd:  https://github.com/apple/swift/pull/7326 
> 
> 
> Although I would also ask: why is CaptureListExpr a parent of ClosureExpr and 
> not a child?

I think it’s kind of arbitrary. You could also argue that they should be one 
and the same AST node. I think right now it’s just a property of how the parser 
works, the capture list comes first, before the closure body?

Slava

> 
> Jacob
> 
> On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov  > wrote:
> 
>> On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> I just learned about CaptureListExpr when working on some diagnostics. Is 
>> there a particular reason that its member "closureBody" is an Expr* and not 
>> a ClosureExpr*? There seems to be only one place it's built 
>> ,
>>  and the body is always a ClosureExpr.
>> 
>> I can see one minor place 
>> 
>>  where it might be less convenient to have a ClosureExpr, but otherwise 
>> there doesn't seem to be much of a reason to keep it generalized to Expr*.
> 
> Since autoclosures cannot have capture lists, I think the change you’re 
> suggesting makes sense.
> 
> Slava
> 
>> 
>> Jacob
>> ___
>> 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] ArchetypeBuilder rename

[Slava Pestov via swift-dev]

It’s merged. Rename all you want, see if I care!!!

> On Feb 7, 2017, at 7:46 PM, Douglas Gregor  wrote:
> 
> Go for it! I haven't even created the renaming PR and don't want to step on 
> toes. 
> 
> Sent from my iPhone
> 
> On Feb 7, 2017, at 7:13 PM, Slava Pestov  > wrote:
> 
>> Do you mind if I merge https://github.com/apple/swift/pull/7319 
>>  first? It’s ready to go in.
>> 
>> Slava
>> 
>>> On Feb 7, 2017, at 4:59 PM, Douglas Gregor via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> The ArchetypeBuilder 
>>> 
>>>  class, whose primary responsibility is to validate, minimize, and 
>>> canonicalize generic signatures, now has almost nothing to do with 
>>> archetypes. I’d like to rename it to GenericSignatureBuilder. Two questions:
>>> 
>>> 1) Does anyone have an issue with this new name?
>>> 2) Other than https://github.com/apple/swift/pull/7313 
>>>  and 
>>> https://github.com/apple/swift/pull/7319 
>>> , does anyone have significant 
>>> outstanding changes to the ArchetypeBuilder for which rebasing after a 
>>> rename would be awful? If so, I can hold off on the rename for a bit longer.
>>> 
>>> - Doug
>>> 
>>> ___
>>> 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] Why doesn't CaptureListExpr hold a ClosureExpr?

[Slava Pestov via swift-dev]

> On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev 
>  wrote:
> 
> I just learned about CaptureListExpr when working on some diagnostics. Is 
> there a particular reason that its member "closureBody" is an Expr* and not a 
> ClosureExpr*? There seems to be only one place it's built 
> ,
>  and the body is always a ClosureExpr.
> 
> I can see one minor place 
> 
>  where it might be less convenient to have a ClosureExpr, but otherwise there 
> doesn't seem to be much of a reason to keep it generalized to Expr*.

Since autoclosures cannot have capture lists, I think the change you’re 
suggesting makes sense.

Slava

> 
> Jacob
> ___
> 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] ArchetypeBuilder rename

[Slava Pestov via swift-dev]

Do you mind if I merge https://github.com/apple/swift/pull/7319 
 first? It’s ready to go in.

Slava

> On Feb 7, 2017, at 4:59 PM, Douglas Gregor via swift-dev 
>  wrote:
> 
> Hi all,
> 
> The ArchetypeBuilder 
> 
>  class, whose primary responsibility is to validate, minimize, and 
> canonicalize generic signatures, now has almost nothing to do with 
> archetypes. I’d like to rename it to GenericSignatureBuilder. Two questions:
> 
> 1) Does anyone have an issue with this new name?
> 2) Other than https://github.com/apple/swift/pull/7313 
>  and 
> https://github.com/apple/swift/pull/7319 
> , does anyone have significant 
> outstanding changes to the ArchetypeBuilder for which rebasing after a rename 
> would be awful? If so, I can hold off on the rename for a bit longer.
> 
>   - Doug
> 
> ___
> 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] Change of requirements to build swift?

[Slava Pestov via swift-dev]

I think it should still build with 10.11, however you need Xcode 8.3 beta 1 now.

Slava

> On Feb 1, 2017, at 2:48 PM, Guillaume Lessard via swift-dev 
>  wrote:
> 
> Hello,
> 
> Is master supposed to have dropped support for building on 10.11.x?
> The previous snapshot I’d built was January 24th, and it was still fine.
> 
> Thanks,
> Guillaume Lessard
> 
> ___
> 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