Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?
> On May 6, 2016, at 3:04 PM, Daniel Dunbar wrote: > > The conclusion was that after weighing all of the tradeoffs, it made the most > sense to encourage porting of SourceKit to Linux and then using it to build > out > the Linux test discovery feature. This was most in line with a desirable > long-term direction without being blocked on language design. For whatever it's worth, this direction is a win on my side as well. In addition to the problem of test discovery (for which I'm using an out-of-tree parser), I have a lot of other problems entirely outside of testing that rely on source-level queries similar to the XCTest problem. This is things like parsing comments for documentation, implementing dispatch-by-string, etc. I currently rely on SK in many cases, but lack of support on Linux is a major issue. Lack of features exposed in the SK APIs is another issue. IMO it is a clear win to invest in resolving these problems inside SK. Right now it is basically a glorified Xcode daemon, but I think it can have a bright future as a multi-client tool if we're willing to invest in making that happen.___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] swift (ABI) and Windows
Hi all,
I merged Saleem's #2080 to my working branch, and did some experiment.
I could compile easily Hello.swift with #2080 merged one.
swiftc -c -o Hello.obj Hello.swift
clang -o Hello.exe Hello.obj -llibswiftCore -llibswiftSwiftOnoneSupport
-Wl,
Without #2080, I should use the *.ll-modifying-trick. It is perfect in this
example.
But, we need the way to disable dllimport. The immediate mode did not work.
swift Hello.swift
LLVM ERROR: Program used external function
'__imp_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_func3' which could
not be resolved!
swift -O Hello.swift
LLVM ERROR: Program used external function
'__imp__swift_getExistentialTypeMetadata' which could not be resolved!
It seems swift.exe call directly the function in the DLL without import
library.
The feature also needed when we link to static library.
I don't know about the SIL, IR, so it is thankful someone tell me how to
approach this problem.
2016-05-07 5:01 GMT+09:00 Saleem Abdulrasool :
> On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev <
> swift-dev@swift.org> wrote:
>
>>
>> > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev <
>> swift-dev@swift.org> wrote:
>> >
>> > Hi,
>> >
>> > I made an experimental MSVC port. Of cause, dllimport/dllexport and the
>> driver for linking and many other part is not implemented. But dynamic
>> linking was possible with some trick.
>> >
>> > I think it is useful for designing, my observation about the
>> experimental building of libswiftCore.dll, libswiftSwiftOnoneSupport.dll
>> and linking of Hello.exe - its source has only 'print("Hello")'.
>> >
>> > 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.
>> > Hello.obj needed defined in libswift*.dll
>> > _swift_getExistentialTypeMetadata,
>> > _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,
>> > _TMSS,
>> > _TZvOs7Process5_argcVs5Int32,
>> > swift_bufferAllocate,
>> > Some of above are dllexported by the macro, but _T* are not. Maybe,
>> it generated by swiftc.exe.
>> > I used the utility 'dlltool.exe' from Cygwin/MinGW world. It extracts
>> all symbols and generates 'allsymbol.def'.
>> > With that .def, I could build the all-symbol-dllexported
>> libswiftCore.dll.
>> > (I'm hoping we can build it without this trick.)
>>
>> The _T symbols are emitted by the Swift compiler. You should modify
>> swiftc's IRGen to generate public symbols with LLVM's "dllexport" storage
>> class when targeting Windows.
>
>
> https://github.com/apple/swift/pull/2080 is a first cut attempt to do
> this.
>
>
>>
>> -Joe
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] swift (ABI) and Windows
One more,
I couldn't build the libswiftCore.dll which can be used for Hello.swift. At
least one symbol _TMSS is not dllexported.
(But I could build the dll with dlltool.exe which make all symbols to be
dllexported)
To find out the reason, I built a Swift.ll instead of the Swift.obj for the
libswiftCore.dll. The Swift.ll are built from many
stdlib/public/core/*.swift and core/8/*.swift files, and about 50MB.
In that file, I could find many dllexport symbols, like
@_TZvOs7Process5_argcVs5Int32 = dllexport global %Vs5Int32 zeroinitializer,
align 4
and Hello.ll uses them,
@_TZvOs7Process5_argcVs5Int32 = external dllimport global %Vs5Int32, align 4
In the case of _TMSS, Hello.ll uses the same way,
@_TMSS = external dllimport global %swift.type, align 8
But, Swift.ll did not declared with dllexport.
@_TMSS = alias %swift.type, bitcast (i64* getelementptr inbounds (<{ i8**,
i64, i64, %swift.type*, i64 }>, <{ i8**, i64, i64, %swift.type*, i64 }>*
@_TMfSS, i32 0, i32 1) to %swift.type*)
How we can make @_TMSS also has the dllexport? Or any other solution ?
-Han Sangjin
2016-05-08 8:01 GMT+09:00 Sangjin Han :
> Hi all,
>
> I merged Saleem's #2080 to my working branch, and did some experiment.
>
> I could compile easily Hello.swift with #2080 merged one.
>
> swiftc -c -o Hello.obj Hello.swift
> clang -o Hello.exe Hello.obj -llibswiftCore -llibswiftSwiftOnoneSupport
> -Wl,
>
> Without #2080, I should use the *.ll-modifying-trick. It is perfect in
> this example.
>
> But, we need the way to disable dllimport. The immediate mode did not work.
>
> swift Hello.swift
> LLVM ERROR: Program used external function
> '__imp_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_func3' which could
> not be resolved!
>
> swift -O Hello.swift
> LLVM ERROR: Program used external function
> '__imp__swift_getExistentialTypeMetadata' which could not be resolved!
>
> It seems swift.exe call directly the function in the DLL without import
> library.
>
> The feature also needed when we link to static library.
>
> I don't know about the SIL, IR, so it is thankful someone tell me how to
> approach this problem.
>
>
> 2016-05-07 5:01 GMT+09:00 Saleem Abdulrasool :
>
>> On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev <
>> swift-dev@swift.org> wrote:
>>
>>>
>>> > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev <
>>> swift-dev@swift.org> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I made an experimental MSVC port. Of cause, dllimport/dllexport and
>>> the driver for linking and many other part is not implemented. But dynamic
>>> linking was possible with some trick.
>>> >
>>> > I think it is useful for designing, my observation about the
>>> experimental building of libswiftCore.dll, libswiftSwiftOnoneSupport.dll
>>> and linking of Hello.exe - its source has only 'print("Hello")'.
>>> >
>>> > 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.
>>> > Hello.obj needed defined in libswift*.dll
>>> > _swift_getExistentialTypeMetadata,
>>> > _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,
>>> > _TMSS,
>>> > _TZvOs7Process5_argcVs5Int32,
>>> > swift_bufferAllocate,
>>> > Some of above are dllexported by the macro, but _T* are not. Maybe,
>>> it generated by swiftc.exe.
>>> > I used the utility 'dlltool.exe' from Cygwin/MinGW world. It
>>> extracts all symbols and generates 'allsymbol.def'.
>>> > With that .def, I could build the all-symbol-dllexported
>>> libswiftCore.dll.
>>> > (I'm hoping we can build it without this trick.)
>>>
>>> The _T symbols are emitted by the Swift compiler. You should modify
>>> swiftc's IRGen to generate public symbols with LLVM's "dllexport" storage
>>> class when targeting Windows.
>>
>>
>> https://github.com/apple/swift/pull/2080 is a first cut attempt to do
>> this.
>>
>>
>>>
>>> -Joe
>>> ___
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>
>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
