I would like to see if the community is interested in the ability for Swift
libraries (when built with Swift Package Manager) to be aware of the
current tagged version number applied on that library during compilation.
This could be useful for when the executable is run, we can know the
version of that library dependency so that we can dump that information out
to our logs. Perhaps some macro like #file or #line, but something like
#version.
···
From: swift-dev-request@swift.org
To: swift-dev@swift.org
Date: 04/18/2016 11:57 AM
Subject: swift-dev Digest, Vol 5, Issue 18
Sent by: swift-dev-bounces@swift.org
Send swift-dev mailing list submissions to
swift-dev@swift.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.swift.org/mailman/listinfo/swift-dev
or, via email, send a message with subject or body 'help' to
swift-dev-request@swift.org
You can reach the person managing the list at
swift-dev-owner@swift.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of swift-dev digest..."
Today's Topics:
1. Re: [SR-710][RFC] Automatically detecting XCTest test methods
on Linux: Reflection? SourceKit? (Brian Gesiak)
2. Re: R_ARM_GOT_PREL error when building Swift on Pi from
source (Timothy Wood)
3. Re: R_ARM_GOT_PREL error when building Swift on Pi from
source (Joe Bell)
4. Re: R_ARM_GOT_PREL error when building Swift on Pi from
source (Timothy Wood)
5. Random failure when building Swift on Pi (Timothy Wood)
6. Re: [SR-710][RFC] Automatically detecting XCTest test methods
on Linux: Reflection? SourceKit? (Drew Crawford)
7. Re: R_ARM_GOT_PREL error when building Swift on Pi from
source (Timothy Wood)
8. SIMD in open source Swift? (Geordie Jay)
9. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
Ubuntu 15.10 (master) #4254 (Sean Callanan)
10. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
Ubuntu 15.10 (master) #4254 (Sean Callanan)
11. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
OS X (master) #3432 (Sean Callanan)
----------------------------------------------------------------------
Message: 1
Date: Sun, 17 Apr 2016 14:36:08 -0400
From: Brian Gesiak <modocache@gmail.com>
To: Daniel Dunbar <daniel_dunbar@apple.com>
Cc: swift-dev <swift-dev@swift.org>
Subject: Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest
test methods on Linux: Reflection? SourceKit?
Message-ID:
<CAN7MxmX3aeuCK3TQepC5cwJ+hzVK8v1FXQQwiqEt5c0tqF7t
+A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
In case anyone interested missed it, John Holdsworth mentions another
approach in a comment on Issues · apple/swift-issues · GitHub using
runtime metadata to find a list of tests. The linked project contains an
example. It:
1. Specifies a test method regex:
2. In Swift, the project exposes metadata information for Swift objects:
3. Uses an UnsafeMutablePointer<ClassMetadataSwift> to get a reference to
the methods defined on an instance:
I assume this approach won't be acceptable to some because it relies on
private information about Swift objects, but I don't know for sure. Please
chime in if this approach seems reasonable to you!
Based on the assumption that we can't use metadata, however, I'm going to
try to begin working on approaches #2 or #3, which I mentioned in my
original email. I think the preliminary work is the same (like
moving SourceKit::FuncDeclEntityInfo.IsTestCandidate to libIDE), so I'll
hold off on making a hard decision between #2 and #3 until necessary.
- Brian Gesiak
On Mon, Apr 4, 2016 at 12:23 AM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
> On Apr 3, 2016, at 3:36 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
>
> On Sun, Apr 3, 2016 at 2:11 PM, Brian Gesiak <modocache@gmail.com> > wrote:
>> I think #2 is the best option. It’s less work than both #1 and #3. I
believe
>> logic like IsTestCandidate belongs in libIDE anyway—SourceKit should
stick
>> to XPC and asynchronous communication with libIDE.
>
> I like #3 better (an option to swiftc), because that would decouple
> the test discovery tool from the Swift compiler. That would allow you
> to use the discovery tool with different compilers. And, because we
> would avoid statically linking libIDE, it would mean one less copy of
> LLVM, Clang and Swift in the toolchain.Ultimately my opinion is that it is likely that the package manager will
want an API interface to Swift in any case. I personally would rather we
simply plan on that.I also would like to avoid duplicating anything in the toolchain, but
think that should be done by moving the driver to sitting on top of a
shared library.>> Not being an expert in many of these components, I have several
questions:
>>
>> I’m assuming the reflection API to return a list of instance methods
on
a
>> XCTestCase subclass is not ready yet, and won’t be for some time. Is
this
>> accurate?
>
> I think so.
>
>> I’m assuming that SourceKit is intended to be an asynchronous wrapper
over
>> libIDE, and that logic like IsTestCandidate should be moved to libIDE.
Is
>> this accurate?
>
> SourceKit has a lot of functionality of its own, but moving this
> particular piece of logic to libIDE sounds reasonable.
>
>> I’m assuming that SourceKit is coupled with XPC, and that it would be
more
>> work to port it to Linux than it would be to move its logic to libIDE.
Is
>> this accurate?
>
> It is not tightly coupled with XPC, there is a portability layer that
> you could implement for Linux. You would need to decide on an IPC
> mechanism and serialization format though.For our purposes, I don't think we need IPC. I think a direct (C) library
interface would be fine. Clients can implement the IPC/XPC if they need
it.
>> If you have thoughts/feedback, please reply to this email or comment
on
>> SR-710. Your input would be greatly appreciated!!
>
> I'm wondering how feasible is it to change the XCTest API to
> accommodate better the Swift language that we have, rather than trying
> to add custom tooling to make the existing API work. Adding magic
> tooling that adds behavior not present in the language seems unnatural
> to me.I agree with you that it is unnatural, but I think this ship has sailed
for XCTest, we have a need to support the existing API in a cross
platform
manner.
My personal preference is that eventually we would build features like
this on top of general support for attributes (a la Java/Python/C#).> Compare with StdlibUnittest -- by using an API to build tests we get
> the following advantages:
>
> - We completely avoid having the issue of test discovery, executing
> the code discovers the tests. No reflection needed!While I think StdlibUnittest is neat, I also believe that there are very
good reasons for supporting test discovery in a test suite. I have used
these features in other suites to great avail to create (bidirectional,
sometimes) lit bridge adaptors between various test frameworks (Python
unittest, googletest, XCTest).In an IDE context, it is also very useful to be able to perform test
discovery independent of test execution.As one other example, I've used lit with suites with hundreds of
thousands
of tests... it would be unfortunate to have to dynamically discover all
of
those tests when the user is just trying to run a single one.
> - We can add attributes to tests (for example, skip, xfail). In the
> current XCTest API this would require adding some kind of user-defined
> attributes, which is another language which is a long way from being
> designed and implemented.This isn't necessarily the case, XCTest could in theory provide explicit
APIs to do these things as part of test execution. I agree attributes are
a
better fit in the current model.
> - We can define data-parameterized tests.
> - Tests can be dynamically synthesized by control flow. In the
> current XCTest API, dynamically generating tests would mean
> dynamically generating methods, which is even more far off than
> read-only method reflection.FWIW, XCTest has some support for doing these kinds of things, they just
don't take the form of the pattern-matched methods.- Daniel
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/1346eb08/attachment-0001.html
------------------------------
Message: 2
Date: Sun, 17 Apr 2016 13:46:33 -0700
From: Timothy Wood <tjw@omnigroup.com>
To: William Dillon <william@housedillon.com>
Cc: Kenny Leung via swift-dev <swift-dev@swift.org>
Subject: Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on
Pi from source
Message-ID: <29ABC0C6-92D9-4A67-ABD0-4CDDE2F5C45E@omnigroup.com>
Content-Type: text/plain; charset="utf-8"
On Apr 16, 2016, at 2:23 PM, William Dillon <william@housedillon.com> wrote:
What LLVM are you using?
You have to use the one from my github (and the arm branch) or it won't
work:
https://github.com/hpux735/swift-llvm/tree/arm>
I haven't had time to upstream the changes to LLVM.
- Will
Ah, thanks! I was using <
GitHub - apple/swift-llvm at swift-2.2-branch <
https://github.com/apple/swift-llvm/tree/swift-2.2-branch>>, but will give
your fork a try!
-tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/5349c220/attachment-0001.html
------------------------------
Message: 3
Date: Sun, 17 Apr 2016 15:52:20 -0500
From: Joe Bell <joe@iachieved.it>
To: Timothy Wood <tjw@omnigroup.com>
Cc: Kenny Leung via swift-dev <swift-dev@swift.org>
Subject: Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on
Pi from source
Message-ID: <5D20A476-5349-426C-B884-49E202631D80@iachieved.it>
Content-Type: text/plain; charset="utf-8"
I'll join in Tim and try compiling again on the BeagleX15, it failed the
other day but I forgot about using Wills LLVM
Joe
On Apr 17, 2016, at 3:46 PM, Timothy Wood via swift-dev <swift-dev@swift.org> wrote:
On Apr 16, 2016, at 2:23 PM, William Dillon <william@housedillon.com> wrote:
What LLVM are you using?
You have to use the one from my github (and the arm branch) or it won't
work:
https://github.com/hpux735/swift-llvm/tree/arm
I haven't had time to upstream the changes to LLVM.
- Will
Ah, thanks! I was using <
https://github.com/apple/swift-llvm/tree/swift-2.2-branch>, but will give
your fork a try!
-tim
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/ac2ace8e/attachment-0001.html
------------------------------
Message: 4
Date: Sun, 17 Apr 2016 13:55:31 -0700
From: Timothy Wood <tjw@omnigroup.com>
To: Joe Groff <jgroff@apple.com>
Cc: swift-dev@swift.org
Subject: Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on
Pi from source
Message-ID: <FFDED274-9542-4266-A319-DAD6B10184CC@omnigroup.com>
Content-Type: text/plain; charset=utf-8
On Apr 15, 2016, at 6:45 PM, Joe Groff <jgroff@apple.com> wrote:
What linker are you using? GNU ld 2.26 in particular changed the behavior
of protected visibility in a way that's incompatible with our usage, and we
haven't fully implemented a workaround. You might try using gold or an
older binutils, if that's what you're currently using.
I could have sworn I was using gold, but looking at my logs it was using
the standard linker. Perhaps I’m remembering an attempt from the Swift 3
sources… Anyway, my current attempts are using this invocation now (though
I’m getting other failures now):
utils/build-script -t -R -j 4 -- --use-gold-linker
Thanks!
-tim
------------------------------
Message: 5
Date: Sun, 17 Apr 2016 13:55:35 -0700
From: Timothy Wood <tjw@me.com>
To: swift-dev@swift.org
Subject: [swift-dev] Random failure when building Swift on Pi
Message-ID: <6904C5F0-0395-48B7-9092-8117D82342BE@me.com>
Content-Type: text/plain; charset="utf-8"
I’m encountering random build compile failures when building on Pi, using
clang-3.6 (as suggested in the various instructions to do so), and when
using <https://github.com/hpux735/swift-llvm/tree/arm>
One example looks like:
FAILED: /usr/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Ilib/Support -I/home/pi/Source/Swift/llvm/lib/Support -Iinclude
-I/home/pi/Source/Swift/llvm/include -fno-stack-protector -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -O3
-UNDEBUG -fno-exceptions -fno-rtti -MMD -MT
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o -MF
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o.d -o
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o
-c /home/pi/Source/Swift/llvm/lib/Support/YAMLTraits.cpp
Stack dump:
0. Program arguments: /usr/lib/llvm-3.6/bin/clang -cc1 -triple
armv6-unknown-linux-gnueabihf -emit-obj -disable-free
-disable-llvm-verifier -main-file-name YAMLTraits.cpp -mrelocation-model
pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu
arm1136jf-s -target-abi aapcs-linux -mfloat-abi hard -target-linker-version
2.25 -dwarf-column-info -ffunction-sections -fdata-sections
-coverage-file /home/pi/Source/Swift/build/Ninja-ReleaseAssert/llvm-linux-armv7/lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o
-resource-dir /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2 -dependency-file
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o.d -MT
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o -D GTEST_HAS_RTTI=0
-D _DEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS
-D __STDC_LIMIT_MACROS -U NDEBUG -I lib/Support
-I /home/pi/Source/Swift/llvm/lib/Support -I include
-I /home/pi/Source/Swift/llvm/include
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/arm-linux-gnueabihf/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/arm-linux-gnueabihf/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c
++/4.9/backward -internal-isystem /usr/local/include
-internal-isystem /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include
-internal-externc-isystem /usr/include/arm-linux-gnueabihf
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-O3 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -pedantic -std=c++11
-fdeprecated-macro
-fdebug-compilation-dir /home/pi/Source/Swift/build/Ninja-ReleaseAssert/llvm-linux-armv7
-ferror-limit 19 -fmessage-length 0 -fvisibility-inlines-hidden
-mstackrealign -fno-rtti -fno-signed-char -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops
-vectorize-slp -o lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o
-x c++ /home/pi/Source/Swift/llvm/lib/Support/YAMLTraits.cpp
1. /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c+
+/4.9/ext/type_traits.h:113:6: current parser token ';'
2. /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c+
+/4.9/ext/type_traits.h:37:1: parsing namespace '__gnu_cxx'
3. /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c+
+/4.9/ext/type_traits.h:106:5: parsing struct/union/class body
'__remove_unsigned'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
Debian clang version 3.6.2-3 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
Target: arm-unknown-linux-gnueabihf
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://bugs.debian.org/ and include the crash backtrace, preprocessed
source, and associated run script.
clang: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/YAMLTraits-d1f411.cpp
clang: note: diagnostic msg: /tmp/YAMLTraits-d1f411.sh
clang: note: diagnostic msg:
But, if I run the emitted script it works fine:
pushd /tmp
bash /tmp/YAMLTraits-d1f411.sh
Or, another example (where clang++ isn’t crashing):
FAILED: /usr/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Iutils/TableGen -I/home/pi/Source/Swift/llvm/utils/TableGen -Iinclude
-I/home/pi/Source/Swift/llvm/include -fno-stack-protector -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -O3
-UNDEBUG -fno-exceptions -fno-rtti -MMD -MT
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o -MF
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o.d -o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o
-c /home/pi/Source/Swift/llvm/utils/TableGen/CodeGenInstruction.cpp
Stack dump:
0. Program arguments: /usr/lib/llvm-3.6/bin/clang -cc1 -triple
armv6-unknown-linux-gnueabihf -emit-obj -disable-free
-disable-llvm-verifier -main-file-name CodeGenInstruction.cpp
-mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array
-target-cpu arm1136jf-s -target-abi aapcs-linux -mfloat-abi hard
-target-linker-version 2.25 -dwarf-column-info -ffunction-sections
-fdata-sections
-coverage-file /home/pi/Source/Swift/build/Ninja-ReleaseAssert/llvm-linux-armv7/utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o
-resource-dir /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2 -dependency-file
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o.d
-MT utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o
-D GTEST_HAS_RTTI=0 -D _DEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D
__STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -U NDEBUG -I utils/TableGen
-I /home/pi/Source/Swift/llvm/utils/TableGen -I include
-I /home/pi/Source/Swift/llvm/include
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/arm-linux-gnueabihf/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/arm-linux-gnueabihf/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c
++/4.9/backward -internal-isystem /usr/local/include
-internal-isystem /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include
-internal-externc-isystem /usr/include/arm-linux-gnueabihf
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-O3 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -pedantic -std=c++11
-fdeprecated-macro
-fdebug-compilation-dir /home/pi/Source/Swift/build/Ninja-ReleaseAssert/llvm-linux-armv7
-ferror-limit 19 -fmessage-length 0 -fvisibility-inlines-hidden
-mstackrealign -fno-rtti -fno-signed-char -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops
-vectorize-slp -o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o -x c
++ /home/pi/Source/Swift/llvm/utils/TableGen/CodeGenInstruction.cpp
1. /home/pi/Source/Swift/llvm/include/llvm/ADT/SmallVector.h:718:44:
current parser token ')'
2. /home/pi/Source/Swift/llvm/include/llvm/ADT/SmallVector.h:31:1: parsing
namespace 'llvm'
3. /home/pi/Source/Swift/llvm/include/llvm/ADT/SmallVector.h:700:56:
parsing function body 'swap'
4. /home/pi/Source/Swift/llvm/include/llvm/ADT/SmallVector.h:700:56: in
compound statement ('{}')
error: unable to rename temporary
'utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o-9c605f46'
to output file
'utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o':
'No such file or directory'
1 error generated.
Each time I invoke the build script I get a few files further:
utils/build-script -t -R -j 4 -- --use-gold-linker
In my previous attempts to build Swift on Pi, I’d not seen this, so I’m
confused why it’s started now. My only working theories so far are that
when I did an `apt-get update`/`apt-get upgrade` to check for a new Swift
build, I applied a whole bunch of other updates to the system or second,
maybe my microSD card is going bad =/
-tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/089ccc30/attachment-0001.html
------------------------------
Message: 6
Date: Sun, 17 Apr 2016 16:50:47 -0500
From: Drew Crawford <drew@sealedabstract.com>
To: Dmitri Gribenko <gribozavr@gmail.com>
Cc: swift-dev <swift-dev@swift.org>
Subject: Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest
test methods on Linux: Reflection? SourceKit?
Message-ID: <CD4EB0A4-4521-4E81-8FDC-5D3B27DD70BC@sealedabstract.com>
Content-Type: text/plain; charset="utf-8"
On Apr 3, 2016, at 10:05 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
Hmm... but then wouldn't that more tightly couple the test discovery
tool
and the Swift compiler? In an earlier email you said you "like #3 better
[...] because that would decouple the test discovery tool from the Swift
compiler." I think that part is confusing me.Sorry -- what I meant is that the compiler remains the point of truth
about the language and can find the tests. The tools that actually
generate glue code won't need to parse code, and would be decoupled
from the compiler.
I am internally shipping a test framework that discovers tests via an
out-of-tree parser. Teaching swiftc about XCTest syntax is not sufficient
to deprecate my parser, and therefore is not sufficient for the compiler to
be the source of truth for my tests.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/00b0efb5/attachment-0001.html
------------------------------
Message: 7
Date: Sun, 17 Apr 2016 23:33:08 -0700
From: Timothy Wood <tjw@me.com>
To: William Dillon <william@housedillon.com>, Kenny Leung via
swift-dev <swift-dev@swift.org>
Subject: Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on
Pi from source
Message-ID: <BB74C65D-3547-4FCB-A43D-F74E8B81CBA7@me.com>
Content-Type: text/plain; charset="utf-8"
On Apr 17, 2016, at 1:46 PM, Timothy Wood via swift-dev <swift-dev@swift.org> wrote:
On Apr 16, 2016, at 2:23 PM, William Dillon <william@housedillon.com < mailto:william@housedillon.com>> wrote:
What LLVM are you using?
You have to use the one from my github (and the arm branch) or it won't
work:
https://github.com/hpux735/swift-llvm/tree/arm>
I haven't had time to upstream the changes to LLVM.
- Will
Ah, thanks! I was using <
GitHub - apple/swift-llvm at swift-2.2-branch <
https://github.com/apple/swift-llvm/tree/swift-2.2-branch>>, but will give
your fork a try!
-tim
I reset my Pi 3 to a fresh install of Jessie (2016-03-18), did the
clang-3.6 install from <
http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/>
and tried building with the above mentioned branch of llvm. This fixed the
spurious build failures I was seeing, but I’m hitting a persistent build
failure now:
[939/1818] Building CXX object
tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o
FAILED: /usr/bin/clang++-3.6 -DCLANG_ENABLE_ARCMT
-DCLANG_ENABLE_OBJC_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/utils/TableGen
-I/home/pi/Source/Swift/llvm/tools/clang/utils/TableGen
-I/home/pi/Source/Swift/llvm/tools/clang/include -Itools/clang/include
-Iinclude -I/home/pi/Source/Swift/llvm/include -fno-stack-protector -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections
-fno-common -Woverloaded-virtual -Wno-nested-anon-types -O3 -UNDEBUG
-fno-exceptions -fno-rtti -MMD -MT
tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o
-MF
tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o.d
-o
tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o
-c /home/pi/Source/Swift/llvm/tools/clang/utils/TableGen/ClangAttrEmitter.cpp
/home/pi/Source/Swift/llvm/tools/clang/utils/TableGen/ClangAttrEmitter.cpp:1075:23:
error: no viable conversion from 'ArrayRef<std::pair<Record *, SMRange>>'
to 'ArrayRef<llvm::Record *>'
ArrayRef<Record*> Bases = Search->getSuperClasses();
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/Source/Swift/llvm/include/llvm/ADT/ArrayRef.h:32:9: note:
candidate constructor (the implicit copy constructor) not viable: no known
conversion from 'ArrayRef<std::pair<Record *, SMRange> >' to 'const
llvm::ArrayRef<llvm::Record *> &' for 1st argument
class ArrayRef {
^
/home/pi/Source/Swift/llvm/include/llvm/ADT/ArrayRef.h:32:9: note:
candidate constructor (the implicit move constructor) not viable: no known
conversion from 'ArrayRef<std::pair<Record *, SMRange> >' to
'llvm::ArrayRef<llvm::Record *> &&' for 1st argument
class ArrayRef {
...
I might try again tomorrow updating to a newer clang build, or maybe I
should just wave the white flag and rewrite my tiny codebase in C++ instead
of trying to use Swift here, and wait for it to be a bit more
stable/supported.
-tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/789510bf/attachment-0001.html
------------------------------
Message: 8
Date: Mon, 18 Apr 2016 17:39:51 +0200
From: Geordie Jay <geojay@gmail.com>
To: swift-dev@swift.org
Subject: [swift-dev] SIMD in open source Swift?
Message-ID: <B4B1849C-8046-4C00-A34A-72BDC4CB08A8@gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear fellow Swift-Devvers,
On Darwin we have a SIMD module, but I’m assuming (based on playing around
with it in the past) that it is unavailable in open-source Swift.
Does anyone know another way of using SIMD intrinsics in a cross-platform
way (Linux-only would also do)? Also, is it a goal to provide at least SIMD
intrinsics and basic operations within Swift’s core in the future, or is
the general philosophy that this kind of thing will be maintained by the
community?
Regards,
Geordie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160418/7083c5d4/attachment-0001.sig
------------------------------
Message: 9
Date: Fri, 15 Apr 2016 17:00:18 -0700
From: Sean Callanan <scallanan@apple.com>
To: swift-dev@swift.org
Subject: Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift
Incremental RA - Ubuntu 15.10 (master) #4254
Message-ID: <5DC21488-5922-40B9-9EDA-E3159B1B0099@apple.com>
Content-Type: text/plain; charset="utf-8"
I’m on it.
Sean
On Apr 15, 2016, at 4:56 PM, no-reply@swift.org wrote:
[FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#4254]
Build URL:
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/
<https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/
Project: oss-swift-incremental-RA-linux-ubuntu-15_10
Date of build: Fri, 15 Apr 2016 16:48:20 -0700
Build duration: 8 min 3 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 <
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
Failed: 11 test(s), Passed: 7798 test(s), Total: 7809 test(s)
Failed: Swift.PlaygroundTransform.array.swift <
Failed: Swift.PlaygroundTransform.array_did_set.swift <
Failed: Swift.PlaygroundTransform.bare_value.swift <
Failed: Swift.PlaygroundTransform.control-flow.swift <
Failed: Swift.PlaygroundTransform.declarations.swift <
Failed: Swift.PlaygroundTransform.do-catch.swift <
Failed: Swift.PlaygroundTransform.do.swift <
Failed: Swift.PlaygroundTransform.high_performance.swift <
Failed: Swift.PlaygroundTransform.init.swift <