Re: [swift-dev] Policy on the use of clang-format

Hi Mark! > The general policy is no bulk reformatting. Cool! > It’s fine to reformat lines that you otherwise change, Got it! > There’s a tool called git-clang-format which makes it easy to run > clang-format but only touch the lines you’ve already modified. Awesome, thanks! Omeed > On Ap

[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] changes in the inliner

on Fri Apr 01 2016, Erik Eckstein wrote: > Hi, > > I'd like to give some more information about the inliner changes I landed > this week. > > The goal was to restrict inlining to improve code size while not degrade > performance (too much). > This was mainly achieved by improving the heuristic

[swift-dev] Why are we re-linking?

Can anyone explain why we're re-linking all these C++ executables when I make changes only to the standard library? [5/130] Linking CXX static library lib/libswiftBasic.a [6/130] Linking CXX shared library lib/libswiftDemangle.dylib [7/130] Linking CXX executable bin/swift [8/130] Linking CXX exe

Re: [swift-dev] Why are we re-linking?

I imagine it's because your git hash has changed, which is used in the --version output for swiftc. I'm not sure how to avoid that cost entirely, but we could add a CMake option to not do it (which you could set locally), and we could probably move it to a library that isn't used by most of thos

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

Hey, Saleem. How do you expect this to differ from normal symbol visibility? It seems to me that in a shared library, any public symbol is either exported or imported, depending on whether it has a definition, and any non-public symbol is default. (Unlike C, we expect to have sensible rules here

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

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, any public symbol is > either exported or imported, depending on whether it has a definition, and > any non-public symbol i

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

> On Apr 6, 2016, at 11:18 AM, Jordan Rose via swift-dev > wrote: > > Hey, Saleem. How do you expect this to differ from normal symbol visibility? > It seems to me that in a shared library, any public symbol is either exported > or imported, depending on whether it has a definition, and any no

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

> 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, any public symbol is either ex

Re: [swift-dev] The build system is ignoring swift-install-components when cross compiling

Has anyone tested the assorted install commands while cross compiling? Are they supposed to work? Andrew Hyatt ahyatt...@icloud.com > On Mar 30, 2016, at 5:43 PM, Andrew Hyatt wrote: > > It appears as though the --install-swift flag is intended to make > build-script-impl install swift. Howev

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

> On Apr 6, 2016, at 10:21 AM, Saleem Abdulrasool via swift-dev > 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

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

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 > some interesting differences between COFF/PE and (ELF

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

My bad, I will fix this > On Apr 6, 2016, at 1:03 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#3996] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/3996/ >

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

Whoops, fixed. - Doug > On Apr 6, 2016, at 4:41 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#3224] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/3224/ > > Project:

[swift-dev] quick, spot the UB in this code:

let completeFile = [112, 114, 105, 110, 116, 40, 34, 104, 101, 108, 108, 111, 32, 119, 111, 114, 108, 100, 34, 41] let str = String(validatingUTF8: completeFile) Did you see it? No? What if our bytes are not UTF8? Well, one would hope that the constructor, um, validates them. Turns out it do

Re: [swift-dev] quick, spot the UB in this code:

On Wed, Apr 6, 2016 at 9:16 PM, Drew Crawford via swift-dev wrote: > and it should crash > deterministically if it gets non-terminated bytes, or It can't, how would you check for this, only given a pointer? > 2. It should not require null-terminated bytes This operation converts a C string to

Re: [swift-dev] quick, spot the UB in this code:

Could we get a method that takes a [UInt8] directly and performs the same basic function? In my experience I have frequently wanted such a thing (primarily when debugging things) when working with binary protocols that have embedded ASCII data. - Daniel > On Apr 6, 2016, at 9:51 PM, Dmitri Gr

Re: [swift-dev] quick, spot the UB in this code:

On Wed, Apr 6, 2016 at 9:54 PM, Daniel Dunbar wrote: > Could we get a method that takes a [UInt8] directly and performs the same > basic function? I think the root of the surprise here is that the compiler converts [UInt8] into an unsafe pointer. This is appropriate when the callee is a C API,

Re: [swift-dev] quick, spot the UB in this code:

> On Apr 6, 2016, at 9:58 PM, Dmitri Gribenko wrote: > > On Wed, Apr 6, 2016 at 9:54 PM, Daniel Dunbar wrote: >> Could we get a method that takes a [UInt8] directly and performs the same >> basic function? > > I think the root of the surprise here is that the compiler converts > [UInt8] into

Re: [swift-dev] quick, spot the UB in this code:

> On Apr 6, 2016, at 11:51 PM, Dmitri Gribenko wrote: > > This operation converts a C string to a Swift string, so (2) is a non-starter. Then it is inappropriately named. The name of the constructor is `validatingUTF8`, not `cString`.___ swift-dev

Re: [swift-dev] quick, spot the UB in this code:

On Wed, Apr 6, 2016 at 10:03 PM, Drew Crawford wrote: > > On Apr 6, 2016, at 11:51 PM, Dmitri Gribenko wrote: > > This operation converts a C string to a Swift string, so (2) is a > non-starter. > > > Then it is inappropriately named. The name of the constructor is > `validatingUTF8`, not `cStri