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

[mishal_shah via swift-dev]

Thanks! 

> On Dec 8, 2016, at 9:59 PM, Bob Wilson  wrote:
> 
> Yes, he renamed sil-extract to sil-func-extractor 
> (https://github.com/apple/swift/pull/6155/files 
> ) and missed updating some 
> places. This should fix it: https://github.com/apple/swift/pull/6159 
> 
> 
> (FWIW, I much preferred the old name. I don’t know why he changed it.)
> 
>> On Dec 8, 2016, at 8:08 PM, mishal_shah > > wrote:
>> 
>> Hi Michael,
>> 
>> Is this related to your changes? 
>> 
>> ninja: error: 'bin/sil-extract', needed by 
>> 'test/CMakeFiles/check-swift-validation-macosx-x86_64', missing and no known 
>> rule to make it
>> *** Failed while running tests for swift 
>> (check-swift-validation-macosx-x86_64)
>> 
>> Thanks,
>> Mishal Shah
>>> On Dec 8, 2016, at 7:52 PM, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-osx [#7501]
>>> 
>>> Build URL:  https://ci.swift.org/job/oss-swift-incremental-RA-osx/7501/ 
>>> 
>>> Project:oss-swift-incremental-RA-osx
>>> Date of build:  Thu, 08 Dec 2016 19:29:59 -0800
>>> Build duration: 22 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 0bfda96ace06c95fd7b8ab5c0a08ef828940f873 by mgottesman:
>>> [sil-func-extractor] Teach sil-extract to extract a list of functions
>>> 
>>> delete: test/sil-extract/basic.sil
>>> delete: test/sil-extract/basic.swift
>>> edit: test/ClangImporter/serialization-sil.swift
>>> add: test/sil-func-extractor/basic.swift
>>> delete: test/sil-extract/load-serialized-sil.swift
>>> edit: include/swift/Basic/STLExtras.h
>>> delete: tools/sil-extract/CMakeLists.txt
>>> add: test/sil-func-extractor/load-serialized-sil.swift
>>> edit: test/lit.cfg
>>> add: test/sil-func-extractor/basic.sil
>>> add: tools/sil-func-extractor/CMakeLists.txt
>>> add: tools/sil-func-extractor/SILFunctionExtractor.cpp
>>> edit: tools/CMakeLists.txt
>>> delete: tools/sil-extract/SILExtract.cpp
>>> add: test/sil-func-extractor/multiple-functions.sil
>>> 
>>> Commit 8972b43abbfb1773b2997da06873ec5fc2c94e6f by mgottesman:
>>> [sil-tooling] Rename sil-sort-output => emit-sorted-sil.
>>> 
>>> edit: tools/sil-opt/SILOpt.cpp
>>> edit: test/SIL/Serialization/semanticsattr.sil
>>> edit: test/SILOptimizer/inlinecaches_arc.sil
>>> edit: test/SILOptimizer/loop-region-analysis.sil
>>> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
>>> 
>>> Commit c12aeabd90a71e512618fdcc7d0e32adbbe1c462 by mgottesman:
>>> [sil-func-extractor] Add support for emitting sib files.
>>> 
>>> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
>>> edit: test/sil-func-extractor/basic.sil
>>> 
>>> Commit c2e63dcbc17a21ab07850a2ae151728eea8f48da by bob.wilson:
>>> Disable sanitizers for the runtime with
>>> 
>>> edit: stdlib/CMakeLists.txt
>>> 
>>> Commit 49e6c06eef75f2b6050876840bb3aeb978282be1 by jordan_rose:
>>> [validation-test] Remove "REQUIRES: asserts" from /fixed/ crash cases.
>>> 
>>> edit: 
>>> validation-test/compiler_crashers_fixed/28423-swift-typechecker-validatedecl.swift
>>> edit: 
>>> validation-test/SIL/crashers_fixed/003-swift-parser-parsetypesimple.sil
>>> edit: 
>>> validation-test/IDE/crashers_fixed/078-swift-iterativetypechecker-processtypechecksuperclass.swift
>>> edit: 
>>> validation-test/SIL/crashers_fixed/008-swift-genericparamlist-getasgenericsignatureelements.sil
>>> edit: 
>>> validation-test/compiler_crashers_fixed/28370-swift-decomposeparamtype.swift
>>> edit: 
>>> validation-test/compiler_crashers_fixed/28306-swift-lookupvisibledecls.swift
>>> edit: 
>>> validation-test/compiler_crashers_fixed/28410-swift-typechecker-typecheckdecl.swift
>>> edit: 
>>> validation-test/IDE/crashers_fixed/087-swift-declcontext-getparentmodule.swift
>>> edit: validation-test/compiler_crashers_fixed/28454-hasval-failed.swift
>>> edit: 
>>> validation-test/compiler_crashers_fixed/10659-swift-printingdiagnosticconsumer-handlediagnostic.timeout.swift
>>> edit: 
>>> validation-test/SIL/crashers_fixed/007-swift-abstractstoragedecl-makecomputed.sil
>>> edit: 
>>> validation-test/compiler_crashers_fixed/28249-swift-typechecker-validategenericfuncsignature.swift
>>> edit: 
>>> validation-test/compiler_crashers_fixed/28291-swift-constraints-constraintsystem-comparesolutions.swift
>>> edit: 
>>> validation-test/IDE/crashers_fixed/015-swift-typechecker-lookupunqualified.swift
>>> edit: 
>>> validation-test/IDE/crashers_fixed/056-swift-archetypebuilder-getallarchetypes.swift
>>> edit: 
>>> 

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

[Bob Wilson via swift-dev]

Yes, he renamed sil-extract to sil-func-extractor 
(https://github.com/apple/swift/pull/6155/files 
) and missed updating some 
places. This should fix it: https://github.com/apple/swift/pull/6159 


(FWIW, I much preferred the old name. I don’t know why he changed it.)

> On Dec 8, 2016, at 8:08 PM, mishal_shah  wrote:
> 
> Hi Michael,
> 
> Is this related to your changes? 
> 
> ninja: error: 'bin/sil-extract', needed by 
> 'test/CMakeFiles/check-swift-validation-macosx-x86_64', missing and no known 
> rule to make it
> *** Failed while running tests for swift 
> (check-swift-validation-macosx-x86_64)
> 
> Thanks,
> Mishal Shah
>> On Dec 8, 2016, at 7:52 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#7501]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-RA-osx/7501/ 
>> 
>> Project: oss-swift-incremental-RA-osx
>> Date of build:   Thu, 08 Dec 2016 19:29:59 -0800
>> Build duration:  22 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 0bfda96ace06c95fd7b8ab5c0a08ef828940f873 by mgottesman:
>> [sil-func-extractor] Teach sil-extract to extract a list of functions
>> 
>> delete: test/sil-extract/basic.sil
>> delete: test/sil-extract/basic.swift
>> edit: test/ClangImporter/serialization-sil.swift
>> add: test/sil-func-extractor/basic.swift
>> delete: test/sil-extract/load-serialized-sil.swift
>> edit: include/swift/Basic/STLExtras.h
>> delete: tools/sil-extract/CMakeLists.txt
>> add: test/sil-func-extractor/load-serialized-sil.swift
>> edit: test/lit.cfg
>> add: test/sil-func-extractor/basic.sil
>> add: tools/sil-func-extractor/CMakeLists.txt
>> add: tools/sil-func-extractor/SILFunctionExtractor.cpp
>> edit: tools/CMakeLists.txt
>> delete: tools/sil-extract/SILExtract.cpp
>> add: test/sil-func-extractor/multiple-functions.sil
>> 
>> Commit 8972b43abbfb1773b2997da06873ec5fc2c94e6f by mgottesman:
>> [sil-tooling] Rename sil-sort-output => emit-sorted-sil.
>> 
>> edit: tools/sil-opt/SILOpt.cpp
>> edit: test/SIL/Serialization/semanticsattr.sil
>> edit: test/SILOptimizer/inlinecaches_arc.sil
>> edit: test/SILOptimizer/loop-region-analysis.sil
>> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
>> 
>> Commit c12aeabd90a71e512618fdcc7d0e32adbbe1c462 by mgottesman:
>> [sil-func-extractor] Add support for emitting sib files.
>> 
>> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
>> edit: test/sil-func-extractor/basic.sil
>> 
>> Commit c2e63dcbc17a21ab07850a2ae151728eea8f48da by bob.wilson:
>> Disable sanitizers for the runtime with
>> 
>> edit: stdlib/CMakeLists.txt
>> 
>> Commit 49e6c06eef75f2b6050876840bb3aeb978282be1 by jordan_rose:
>> [validation-test] Remove "REQUIRES: asserts" from /fixed/ crash cases.
>> 
>> edit: 
>> validation-test/compiler_crashers_fixed/28423-swift-typechecker-validatedecl.swift
>> edit: validation-test/SIL/crashers_fixed/003-swift-parser-parsetypesimple.sil
>> edit: 
>> validation-test/IDE/crashers_fixed/078-swift-iterativetypechecker-processtypechecksuperclass.swift
>> edit: 
>> validation-test/SIL/crashers_fixed/008-swift-genericparamlist-getasgenericsignatureelements.sil
>> edit: 
>> validation-test/compiler_crashers_fixed/28370-swift-decomposeparamtype.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28306-swift-lookupvisibledecls.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28410-swift-typechecker-typecheckdecl.swift
>> edit: 
>> validation-test/IDE/crashers_fixed/087-swift-declcontext-getparentmodule.swift
>> edit: validation-test/compiler_crashers_fixed/28454-hasval-failed.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/10659-swift-printingdiagnosticconsumer-handlediagnostic.timeout.swift
>> edit: 
>> validation-test/SIL/crashers_fixed/007-swift-abstractstoragedecl-makecomputed.sil
>> edit: 
>> validation-test/compiler_crashers_fixed/28249-swift-typechecker-validategenericfuncsignature.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28291-swift-constraints-constraintsystem-comparesolutions.swift
>> edit: 
>> validation-test/IDE/crashers_fixed/015-swift-typechecker-lookupunqualified.swift
>> edit: 
>> validation-test/IDE/crashers_fixed/056-swift-archetypebuilder-getallarchetypes.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28298-swift-namealiastype-getsinglydesugaredtype.swift
>> edit: validation-test/Sema/type_checker_crashers_fixed/rdar27575060.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28207-swift-dependentgenerictyperesolver-resolveselfassociatedtype.swift
>> edit: 

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

[Frederick Kellison-Linn via swift-dev]

Good idea.

In the end, I resolved the issue by renaming /opt/local/bin/ld which meant that 
clang used /usr/bin/ld, which had an appropriate LLVM version. Would be good if 
the build script utilized the Xcode toolchain instead of relying on system 
settings.

Freddy



> On Dec 8, 2016, at 9:09 PM, William Dillon  wrote:
> 
> Try it with a PATH that does not include /opt/local/*
> 
> I haven’t build on MacOS in a long time, so I can’t say with any more detail 
> how the tools (clang, ld, etc.) are chosen when building swift ¯\_(ツ)_/¯ 
> 
> Good luck :)
> - Will
> 
>> On December 8, 2016 at 6:05:12 PM, Frederick Kellison-Linn (fred...@me.com) 
>> wrote:
>> which ld gives the same /opt/local version
>> 
>> My path is
>> 
>> /opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/Users/freddy/anaconda3/bin:/opt/local/bin:/opt/local/sbin:/Users/freddy/.rvm/gems/ruby-2.1.1/bin:/Users/freddy/.rvm/gems/ruby-2.1.1@global/bin:/Users/freddy/.rvm/rubies/ruby-2.1.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/usr/local/MacGPG2/bin:/Library/TeX/texbin:/Users/freddy/.rvm/bin
>> 
>> Freddy
>> 
>>> On Dec 8, 2016, at 5:31 PM, William Dillon  wrote:
>>> 
>>> What if you try:
>>> 
>>> which ld
>>> 
>>> And, what’s your PATH?
>>> 
 On December 8, 2016 at 2:19:20 PM, Frederick Kellison-Linn 
 (fred...@me.com) wrote:
 
 Yeah that seems wrong to me as well. Do you know how I can change the 
 linker that clang invokes?
 
 Freddy
 
> On Dec 8, 2016, at 5:16 PM, William Dillon  
> wrote:
> 
> The Apple folks might know better and correct me, but I’m pretty certain 
> you don’t want to be using any toolchains in /opt/local.  It all needs to 
> be from the Xcode.app.
> 
> - Will
> 
>> On December 8, 2016 at 2:14:42 PM, Frederick Kellison-Linn via swift-dev 
>> (swift-dev@swift.org) wrote:
>> 
>> The output of those commands follows:
>> 
>> $ xcode-select -p
>> /Applications/Xcode.app/Contents/Developer
>> 
>> $ xcodebuild -version
>> Xcode 8.1
>> Build version 8B62
>> 
>> Both look fine to me.
>> 
>> It appears that clang is invoking /opt/local/bin/ld, and running 
>> /opt/local/bin/ld -v gives:
>> 
>> @(#)PROGRAM:ld  PROJECT:ld64-264.3.102
>> configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s 
>> armv7m armv7k arm64 (tvOS)
>> LTO support using: LLVM version 3.8.1
>> 
>> What is wrong with the config here?
>> 
>> Freddy
>>  
>>> On Dec 8, 2016, at 4:28 PM, William Dillon  
>>> wrote:
>>> 
>>> I think Greg is right.  I’ve seen this before, and the way I fixed it 
>>> was by fixing the Xcode configuration, specifically relating to the 
>>> command-line tools.
>>> 
>>> - Will
>>> 
 On December 8, 2016 at 1:24:59 PM, Greg Parker via swift-dev 
 (swift-dev@swift.org) wrote:
 
 
> On Dec 8, 2016, at 7:28 AM, Frederick Kellison-Linn via swift-dev 
>  wrote:
> 
> Hello,
> 
> I have been attempting to build Swift, but have been running into 
> issues near the end of the build. Specifically, CMake fails on the 
> step [2112/2254] Performing configure step for 'compiler-rt’, since 
> the compiled clang fails to build a simple C program. The specific 
> issue appears to be at the lines:
> 
> ld: unexpected token: !tapi-tbd-v2 file
>   
> '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
>   for architecture x86_64
> 
> My system settings are as follows:
> 
> MacBook Pro (Retina, Mid 2012)
> macOS Sierra Version 10.12.2 Beta (16C48b)
> Xcode Version 8.1 (8B62)
> |clang/clang++: Apple LLVM version 8.0.0 (clang-800.0.42.1)
> 
>   
> /Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
>   -isysroot
>   
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>   -Wl,-search_paths_first -Wl,-headerpad_max_install_names
>   CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o -o cmTC_b980a && :
> 
>   ld: unexpected token: !tapi-tbd-v2 file
>   
> '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
>   for architecture x86_64
 
 
 That error sounds like the build is trying to use an old linker that 
 does not understand the format 

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

[mishal_shah via swift-dev]

Hi Michael,

Is this related to your changes? 

ninja: error: 'bin/sil-extract', needed by 
'test/CMakeFiles/check-swift-validation-macosx-x86_64', missing and no known 
rule to make it
*** Failed while running tests for swift (check-swift-validation-macosx-x86_64)

Thanks,
Mishal Shah
> On Dec 8, 2016, at 7:52 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#7501]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/7501/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Thu, 08 Dec 2016 19:29:59 -0800
> Build duration:   22 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 0bfda96ace06c95fd7b8ab5c0a08ef828940f873 by mgottesman:
> [sil-func-extractor] Teach sil-extract to extract a list of functions
> 
> delete: test/sil-extract/basic.sil
> delete: test/sil-extract/basic.swift
> edit: test/ClangImporter/serialization-sil.swift
> add: test/sil-func-extractor/basic.swift
> delete: test/sil-extract/load-serialized-sil.swift
> edit: include/swift/Basic/STLExtras.h
> delete: tools/sil-extract/CMakeLists.txt
> add: test/sil-func-extractor/load-serialized-sil.swift
> edit: test/lit.cfg
> add: test/sil-func-extractor/basic.sil
> add: tools/sil-func-extractor/CMakeLists.txt
> add: tools/sil-func-extractor/SILFunctionExtractor.cpp
> edit: tools/CMakeLists.txt
> delete: tools/sil-extract/SILExtract.cpp
> add: test/sil-func-extractor/multiple-functions.sil
> 
> Commit 8972b43abbfb1773b2997da06873ec5fc2c94e6f by mgottesman:
> [sil-tooling] Rename sil-sort-output => emit-sorted-sil.
> 
> edit: tools/sil-opt/SILOpt.cpp
> edit: test/SIL/Serialization/semanticsattr.sil
> edit: test/SILOptimizer/inlinecaches_arc.sil
> edit: test/SILOptimizer/loop-region-analysis.sil
> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
> 
> Commit c12aeabd90a71e512618fdcc7d0e32adbbe1c462 by mgottesman:
> [sil-func-extractor] Add support for emitting sib files.
> 
> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
> edit: test/sil-func-extractor/basic.sil
> 
> Commit c2e63dcbc17a21ab07850a2ae151728eea8f48da by bob.wilson:
> Disable sanitizers for the runtime with
> 
> edit: stdlib/CMakeLists.txt
> 
> Commit 49e6c06eef75f2b6050876840bb3aeb978282be1 by jordan_rose:
> [validation-test] Remove "REQUIRES: asserts" from /fixed/ crash cases.
> 
> edit: 
> validation-test/compiler_crashers_fixed/28423-swift-typechecker-validatedecl.swift
> edit: validation-test/SIL/crashers_fixed/003-swift-parser-parsetypesimple.sil
> edit: 
> validation-test/IDE/crashers_fixed/078-swift-iterativetypechecker-processtypechecksuperclass.swift
> edit: 
> validation-test/SIL/crashers_fixed/008-swift-genericparamlist-getasgenericsignatureelements.sil
> edit: 
> validation-test/compiler_crashers_fixed/28370-swift-decomposeparamtype.swift
> edit: 
> validation-test/compiler_crashers_fixed/28306-swift-lookupvisibledecls.swift
> edit: 
> validation-test/compiler_crashers_fixed/28410-swift-typechecker-typecheckdecl.swift
> edit: 
> validation-test/IDE/crashers_fixed/087-swift-declcontext-getparentmodule.swift
> edit: validation-test/compiler_crashers_fixed/28454-hasval-failed.swift
> edit: 
> validation-test/compiler_crashers_fixed/10659-swift-printingdiagnosticconsumer-handlediagnostic.timeout.swift
> edit: 
> validation-test/SIL/crashers_fixed/007-swift-abstractstoragedecl-makecomputed.sil
> edit: 
> validation-test/compiler_crashers_fixed/28249-swift-typechecker-validategenericfuncsignature.swift
> edit: 
> validation-test/compiler_crashers_fixed/28291-swift-constraints-constraintsystem-comparesolutions.swift
> edit: 
> validation-test/IDE/crashers_fixed/015-swift-typechecker-lookupunqualified.swift
> edit: 
> validation-test/IDE/crashers_fixed/056-swift-archetypebuilder-getallarchetypes.swift
> edit: 
> validation-test/compiler_crashers_fixed/28298-swift-namealiastype-getsinglydesugaredtype.swift
> edit: validation-test/Sema/type_checker_crashers_fixed/rdar27575060.swift
> edit: 
> validation-test/compiler_crashers_fixed/28207-swift-dependentgenerictyperesolver-resolveselfassociatedtype.swift
> edit: 
> validation-test/IDE/crashers_fixed/075-swift-printoptions-setarchetypeselftransform.swift
> edit: 
> validation-test/compiler_crashers_fixed/28433-swift-typechecker-typecheckdecl.swift
> edit: 
> validation-test/compiler_crashers_fixed/28343-swift-genericfunctiontype-get.swift
> edit: validation-test/compiler_crashers_fixed/28390-swift-expr-walk.swift
> edit: 
> validation-test/compiler_crashers_fixed/28320-swift-archetypebuilder-enumeraterequirements.swift
> edit: 
> validation-test/compiler_crashers_fixed/28375-swift-typechecker-lookupmembertype.swift
> edit: 

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

[William Dillon via swift-dev]

Try it with a PATH that does not include /opt/local/*

I haven’t build on MacOS in a long time, so I can’t say with any more detail 
how the tools (clang, ld, etc.) are chosen when building swift ¯\_(ツ)_/¯ 

Good luck :)
- Will

On December 8, 2016 at 6:05:12 PM, Frederick Kellison-Linn (fred...@me.com) 
wrote:
which ld gives the same /opt/local version

My path is

/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/Users/freddy/anaconda3/bin:/opt/local/bin:/opt/local/sbin:/Users/freddy/.rvm/gems/ruby-2.1.1/bin:/Users/freddy/.rvm/gems/ruby-2.1.1@global/bin:/Users/freddy/.rvm/rubies/ruby-2.1.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/usr/local/MacGPG2/bin:/Library/TeX/texbin:/Users/freddy/.rvm/bin

Freddy

On Dec 8, 2016, at 5:31 PM, William Dillon  wrote:

What if you try:

which ld

And, what’s your PATH?

On December 8, 2016 at 2:19:20 PM, Frederick Kellison-Linn (fred...@me.com) 
wrote:

Yeah that seems wrong to me as well. Do you know how I can change the linker 
that clang invokes?

Freddy

On Dec 8, 2016, at 5:16 PM, William Dillon  wrote:

The Apple folks might know better and correct me, but I’m pretty certain you 
don’t want to be using any toolchains in /opt/local.  It all needs to be from 
the Xcode.app.

- Will

On December 8, 2016 at 2:14:42 PM, Frederick Kellison-Linn via swift-dev 
(swift-dev@swift.org) wrote:

The output of those commands follows:

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcodebuild -version
Xcode 8.1
Build version 8B62

Both look fine to me.

It appears that clang is invoking /opt/local/bin/ld, and running 
/opt/local/bin/ld -v gives:

@(#)PROGRAM:ld  PROJECT:ld64-264.3.102
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m 
armv7k arm64 (tvOS)
LTO support using: LLVM version 3.8.1

What is wrong with the config here?

Freddy
 
On Dec 8, 2016, at 4:28 PM, William Dillon  wrote:

I think Greg is right.  I’ve seen this before, and the way I fixed it was by 
fixing the Xcode configuration, specifically relating to the command-line tools.

- Will

On December 8, 2016 at 1:24:59 PM, Greg Parker via swift-dev 
(swift-dev@swift.org) wrote:


On Dec 8, 2016, at 7:28 AM, Frederick Kellison-Linn via swift-dev 
 wrote:

Hello,

I have been attempting to build Swift, but have been running into issues near 
the end of the build. Specifically, CMake fails on the step [2112/2254] 
Performing configure step for 'compiler-rt’, since the compiled clang fails to 
build a simple C program. The specific issue appears to be at the lines:

ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

My system settings are as follows:

MacBook Pro (Retina, Mid 2012)
macOS Sierra Version 10.12.2 Beta (16C48b)
Xcode Version 8.1 (8B62)
    |clang/clang++: Apple LLVM version 8.0.0 (clang-800.0.42.1)

  
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
  -isysroot
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
  -Wl,-search_paths_first -Wl,-headerpad_max_install_names
  CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o -o cmTC_b980a && :

  ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

That error sounds like the build is trying to use an old linker that does not 
understand the format of the current SDK's files.

Xcode 8.1 (8B62) should be fine. If the problem is an old linker then it is 
most likely coming from some other install of Xcode on your machine.

What is the output of `xcode-select -p` and `xcodebuild -version`? If those are 
pointing at some other install of Xcode then you can use `xcode-select -s` to 
tell the command-line tools which copy of Xcode to use.

You can also re-run the failing clang command by hand and add -### to its 
arguments. clang will then print the full path to the linker it is running.


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

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

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

[Frederick Kellison-Linn via swift-dev]

which ld gives the same /opt/local version

My path is

/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/Users/freddy/anaconda3/bin:/opt/local/bin:/opt/local/sbin:/Users/freddy/.rvm/gems/ruby-2.1.1/bin:/Users/freddy/.rvm/gems/ruby-2.1.1@global/bin:/Users/freddy/.rvm/rubies/ruby-2.1.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/usr/local/MacGPG2/bin:/Library/TeX/texbin:/Users/freddy/.rvm/bin

Freddy

> On Dec 8, 2016, at 5:31 PM, William Dillon  wrote:
> 
> What if you try:
> 
> which ld
> 
> And, what’s your PATH?
> 
> On December 8, 2016 at 2:19:20 PM, Frederick Kellison-Linn (fred...@me.com 
> ) wrote:
> 
>> Yeah that seems wrong to me as well. Do you know how I can change the linker 
>> that clang invokes?
>> 
>> Freddy
>> 
>>> On Dec 8, 2016, at 5:16 PM, William Dillon >> > wrote:
>>> 
>>> The Apple folks might know better and correct me, but I’m pretty certain 
>>> you don’t want to be using any toolchains in /opt/local.  It all needs to 
>>> be from the Xcode.app.
>>> 
>>> - Will
>>> 
>>> On December 8, 2016 at 2:14:42 PM, Frederick Kellison-Linn via swift-dev 
>>> (swift-dev@swift.org ) wrote:
>>> 
 The output of those commands follows:
 
 $ xcode-select -p
 /Applications/Xcode.app/Contents/Developer
 
 $ xcodebuild -version
 Xcode 8.1
 Build version 8B62
 
 Both look fine to me.
 
 It appears that clang is invoking /opt/local/bin/ld, and running 
 /opt/local/bin/ld -v gives:
 
 @(#)PROGRAM:ld  PROJECT:ld64-264.3.102
 configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m 
 armv7k arm64 (tvOS)
 LTO support using: LLVM version 3.8.1
 
 What is wrong with the config here?
 
 Freddy
  
> On Dec 8, 2016, at 4:28 PM, William Dillon  > wrote:
> 
> I think Greg is right.  I’ve seen this before, and the way I fixed it was 
> by fixing the Xcode configuration, specifically relating to the 
> command-line tools.
> 
> - Will
> 
> On December 8, 2016 at 1:24:59 PM, Greg Parker via swift-dev 
> (swift-dev@swift.org ) wrote:
> 
>> 
>>> On Dec 8, 2016, at 7:28 AM, Frederick Kellison-Linn via swift-dev 
>>> > wrote:
>>> 
>>> Hello,
>>> 
>>> I have been attempting to build Swift, but have been running into 
>>> issues near the end of the build. Specifically, CMake fails on the step 
>>> [2112/2254] Performing configure step for 'compiler-rt’, since the 
>>> compiled clang fails to build a simple C program. The specific issue 
>>> appears to be at the lines:
>>> 
>>> ld: unexpected token: !tapi-tbd-v2 file
>>>   
>>> '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
>>>   for architecture x86_64
>>> 
>>> My system settings are as follows:
>>> 
>>> MacBook Pro (Retina, Mid 2012)
>>> macOS Sierra Version 10.12.2 Beta (16C48b)
>>> Xcode Version 8.1 (8B62)
>>> |clang/clang++: Apple LLVM version 8.0.0 (clang-800.0.42.1)
>>> 
>>>   
>>> /Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
>>>   -isysroot
>>>   
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>>>   -Wl,-search_paths_first -Wl,-headerpad_max_install_names
>>>   CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o -o cmTC_b980a && :
>>> 
>>>   ld: unexpected token: !tapi-tbd-v2 file
>>>   
>>> '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
>>>   for architecture x86_64
>> 
>> 
>> That error sounds like the build is trying to use an old linker that 
>> does not understand the format of the current SDK's files.
>> 
>> Xcode 8.1 (8B62) should be fine. If the problem is an old linker then it 
>> is most likely coming from some other install of Xcode on your machine.
>> 
>> What is the output of `xcode-select -p` and `xcodebuild -version`? If 
>> those are pointing at some other install of Xcode then you can use 
>> `xcode-select -s` to tell the command-line tools which copy of Xcode to 
>> use.
>> 
>> You can also re-run the failing clang command by hand and add -### to 
>> its arguments. clang will then print the full path to the linker it is 
>> running.
>> 
>> 
>> -- 
>> Greg Parker gpar...@apple.com  Runtime 
>> 

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

[William Dillon via swift-dev]

What if you try:

which ld

And, what’s your PATH?

On December 8, 2016 at 2:19:20 PM, Frederick Kellison-Linn (fred...@me.com) 
wrote:

Yeah that seems wrong to me as well. Do you know how I can change the linker 
that clang invokes?

Freddy

On Dec 8, 2016, at 5:16 PM, William Dillon  wrote:

The Apple folks might know better and correct me, but I’m pretty certain you 
don’t want to be using any toolchains in /opt/local.  It all needs to be from 
the Xcode.app.

- Will

On December 8, 2016 at 2:14:42 PM, Frederick Kellison-Linn via swift-dev 
(swift-dev@swift.org) wrote:

The output of those commands follows:

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcodebuild -version
Xcode 8.1
Build version 8B62

Both look fine to me.

It appears that clang is invoking /opt/local/bin/ld, and running 
/opt/local/bin/ld -v gives:

@(#)PROGRAM:ld  PROJECT:ld64-264.3.102
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m 
armv7k arm64 (tvOS)
LTO support using: LLVM version 3.8.1

What is wrong with the config here?

Freddy
 
On Dec 8, 2016, at 4:28 PM, William Dillon  wrote:

I think Greg is right.  I’ve seen this before, and the way I fixed it was by 
fixing the Xcode configuration, specifically relating to the command-line tools.

- Will

On December 8, 2016 at 1:24:59 PM, Greg Parker via swift-dev 
(swift-dev@swift.org) wrote:


On Dec 8, 2016, at 7:28 AM, Frederick Kellison-Linn via swift-dev 
 wrote:

Hello,

I have been attempting to build Swift, but have been running into issues near 
the end of the build. Specifically, CMake fails on the step [2112/2254] 
Performing configure step for 'compiler-rt’, since the compiled clang fails to 
build a simple C program. The specific issue appears to be at the lines:

ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

My system settings are as follows:

MacBook Pro (Retina, Mid 2012)
macOS Sierra Version 10.12.2 Beta (16C48b)
Xcode Version 8.1 (8B62)
    |clang/clang++: Apple LLVM version 8.0.0 (clang-800.0.42.1)

  
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
  -isysroot
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
  -Wl,-search_paths_first -Wl,-headerpad_max_install_names
  CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o -o cmTC_b980a && :

  ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

That error sounds like the build is trying to use an old linker that does not 
understand the format of the current SDK's files.

Xcode 8.1 (8B62) should be fine. If the problem is an old linker then it is 
most likely coming from some other install of Xcode on your machine.

What is the output of `xcode-select -p` and `xcodebuild -version`? If those are 
pointing at some other install of Xcode then you can use `xcode-select -s` to 
tell the command-line tools which copy of Xcode to use.

You can also re-run the failing clang command by hand and add -### to its 
arguments. clang will then print the full path to the linker it is running.


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

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

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

[Frederick Kellison-Linn via swift-dev]

Yeah that seems wrong to me as well. Do you know how I can change the linker 
that clang invokes?

Freddy

> On Dec 8, 2016, at 5:16 PM, William Dillon  wrote:
> 
> The Apple folks might know better and correct me, but I’m pretty certain you 
> don’t want to be using any toolchains in /opt/local.  It all needs to be from 
> the Xcode.app.
> 
> - Will
> 
> On December 8, 2016 at 2:14:42 PM, Frederick Kellison-Linn via swift-dev 
> (swift-dev@swift.org ) wrote:
> 
>> The output of those commands follows:
>> 
>> $ xcode-select -p
>> /Applications/Xcode.app/Contents/Developer
>> 
>> $ xcodebuild -version
>> Xcode 8.1
>> Build version 8B62
>> 
>> Both look fine to me.
>> 
>> It appears that clang is invoking /opt/local/bin/ld, and running 
>> /opt/local/bin/ld -v gives:
>> 
>> @(#)PROGRAM:ld  PROJECT:ld64-264.3.102
>> configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m 
>> armv7k arm64 (tvOS)
>> LTO support using: LLVM version 3.8.1
>> 
>> What is wrong with the config here?
>> 
>> Freddy
>>  
>>> On Dec 8, 2016, at 4:28 PM, William Dillon >> > wrote:
>>> 
>>> I think Greg is right.  I’ve seen this before, and the way I fixed it was 
>>> by fixing the Xcode configuration, specifically relating to the 
>>> command-line tools.
>>> 
>>> - Will
>>> 
>>> On December 8, 2016 at 1:24:59 PM, Greg Parker via swift-dev 
>>> (swift-dev@swift.org ) wrote:
>>> 
 
> On Dec 8, 2016, at 7:28 AM, Frederick Kellison-Linn via swift-dev 
> > wrote:
> 
> Hello,
> 
> I have been attempting to build Swift, but have been running into issues 
> near the end of the build. Specifically, CMake fails on the step 
> [2112/2254] Performing configure step for 'compiler-rt’, since the 
> compiled clang fails to build a simple C program. The specific issue 
> appears to be at the lines:
> 
> ld: unexpected token: !tapi-tbd-v2 file
>   
> '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
>   for architecture x86_64
> 
> My system settings are as follows:
> 
> MacBook Pro (Retina, Mid 2012)
> macOS Sierra Version 10.12.2 Beta (16C48b)
> Xcode Version 8.1 (8B62)
> |clang/clang++: Apple LLVM version 8.0.0 (clang-800.0.42.1)
> 
>   
> /Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
>   -isysroot
>   
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>   -Wl,-search_paths_first -Wl,-headerpad_max_install_names
>   CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o -o cmTC_b980a && :
> 
>   ld: unexpected token: !tapi-tbd-v2 file
>   
> '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
>   for architecture x86_64
 
 
 That error sounds like the build is trying to use an old linker that does 
 not understand the format of the current SDK's files.
 
 Xcode 8.1 (8B62) should be fine. If the problem is an old linker then it 
 is most likely coming from some other install of Xcode on your machine.
 
 What is the output of `xcode-select -p` and `xcodebuild -version`? If 
 those are pointing at some other install of Xcode then you can use 
 `xcode-select -s` to tell the command-line tools which copy of Xcode to 
 use.
 
 You can also re-run the failing clang command by hand and add -### to its 
 arguments. clang will then print the full path to the linker it is running.
 
 
 -- 
 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 
>> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

[William Dillon via swift-dev]

The Apple folks might know better and correct me, but I’m pretty certain you 
don’t want to be using any toolchains in /opt/local.  It all needs to be from 
the Xcode.app.

- Will

On December 8, 2016 at 2:14:42 PM, Frederick Kellison-Linn via swift-dev 
(swift-dev@swift.org) wrote:

The output of those commands follows:

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcodebuild -version
Xcode 8.1
Build version 8B62

Both look fine to me.

It appears that clang is invoking /opt/local/bin/ld, and running 
/opt/local/bin/ld -v gives:

@(#)PROGRAM:ld  PROJECT:ld64-264.3.102
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m 
armv7k arm64 (tvOS)
LTO support using: LLVM version 3.8.1

What is wrong with the config here?

Freddy
 
On Dec 8, 2016, at 4:28 PM, William Dillon  wrote:

I think Greg is right.  I’ve seen this before, and the way I fixed it was by 
fixing the Xcode configuration, specifically relating to the command-line tools.

- Will

On December 8, 2016 at 1:24:59 PM, Greg Parker via swift-dev 
(swift-dev@swift.org) wrote:


On Dec 8, 2016, at 7:28 AM, Frederick Kellison-Linn via swift-dev 
 wrote:

Hello,

I have been attempting to build Swift, but have been running into issues near 
the end of the build. Specifically, CMake fails on the step [2112/2254] 
Performing configure step for 'compiler-rt’, since the compiled clang fails to 
build a simple C program. The specific issue appears to be at the lines:

ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

My system settings are as follows:

MacBook Pro (Retina, Mid 2012)
macOS Sierra Version 10.12.2 Beta (16C48b)
Xcode Version 8.1 (8B62)
    |clang/clang++: Apple LLVM version 8.0.0 (clang-800.0.42.1)

  
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
  -isysroot
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
  -Wl,-search_paths_first -Wl,-headerpad_max_install_names
  CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o -o cmTC_b980a && :

  ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

That error sounds like the build is trying to use an old linker that does not 
understand the format of the current SDK's files.

Xcode 8.1 (8B62) should be fine. If the problem is an old linker then it is 
most likely coming from some other install of Xcode on your machine.

What is the output of `xcode-select -p` and `xcodebuild -version`? If those are 
pointing at some other install of Xcode then you can use `xcode-select -s` to 
tell the command-line tools which copy of Xcode to use.

You can also re-run the failing clang command by hand and add -### to its 
arguments. clang will then print the full path to the linker it is running.


-- 
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
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[John McCall via swift-dev]

> On Dec 8, 2016, at 1:53 PM, Andrew Trick  wrote:
>> On Dec 7, 2016, at 11:25 PM, John McCall via swift-dev > > wrote:
>> 
>>> 
>>> On Dec 7, 2016, at 2:13 PM, Michael Gottesman via swift-dev 
>>> > wrote:
>>> 
>>> This is a proposal for a new SIL Ownership Model and verifier. An online 
>>> HTML version of the document is available here:
>>> 
>>> https://gottesmm.github.io/proposals/sil-ownership-model.html 
>>> 
>>> 
>>> and inline below.
>>> 
>>> Michael
>>> 
>>> 
>>> 
>>> # Summary
>>> 
>>> This document defines a SIL ownership model and a compile time static 
>>> verifier
>>> for the model. This will allow for static compile time verification that a 
>>> SIL
>>> program satisfies all ownership model constraints.
>>> 
>>> The proposed SIL ownership model embeds ownership into SIL's SSA def-use
>>> edges. This is accomplished by:
>>> 
>>> 1. Formalizing into SIL API's the distinction in between defs
>>>(e.g. `SILInstruction` and `SILArgument`) and the values produced by defs
>>>(e.g. `SILValue`). This is needed to model values as having ownership and
>>>defs as not having ownership. The main implication here is that the two 
>>> can
>>>no longer be implicitly convertible and the API must enforce this.
> 
> This proposal is simultaneously proposing some specific API details
> while avoiding both the motivation behind it and the eventual features
> that it will support.
> 
> I think the ValueBase/Def renaming is a little
> misunderstanding. "ValueDef" in the proposal was a placeholder (not a
> perfect name) for some perceived need to have a common
> SILArgument/SILInstruction base class. That's probably not necessary
> in which case there's nothing to disagree about.
> 
> John's counter proposal solves that problem by repurposing ValueBase
> to serve as a base class for value definitions (and then goes into
> some detail on implementing multi-result instructions).
> 
>> We currently have two kinds of def: instructions and arguments.  Arguments
>> always define a single value, and I don't see anything in your proposal that
>> changes that.  And the idea that an instruction produces exactly one value is
>> already problematic, because many don't produce a meaningful value at all.
>> All that changes in your proposal is that certain instructions need to be 
>> able
>> to produce multiple values.
> 
> That’s an obvious way of looking at it. I personally am most
> interested in putting an end to the chronic problem of conflating
> instructions and values which literally makes it impossible to have a
> sane discussion about ownership. I insisted that SILInstruction not
> derive from ValueBase, which probably led to the proposed
> renaming. This probably comes across as confusing because the proposal
> is deliberately side-stepping the issue of multi-result instructions.
> 
> What I really want to see at the proposal level is agreement on core concepts:
> - A value has a type, ownership, one def, and 0..n uses
> - Ownership rules are guaranteed simply by evaluating those 0..n uses.
> - A value’s def/use is the point at which it is produced/consumed.
> - Use/def points are demarcated by instructions or block boundaries
> - An instruction produces values via results or consumes them via operands.
> 
> There shouldn't be any debate about these concepts, so why is there so
> much confusion? I think caused by some bad choices in the SIL
> interface, particularly as SILInstruction : ValueBase.
> 
> So we should define a SIL interface that reflects those core
> concepts. We should be able to reimplement multi-result instructions
> without affecting those interfaces and without rewritting SIL passes.

I agree.  I don't think this requires deep changes to how SIL nodes are 
typically
worked with.  As long as single-result instructions can be transparently used as
values, so that e.g. the result of SILBuilder::CreateBitCast can be used as a
SILValue, the number of changes required should be quite modest.

Things like SILCloner will of course need some minor updates to handle the
fact that a single instruction can have multiple uses, but that should be 
straightforward
to do on top of the existing Value->Value mapping.

John.

> 
> -Andy
> 
>> 
>> Moreover, the word "def" clearly suggests that it refers to the definition 
>> of a
>> value that can be used, and that's how the term is employed basically 
>> everywhere.
>> 
>> So allow me to suggest that a much clearer way of saying what you're trying 
>> to
>> say is that we need to distinguish between defs and instructions.  An 
>> instruction
>> may have an arbitrary number of defs, possibly zero, and each def is a value
>> that can be used.  (But the number of defs per instruction is known 
>> statically
>> for most instructions, which is something we can use to make 

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

[Andrew Trick via swift-dev]

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

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

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

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

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

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

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

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

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

-Andy

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

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

[William Dillon via swift-dev]

I think Greg is right.  I’ve seen this before, and the way I fixed it was by 
fixing the Xcode configuration, specifically relating to the command-line tools.

- Will

On December 8, 2016 at 1:24:59 PM, Greg Parker via swift-dev 
(swift-dev@swift.org) wrote:


On Dec 8, 2016, at 7:28 AM, Frederick Kellison-Linn via swift-dev 
 wrote:

Hello,

I have been attempting to build Swift, but have been running into issues near 
the end of the build. Specifically, CMake fails on the step [2112/2254] 
Performing configure step for 'compiler-rt’, since the compiled clang fails to 
build a simple C program. The specific issue appears to be at the lines:

ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

My system settings are as follows:

MacBook Pro (Retina, Mid 2012)
macOS Sierra Version 10.12.2 Beta (16C48b)
Xcode Version 8.1 (8B62)
    |clang/clang++: Apple LLVM version 8.0.0 (clang-800.0.42.1)

  
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
  -isysroot
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
  -Wl,-search_paths_first -Wl,-headerpad_max_install_names
  CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o -o cmTC_b980a && :

  ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

That error sounds like the build is trying to use an old linker that does not 
understand the format of the current SDK's files.

Xcode 8.1 (8B62) should be fine. If the problem is an old linker then it is 
most likely coming from some other install of Xcode on your machine.

What is the output of `xcode-select -p` and `xcodebuild -version`? If those are 
pointing at some other install of Xcode then you can use `xcode-select -s` to 
tell the command-line tools which copy of Xcode to use.

You can also re-run the failing clang command by hand and add -### to its 
arguments. clang will then print the full path to the linker it is running.


-- 
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] proposed change for master-next merges

[Michael Gottesman via swift-dev]

> On Dec 8, 2016, at 7:43 AM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> Having been involved in the update process for the next branches, I'm really 
> excited to see this type of change.
> 
> I think that the "simple" approach is both better to work and collaborate in 
> as well as closer to the llvm development model which makes it easier to 
> cross pollinate.
> 
> The one thing that I think could be more strongly called out is that normal 
> PR CI shouldn't be gated on master next passing.
> 
> Beyond that, I think that this proposal should ease collaboration and 
> maintenance pains in the current process.

I agree with everything said here. The collaboration issue is the high order 
bit that needs to be fixed. Any other issues that come up can be fixed 
incrementally if necessary based on experience (for instance using the "back 
up" alternative). This is even more true since it is clear that that 
infrastructure would take time to develop and an incremental solution now that 
improves the collaboration will not make it more difficult to develop such a 
solution.

My only strong feeling here is that I think we need documentation of this 
process in ./docs in addition to this proposal.

Michael

> 
> On Wed, Dec 7, 2016 at 7:30 PM Bob Wilson via swift-dev  > wrote:
> I would like to make a change in the way we handle the master-next branch.
> 
> Summary: I’d like to switch to a model where we continuously test against the 
> latest upstream LLVM changes. The goal is to simplify the process and make it 
> easier to collaborate on maintaining master-next.
> 
> Background: We develop Swift against “stable” branches of LLVM (which I am 
> using here to refer to the llvm, clang, and compiler-rt repositories) that 
> are typically rebranched from trunk once for each release, with other commits 
> individually cherry-picked for specific bug fixes and other changes. This 
> insulates Swift development from the churn of changes in LLVM. At the same 
> time, we maintain the “master-next” branches of Swift repos to keep up to 
> date with trunk LLVM. For Swift, our “trunk” comes from the 
> “upstream-with-swift” branches in our GitHub LLVM repos. We have existing 
> automation to continuously merge changes from llvm.org  
> into those upstream-with-swift branches.
> 
> We currently use a manual process to update master-next. Someone on the Swift 
> team is designated as the "merge czar" and is responsible for this. This 
> merge typically happens once every few weeks. Michael Gottesman developed 
> some internal tools to help automate the process, but someone still needs to 
> drive those tools manually. The process involves merging “master” to 
> “master-next” for all the Swift repos and updating the “stable-next” branches 
> of the GitHub LLVM repos for Swift. The “stable-next” branches are basically 
> snapshots of the LLVM upstream-with-swift branches at the point where 
> master-next was most recently merged.
> 
> Swift CI includes a set of Jenkins bots to test master-next building with the 
> stable-next branches of LLVM (https://ci.swift.org/view/swift-master-next 
> ). The merge czar can use these 
> bots to confirm that everything is working after a merge.
> 
> Reasons to change: The current process has the advantage that the merge czar 
> can choose when to do a merge and can schedule that around other work, but it 
> has some significant problems.
> 
> - It is difficult for multiple people to collaborate on updating master-next. 
> The changes involved are often rev-locked between Swift and the LLVM repos, 
> so there is no good way for someone to fix a problem without doing the whole 
> merge process.
> 
> - The current system is hard to understand. I’ve been serving as the merge 
> czar for the last few months, and it took me a while to figure out how to do 
> it well.
> 
> - It requires extra “stable-next” branches in our GitHub LLVM repos, further 
> adding to the complexity.
> 
> - The tools we have to help automate the process are currently internal to 
> Apple and require ongoing maintenance. They could be cleaned up to release 
> publicly but that would take more work.
> 
> Proposal: We already have Jenkins bots testing master-next. I would like to 
> add a job to continuously merge master to master-next and change the existing 
> bots to build against the “upstream-with-swift” branches in our GitHub LLVM 
> repos. The bots would then detect any new problems soon after they are 
> introduced. Anyone could fix those problems, whether they are merge 
> conflicts, build failures, or test issues. A partial fix could be applied 
> directly without needing to resolve all of the outstanding issues.
> 
> This would avoid the need for our current internal merging tools. We already 
> have automatic merging bots, so adding another one would not be difficult.
> 

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #36

[Alex L via swift-dev]

This looks like the incremental build issue that we saw 2-3 weeks ago
(rdar://29201272), clang's libSema wasn't fully re-compiled:

[20/64] Building DiagnosticSemaKinds.inc...
...
[23/64] Updating DiagnosticSemaKinds.inc...
...
[35/50] Building CXX object
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaCXXScopeSpec.cpp.o
...
[39/50] Building CXX object
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaType.cpp.o
[40/50] Building CXX object
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaDecl.cpp.o
[41/50] Linking CXX static library lib/libclangSema.a


On 8 December 2016 at 16:39,  wrote:

> [FAILURE] oss-lldb-swift-3.1-incremental-osx [#36]
> Build URL: https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/36/
> Project: oss-lldb-swift-3.1-incremental-osx
> Date of build: Thu, 08 Dec 2016 07:43:12 -0800
> Build duration: 56 min Identified problems:
>
>- Assertion failure: This build failed because of an assertion
>failure. Below is a list of all errors in the build log:
>   - Indication 1
>   
> 
>- Compile Error: This build failed because of a compile error. Below
>is a list of all errors in the build log:
>   - Indication 1
>   
> 
>- Regression test failed: This build failed because a regression test
>in the test suite FAILed. Below is a list of all errors:
>   - Indication 1
>   
> 
>
>
> Changes
>
>- Commit *415306523048561c4211a5eab6ed8085ad9328e2* by *arphaman:*
>
>[ObjC++] Don't enter a C++ declarator scope when the current context is
>- *edit*: lib/Parse/ParseDecl.cpp
>   - *edit*: lib/Sema/SemaCXXScopeSpec.cpp
>   - *edit*: test/SemaObjCXX/crash.mm
>
>- Commit *80e3c5ba312cafdcd6a1b5db522eef60a2b8999a* by *arphaman:*
>
>Implement the -Wstrict-prototypes warning
>- *add*: test/Sema/warn-strict-prototypes.c
>   - *edit*: lib/Sema/SemaDecl.cpp
>   - *edit*: include/clang/Basic/DiagnosticSemaKinds.td
>   - *add*: test/Sema/warn-strict-prototypes.m
>   - *edit*: lib/Sema/SemaType.cpp
>
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] Build failing on CMakeTestCCompiler.cmake

[Frederick Kellison-Linn via swift-dev]

Hello,

I have been attempting to build Swift, but have been running into issues near 
the end of the build. Specifically, CMake fails on the step [2112/2254] 
Performing configure step for 'compiler-rt’, since the compiled clang fails to 
build a simple C program. The specific issue appears to be at the lines:

ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

My system settings are as follows:

MacBook Pro (Retina, Mid 2012)
macOS Sierra Version 10.12.2 Beta (16C48b)
Xcode Version 8.1 (8B62)
|clang/clang++: Apple LLVM version 8.0.0 (clang-800.0.42.1)

The full text of the failure is below. Any help figuring out how to solve this 
issue would be greatly appreciated.

[2112/2254] Performing configure step for 'compiler-rt'
-- The C compiler identification is Clang 4.0.0
-- The CXX compiler identification is Clang 4.0.0
-- The ASM compiler identification is Clang
-- Found assembler: 
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
-- Check for working C compiler: 
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
-- Check for working C compiler: 
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
 -- broken
CMake Error at 
/Applications/CMake.app/Contents/share/cmake-3.7/Modules/CMakeTestCCompiler.cmake:51
 (message):
  The C compiler
  
"/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang"
  is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: 
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/tools/clang/runtime/compiler-rt-bins/CMakeFiles/CMakeTmp

  

  Run Build Command:"/opt/local/bin/ninja" "cmTC_b980a"

  [1/2] Building C object CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o

  [2/2] Linking C executable cmTC_b980a

  FAILED: cmTC_b980a

  : &&
  
/Users/freddy/Development/swift/swift-source/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./bin/clang
  -isysroot
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
  -Wl,-search_paths_first -Wl,-headerpad_max_install_names
  CMakeFiles/cmTC_b980a.dir/testCCompiler.c.o -o cmTC_b980a && :

  ld: unexpected token: !tapi-tbd-v2 file
  
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libSystem.tbd'
  for architecture x86_64

  clang-4.0: error: linker command failed with exit code 1 (use -v to see
  invocation)

  ninja: build stopped: subcommand failed.

  

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:12 (project)

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