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

DB, which imports Swift > headers; if Swift is going to move to C++14, then Swift-LLDB probably has > to as well. LLDB folks, what do you think? > > The other thing to check is if our minimum Clang or libstdc++ requirements > on Linux didn't support C++14. It looks like our README is

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

wift.org>> wrote: >>>>>>> >>>>>>> No one else has commented on this yet today, so I'll put in that I >>>>>>> don't have any objections to this and don't foresee any major problems. >>>>>>> The o

Re: [swift-dev] Preserving and Applying CC in Imported Decls

On Wed, Dec 13, 2017 at 4:14 PM, John McCall wrote: > > On Dec 13, 2017, at 6:42 PM, Saleem Abdulrasool > wrote: > > > > On Dec 13, 2017, at 12:46 PM, John McCall wrote: > > > On Dec 13, 2017, at 3:22 PM, Saleem Abdulrasool > wrote: > > > > On Dec 13, 2017, at 12:14 PM, John McCall wrote: > >

Re: [swift-dev] Preserving and Applying CC in Imported Decls

> On Dec 13, 2017, at 12:46 PM, John McCall wrote: > >> >> On Dec 13, 2017, at 3:22 PM, Saleem Abdulrasool > > wrote: >> >> >> >>> On Dec 13, 2017, at 12:14 PM, John McCall >> > wrote: >>> On Dec 13, 2017, at 2:56 PM, Sale

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

> On Dec 13, 2017, at 2:30 PM, Jordan Rose wrote: > > > >> On Dec 13, 2017, at 14:19, Saleem Abdulrasool wrote: >> >>> On Dec 13, 2017, at 1:45 PM, Jordan Rose wrote: >>> >>> No one else has commented on this yet today, so I'll put in that I don't >>> have any objections to this and don'

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

4) as well. So, I believe that the dependency issue should not be a problem. > Jordan > > >> On Dec 13, 2017, at 10:36, Saleem Abdulrasool via swift-dev >> wrote: >> >> Hi, >> >> The newer Windows SDK requires the use of C++14 (the SDK headers

[swift-dev] Switching swift to C++14

Hi, The newer Windows SDK requires the use of C++14 (the SDK headers use `auto` return types without trailing type information). Joe mentioned that there was some interest in switching the rest of swift to C++14 as well. I figured that I would just start a thread here to determine if this is oka

Re: [swift-dev] Request for review on Windows CMake changes

tion), but rather the way that the tool is being used within the context of swift. As an example, libdispatch is extremely easy to cross-compile thanks to its use of CMake. > > Em ter, 12 de dez de 2017 às 19:39, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> escreveu: &g

Re: [swift-dev] Request for review on Windows CMake changes

On Sat, Dec 9, 2017 at 9:21 AM, David Zarzycki via swift-dev < swift-dev@swift.org> wrote: > Can somebody please also speak up to why Windows needs to remove the > "-Wl,-z,defs” from CXX_FLAGS? At the very least, I’d like to see the > project-wide removal of this useful flag limited to just the Wi

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

On Fri, Dec 1, 2017 at 11:53 AM, Arnold Schwaighofer via swift-dev < swift-dev@swift.org> wrote: > 16_10/buildbot_incremental/libdispatch-linux-x86_64/src/swiftDispatch.o:0: > error: cannot open file > '/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift-corelibs-

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

Weird, this made it through multiple builds just fine. Either way, I believe PR#13180 should repair the build. > On Nov 30, 2017, at 11:33 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#1815] > > Build URL: > https://ci.swift.org/job/oss-swift-inc

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

On Tue, Nov 28, 2017 at 3:57 PM, Mishal Shah via swift-dev < swift-dev@swift.org> wrote: > :0: error: module map file > '/home/buildnode/jenkins/workspace/oss-swift-4.1-incremental-RA-linux-ubuntu-16_10/swift-corelibs-libdispatch/dispatch/module.modulemap' > not found:0: error: module map file

Re: [swift-dev] sharing tips and tricks and scripts

I agree with Jordan (and Chris) on this. I think that we should try to simplify the build process that we have rather than encouraging more build script wrappers. The current build process is pretty cumbersome which is why I think that many people have wrapper scripts. In fact, it seems that it

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

I think that PR308 on libdispatch should help with that. I don’t have CI rights on that repository though. On Sat, Oct 7, 2017 at 11:40 AM Saleem Abdulrasool via swift-dev < swift-dev@swift.org> wrote: > Hmm, just so I understand what is going on here ... is there an > incompatibl

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

Hmm, just so I understand what is going on here ... is there an incompatible change and we aren't rebuilding enough stuff (possibly a missing dependency?) or is there something else going on? Sounds like the swift portion of the build needs to be more aggressively rebuilt? On Fri, Oct 6, 2017 at

Re: [swift-dev] Metadata Representation

; wrote: >>> >>> >>> >>> On Thu, Sep 21, 2017 at 10:28 PM, John McCall >>> wrote: >>> >>> >>> >>>> On Sep 21, 2017, at 10:10 PM, Saleem Abdulrasool < >>> compn...@compnerd.org> wrote: >>> >

Re: [swift-dev] Metadata Representation

1, 2017, at 10:10 PM, Saleem Abdulrasool < >> compn...@compnerd.org> wrote: >> >>>> >> >>>> On Thu, Sep 21, 2017 at 5:18 PM, John McCall >> wrote: >> >>>>> On Sep 21, 2017, at 1:26 PM, Saleem Abdulrasool via swift-dev <

Re: [swift-dev] libdispatch switched to CMake

On Mon, Sep 25, 2017 at 11:39 AM, Jordan Rose wrote: > > > On Sep 25, 2017, at 11:28, Jordan Rose wrote: > > > > On Sep 24, 2017, at 19:32, Saleem Abdulrasool > wrote: > > On Sat, Sep 23, 2017 at 5:02 AM, David P Grove wrote: > >> With autotools, the first time libdispatch was built (for Sourc

Re: [swift-dev] Metadata Representation

On Thu, Sep 21, 2017 at 10:28 PM, John McCall > wrote: > >>> > >>>> On Sep 21, 2017, at 10:10 PM, Saleem Abdulrasool < > compn...@compnerd.org> wrote: > >>>> > >>>> On Thu, Sep 21, 2017 at 5:18 PM, John McCall > wrote: > >>

Re: [swift-dev] libdispatch switched to CMake

t; > [image: Inactive hide details for Saleem Abdulrasool via swift-dev > ---09/22/2017 08:59:28 PM---On Fri, Sep 22, 2017 at 2:31 PM, Jordan]Saleem > Abdulrasool via swift-dev ---09/22/2017 08:59:28 PM---On Fri, Sep 22, 2017 > at 2:31 PM, Jordan Rose wrote: > Hey, Saleem. I >

Re: [swift-dev] libdispatch switched to CMake

ssibly that the swift module is not built? Ill try to take a look at that (though, honestly, that would probably be tomorrow). Sorry about the trouble there (it built for me and on the build bots). Thanks, > Jordan > > > On Sep 18, 2017, at 15:28, Saleem Abdulrasool via swift-de

Re: [swift-dev] Metadata Representation

On Thu, Sep 21, 2017 at 10:28 PM, John McCall wrote: > > On Sep 21, 2017, at 10:10 PM, Saleem Abdulrasool > wrote: > > On Thu, Sep 21, 2017 at 5:18 PM, John McCall wrote: > >> On Sep 21, 2017, at 1:26 PM, Saleem Abdulrasool via swift-dev < >> swift-dev@swift.or

Re: [swift-dev] Metadata Representation

On Thu, Sep 21, 2017 at 5:18 PM, John McCall wrote: > On Sep 21, 2017, at 1:26 PM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> wrote: > On Thu, Sep 21, 2017 at 12:04 PM, Joe Groff wrote: > >> >> >> On Sep 21, 2017, at 11:49 AM, Saleem Abdulra

Re: [swift-dev] Metadata Representation

On Thu, Sep 21, 2017 at 12:04 PM, Joe Groff wrote: > > > On Sep 21, 2017, at 11:49 AM, Saleem Abdulrasool > wrote: > > On Thu, Sep 21, 2017 at 10:53 AM, Joe Groff wrote: > >> >> >> On Sep 21, 2017, at 9:32 AM, Saleem Abdulrasool via swift-dev <

Re: [swift-dev] Metadata Representation

On Thu, Sep 21, 2017 at 10:53 AM, Joe Groff wrote: > > > On Sep 21, 2017, at 9:32 AM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> wrote: > > Hello, > > The current layout for the swift metadata for structure types, as emitted, > seems to be unrepre

[swift-dev] Metadata Representation

Hello, The current layout for the swift metadata for structure types, as emitted, seems to be unrepresentable in PE/COFF (at least for x86_64). There is a partial listing of the generated code following the message for reference. When building the standard library, LLVM encounters a relocation w

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

Mon, Sep 18, 2017 at 7:13 PM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> wrote: > >> Ugh, I think I see what the issue is. The build-script-impl wrapper is >> pretty intricate and I missed the conditional check since it was pretty >> similar to the one

Re: [swift-dev] Changing ELF layout

On Tue, Sep 19, 2017 at 8:42 AM Joe Groff wrote: > > On Sep 18, 2017, at 9:24 PM, Saleem Abdulrasool > wrote: > > On Mon, Sep 18, 2017 at 4:07 PM, Joe Groff wrote: > >> >> >> On Sep 18, 2017, at 3:31 PM, Saleem Abdulrasool via swift-dev < >> swift-

Re: [swift-dev] Changing ELF layout

On Mon, Sep 18, 2017 at 4:07 PM, Joe Groff wrote: > > > On Sep 18, 2017, at 3:31 PM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> wrote: > > > On Mon, Sep 18, 2017 at 9:36 AM John McCall wrote: > >> On Sep 17, 2017, at 10:15 AM, Saleem Abdulra

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

PR#11994 On Mon, Sep 18, 2017 at 7:13 PM, Saleem Abdulrasool via swift-dev < swift-dev@swift.org> wrote: > Ugh, I think I see what the issue is. The build-script-impl wrapper is > pretty intricate and I missed the conditional check since it was pretty > similar to the one near i

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

arily. On Mon, Sep 18, 2017 at 6:59 PM, Saleem Abdulrasool via swift-dev < swift-dev@swift.org> wrote: > Yeah, Im looking into this. That is a really weird error. It seems like > it would be related to the the switch to CMake for libdispatch. > > On Mon, Sep 18, 2017 at 6:34 PM,

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

Yeah, Im looking into this. That is a really weird error. It seems like it would be related to the the switch to CMake for libdispatch. On Mon, Sep 18, 2017 at 6:34 PM, Vedant Kumar via swift-dev < swift-dev@swift.org> wrote: > I don't think I have changed this or control it: > > --install-dest

Re: [swift-dev] Changing ELF layout

On Mon, Sep 18, 2017 at 9:36 AM John McCall wrote: > On Sep 17, 2017, at 10:15 AM, Saleem Abdulrasool > wrote: > > On Sat, Sep 16, 2017 at 6:19 PM, John McCall wrote: > >> > On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev < >> swift-dev@swift.org&

[swift-dev] libdispatch switched to CMake

Hello swift-dev, This change should be transparent to everyone, but, it still is a pretty big milestone. As of this afternoon, the non-Darwin builds use CMake to build libdispatch. This work has been underway for quite some time, and we have finally switched to that as the default on most target

Re: [swift-dev] Changing ELF layout

On Sat, Sep 16, 2017 at 6:19 PM, John McCall wrote: > > On Sep 16, 2017, at 6:06 PM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> wrote: > > Hello, > > > > I'd like to propose that we change the locations that we use to store > the t

[swift-dev] Changing ELF layout

Hello, I'd like to propose that we change the locations that we use to store the type metadata, protocol conformances, type references, reflection strings, field metadata, and associated types. I think that it is possible to simplify the design for the linker tables by changing section names and

Re: [swift-dev] swift-format editor integration

On Tue, May 2, 2017 at 10:41 PM Ted Kremenek wrote: > On Apr 28, 2017, at 8:17 AM, Saleem Abdulrasool > wrote: > > Hi Ted, > > I think that what I'm proposing adding is quite small. It has a mirror > equivalent in the clang repository. > > > I thought about it more, and you convinced me. I’m f

Re: [swift-dev] swift-format editor integration

Hi Ted, I think that what I'm proposing adding is quite small. It has a mirror equivalent in the clang repository. As to maintainence, I'm willing to take that on. I already maintain the vim syntax support (I'm pretty confident that I've made the bulk of the changes to it at this point). I'm n

[swift-dev] swift-format editor integration

Hi, Jordan asked me to check with you about adding a simple helper for integrating swift-format into vim since the repository hasn't really added any editor integration stuff previously. It's just a python wrapper for invoking swift-format (much like clang-format). It is on GitHub as PR8610. Th

Re: [swift-dev] Breaking brain

On Wed, Feb 1, 2017 at 10:24 AM, Joe Groff via swift-dev < swift-dev@swift.org> wrote: > > > On Feb 1, 2017, at 2:33 AM, Chris Eidhof via swift-dev < > swift-dev@swift.org> wrote: > > > > The error tells you it's not a function, but a String. In other words, > it's a property of filemgr. Try calli

Re: [swift-dev] proposed change for master-next merges

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 tha

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

Just had a closer look at this. This is related to PR #6048. It got through the bots due to an incremental build. Trying to get the revert merged. On Sat, Dec 3, 2016 at 2:14 PM, wrote: > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#81] > Build URL: https://ci.swift.org/jo

Re: [swift-dev] C API Annotations outside of original header?

On Sun, Jul 17, 2016 at 4:10 PM, Geordie Jay wrote: > Is it possible that apinotes only works for Objective C? The only docs > I've seen regarding them explicitly mention ObjC repeatedly I would find that hard to believe given that it is used for importing libdispatch (C) into Swift. > Saleem

Re: [swift-dev] C API Annotations outside of original header?

On Sun, Jul 17, 2016 at 1:39 PM, Geordie J via swift-dev < swift-dev@swift.org> wrote: > Hi, I’m hoping to add CF_SWIFT_NAME annotations to an imported Clang > module (JNI) without editing the original header file itself. Is this > possible, or is there a working alternative other than creating a

Re: [swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

On Sat, Jul 9, 2016 at 4:07 PM, Saleem Abdulrasool wrote: > On Wed, Jul 6, 2016 at 9:43 AM, John McCall wrote: > >> On Jul 6, 2016, at 7:33 AM, Saleem Abdulrasool >> wrote: >> On Tue, Jul 5, 2016 at 6:28 PM, John McCall wrote: >> >>> On Jul 5, 2016, at 5:56 PM, Saleem Abdulrasool >>> wrote: >

Re: [swift-dev] [RFC] Finer grained OS checks

On Mon, Jul 11, 2016 at 2:33 PM, Karl Wagner wrote: > I remember somebody telling me it was, but it was years ago and I'm > probably remembering it wrong. Fair enough though; I got told on that one > 😶 > > I'm standing by the principle - it shouldn't matter if you're running in a > simulator or n

Re: [swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

On Wed, Jul 6, 2016 at 9:43 AM, John McCall wrote: > On Jul 6, 2016, at 7:33 AM, Saleem Abdulrasool > wrote: > On Tue, Jul 5, 2016 at 6:28 PM, John McCall wrote: > >> On Jul 5, 2016, at 5:56 PM, Saleem Abdulrasool >> wrote: >> On Tue, Jul 5, 2016 at 10:30 AM, John McCall wrote: >> >>> > On Ju

[swift-dev] [RFC] Finer grained OS checks

Hi, Id like to revive the discussion around OS "variants". I've been doing some work to bring up Windows without any emulation layer (MSVCRT based) as a viable host environment. This work is bringing to light the need for more finer grained OS checks. Currently, we have the `os` compilation con

Re: [swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

On Tue, Jul 5, 2016 at 6:28 PM, John McCall wrote: > On Jul 5, 2016, at 5:56 PM, Saleem Abdulrasool > wrote: > On Tue, Jul 5, 2016 at 10:30 AM, John McCall wrote: > >> > On Jul 3, 2016, at 2:40 PM, Saleem Abdulrasool >> wrote: >> > Hello again, >> > >> > I come bearing more problems :-). >> >

Re: [swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

On Tue, Jul 5, 2016 at 10:30 AM, John McCall wrote: > > On Jul 3, 2016, at 2:40 PM, Saleem Abdulrasool > wrote: > > Hello again, > > > > I come bearing more problems :-). > > > > I seem to have found another point in the ABI which prevents an easy > port of swift to Windows without an emulation

[swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

Hello again, I come bearing more problems :-). I seem to have found another point in the ABI which prevents an easy port of swift to Windows without an emulation layer underneath. This time it deals with the protocol conformance table. The table is constructed with a direct reference to protoco

[swift-dev] Handling Windows C library Matrix

Hi, Windows has an interesting (different) model for handling the C library. There are *four* different libraries and you select the library you want across two axis. Traditionally the driver controls the selected library via flags (and options exposed to the developer via the IDE). Im not sure

[swift-dev] Requiring blocks (universally)

Hi, The blocks runtime itself is pretty tiny, and works across various targets already, so including it is not too onerous. As such, Id like to propose enabling blocks across all the targets. This make it easier to then import code on targets which have optional blocks support. For most users,

Re: [swift-dev] [RFC] Toolchain based build process

On Wed, Jun 1, 2016 at 2:18 PM, Daniel Dunbar via swift-dev < swift-dev@swift.org> wrote: > Hi all, > > The current build process for the overall Swift project (i.e., the > compiler + associated projects like Foundation, XCTest, and SwiftPM) relies > on each project having dependencies on the buil

Re: [swift-dev] Relative Pointers and Windows ARM

cheers, > > Tom > > > > On Thu, May 19, 2016 at 9:51 AM Joe Groff via swift-dev < > swift-dev@swift.org> wrote: > > > > > On May 18, 2016, at 6:01 PM, Saleem Abdulrasool > wrote: > > > > > > On Wednesday, May 18, 2016, Joe Groff wrote:

Re: [swift-dev] Requiring gold linker for Linux targets?

ven that BFD seems to be a liability, I think it > > makes sense to transition. In the interest of full disclosure, I don't > > fully understand all the implications of this change, especially on x86. > > > > - Will > > > > > On May 13, 2016, at 6:

Re: [swift-dev] Relative Pointers and Windows ARM

On Thu, May 19, 2016 at 9:07 AM, John McCall wrote: > > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool > wrote: > > Hi, > > > > It seems that there are assumptions about the ability to create relative > address across sections which doesn't seem possible on Windows ARM. > > > > Consider the fol

Re: [swift-dev] Relative Pointers and Windows ARM

On Wednesday, May 18, 2016, Joe Groff wrote: > > > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org > wrote: > > > > Hi, > > > > It seems that there are assumptions about the ability to create relative > address a

[swift-dev] Relative Pointers and Windows ARM

Hi, It seems that there are assumptions about the ability to create relative address across sections which doesn't seem possible on Windows ARM. Consider the following swift code: final class _ContiguousArrayStorage { } When compiled for Windows x86 (via swiftc -c -target i686-windows -parse-as

[swift-dev] Requiring gold linker for Linux targets?

Hi, On ARM targets, gold is already required due to a certain bugs in the handling of relocations for those targets. For other targets, there was a bug exposed in the BFD linker (which is believed to have been fixed in a newer release). Recently, another change seems to have exposed yet another

Re: [swift-dev] swift (ABI) and Windows

On Tue, May 3, 2016 at 6:34 PM, Jordan Rose wrote: > > On Apr 26, 2016, at 08:43, Saleem Abdulrasool > wrote: > > On Tue, Apr 12, 2016 at 9:32 AM, Saleem Abdulrasool > wrote: > >> On Monday, April 11, 2016, Joe Groff wrote: >> >>> >>> &g

Re: [swift-dev] swift (ABI) and Windows

On Tue, May 10, 2016 at 2:29 PM, Joe Groff wrote: > It might help to centralize the logic. In IRGen, there's a function > getIRLinkage that decomposes a semantic SIL visibility into an LLVM linkage > and visibility pair: > > https://github.com/apple/swift/blob/master/lib/IRGen/GenDecl.cpp#L1201 >

Re: [swift-dev] swift (ABI) and Windows

On Monday, May 9, 2016, Joe Groff wrote: > > > On May 9, 2016, at 7:19 PM, Saleem Abdulrasool > wrote: > > > > On Sat, May 7, 2016 at 7:55 PM, Sangjin Han > wrote: > > One more, > > > > I couldn't build the libswiftCore.dll which can be used for Hello.swift. > At least one symbol _TMSS is not d

Re: [swift-dev] swift (ABI) and Windows

On Sat, May 7, 2016 at 7:55 PM, Sangjin Han wrote: > 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

Re: [swift-dev] swift (ABI) and Windows

On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev 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 im

Re: [swift-dev] swift (ABI) and Windows

On Tue, Apr 12, 2016 at 9:32 AM, Saleem Abdulrasool wrote: > On Monday, April 11, 2016, Joe Groff wrote: > >> >> > On Apr 11, 2016, at 3:19 PM, Saleem Abdulrasool via swift-dev < >> swift-dev@swift.org> wrote: >> > >> > On Thu, Ap

Re: [swift-dev] swift (ABI) and Windows

On Monday, April 11, 2016, Joe Groff wrote: > > > On Apr 11, 2016, at 3:19 PM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org > wrote: > > > > On Thu, Apr 7, 2016 at 2:12 PM, Saleem Abdulrasool < > compn...@compnerd.org > wrote: > > On Wed

Re: [swift-dev] swift (ABI) and Windows

On Thu, Apr 7, 2016 at 2:12 PM, Saleem Abdulrasool wrote: > On Wed, Apr 6, 2016 at 10:21 AM, Saleem Abdulrasool > wrote: > >> Hi, >> >> I was playing around with the idea of swift and Windows since there are >> some interesting differences between COFF/PE and (ELF and MachO). >> >> PE/COFF does

Re: [swift-dev] swift (ABI) and Windows

On Wed, Apr 6, 2016 at 10:21 AM, Saleem Abdulrasool wrote: > Hi, > > I was playing around with the idea of swift and Windows since there are > some interesting differences between COFF/PE and (ELF and MachO). > > PE/COFF does not directly address symbols in external modules > (DSOs/dylibs/DLLs).

Re: [swift-dev] swift (ABI) and Windows

On Wed, Apr 6, 2016 at 11:39 AM, Joe Groff wrote: > > > On Apr 6, 2016, at 10:21 AM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> wrote: > > > > Hi, > > > > I was playing around with the idea of swift and Windows since there are > som

Re: [swift-dev] swift (ABI) and Windows

On Wed, Apr 6, 2016 at 11:34 AM, Jordan Rose wrote: > > On Apr 6, 2016, at 11:31, Saleem Abdulrasool > wrote: > > On Wed, Apr 6, 2016 at 11:18 AM, Jordan Rose > wrote: > >> Hey, Saleem. How do you expect this to differ from normal symbol >> visibility? It seems to me that in a shared library, a

Re: [swift-dev] swift (ABI) and Windows

static and shared libraries seems unfortunate to > have to expose to IRGen, but we may end up needing that anyway to handle > Mach-O/ELF-style symbol visibility. > Yes, it is unfortunate, but sounds like it could end up being beneficial. > Jordan > > > > On Apr 6, 2016, at

[swift-dev] swift (ABI) and Windows

Hi, I was playing around with the idea of swift and Windows since there are some interesting differences between COFF/PE and (ELF and MachO). PE/COFF does not directly address symbols in external modules (DSOs/dylibs/DLLs). Instead, there is an indirect addressing model (thunks in Windows parlan

Re: [swift-dev] long double usage in swift

On Wed, Mar 23, 2016 at 3:54 PM, Joe Groff wrote: > > > On Mar 23, 2016, at 2:25 PM, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> wrote: > > > > Hi, > > > > I was looking at an ABI related issue on Windows. In trying to > construct a tes

Re: [swift-dev] long double usage in swift

int >> value. >> > > Im explicitly trying to import a call from C through the clang-importer > (to ensure that long doubles are imported correctly). As such, > unfortunately, I don't think that the use of Float80 is appropriate in this > case. > > >>

Re: [swift-dev] long double usage in swift

, I don't think that the use of Float80 is appropriate in this case. > Alex > > > On 23 Mar 2016, at 21:25, Saleem Abdulrasool via swift-dev < > swift-dev@swift.org> wrote: > > > > Hi, > > > > I was looking at an ABI related issue on Windows. In t

Re: [swift-dev] long double usage in swift

Sorry, hit send too quickly: Inputs/abi.h: float fp32_call(void); double fp64_call(void); long double fp80_call(void); Inputs/module.map: module abi { header "abi.h" } test.swift: %swift -I Inputs -parse %s import abi @inline(never) func blackhole(t : T) { } func test_floating_point() {

[swift-dev] long double usage in swift

Hi, I was looking at an ABI related issue on Windows. In trying to construct a test case, it seems that I am unable to import a declaration using a long double into swift. I was wondering if there is something about long double usage in swift that I am unaware of. Inputs/abi.h: float fp32_call