Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.10 (master) #321

Testing Time: 625.72s Failing Tests (17): Swift(linux-x86_64) :: SIL/parse_stdlib_15.sil Swift(linux-x86_64) :: SIL/parse_stdlib_0.sil Swift(linux-x86_64) :: SIL/parse_stdlib_10.sil Swift(linux-x86_64) :: SIL/parse_stdlib_13.sil

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 4:48 PM, Greg Parker wrote: > > >> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev >> wrote: >> >> Before I pull in a large PR that "accidentally" reformats a bunch of code, I >> want to get feedback on how Swift

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev > wrote: > > Before I pull in a large PR that "accidentally" reformats a bunch of code, I > want to get feedback on how Swift compiler devs plan to use `clang-format`. > (BTW, here's the PR

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 12:55, Andrew Trick via swift-dev > wrote: > >> >> On Jan 26, 2017, at 11:38 AM, Graydon Hoare wrote: >> >> >>> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev >>> wrote: >>> >>> Before I pull in a

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 11:38 AM, Graydon Hoare wrote: > > >> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev >> wrote: >> >> Before I pull in a large PR that "accidentally" reformats a bunch of code, I >> want to get feedback on how Swift

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev > wrote: > > Before I pull in a large PR that "accidentally" reformats a bunch of code, I > want to get feedback on how Swift compiler devs plan to use `clang-format`. > (BTW, here's the PR

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

Can I make a more radical suggestion. Maybe the thing to do here is to enforce git-clang-format so that everyone uses it. It would be really simple to do. You would require people to put it in a pre commit hook. Then swift-ci would have a job that ran git-clang-format and would require it to

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 10:34 AM, Andrew Trick via swift-dev > wrote: > > >> On Jan 26, 2017, at 10:25 AM, Jordan Rose > > wrote: >> >>> >>> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 10:25 AM, Jordan Rose wrote: > >> >> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev > > wrote: >> >>> >>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir >>

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev > wrote: > >> >> On Jan 26, 2017, at 9:29 AM, Ben Langmuir > > wrote: >> >>> >>> On Jan 26, 2017, at 9:14 AM, Andrew Trick >>

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 9:29 AM, Ben Langmuir wrote: > >> >> On Jan 26, 2017, at 9:14 AM, Andrew Trick > > wrote: >> >> >>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir >> > wrote:

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

Jenkins error, not my commit. > On Jan 26, 2017, at 00:13, no-re...@swift.org wrote: > > [FAILURE] oss-swift-3.1-incremental-RA-osx [#230] > > Build URL:https://ci.swift.org/job/oss-swift-3.1-incremental-RA-osx/230/ > >

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 9:14 AM, Andrew Trick wrote: > > >> On Jan 26, 2017, at 9:11 AM, Ben Langmuir > > wrote: >>> >>> ** Option 1: Add a simple configuration option to swift/.clang-format: >>> >>> 1a.

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 9:11 AM, Ben Langmuir wrote: >> >> ** Option 1: Add a simple configuration option to swift/.clang-format: >> >> 1a. BreakBeforeBinaryOperators: All >> >> 1b. BreakBeforeBinaryOperators: NonAssignment > >> >> I have absolutely no preference between

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev > wrote: > > Before I pull in a large PR that "accidentally" reformats a bunch of code, I > want to get feedback on how Swift compiler devs plan to use `clang-format`. > (BTW, here's the PR

[swift-dev] Race conditions with lazy variables

Hey, Today I ran into an issue where I had a lazy instance variable that was being initialized multiple times due to a race condition. For example: ``` import Darwin import Dispatch func doSomethingIntense() { usleep(10) } var counter: Int = 0 class Cat { lazy var sound:

[swift-corelibs-dev] swift-corelibs-dev build-script with --foundation is not working for me

Hi, a couple of days ago i ran into swift on linux. The whole thing makes so much sense for us. Developing our tools in swift could be a huge benefit. I am excited to get deeper into swift for linux. I build swift on Ubuntu successfully (without errors) from scratch with this options:

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 26, 2017, at 12:45 AM, Andrew Trick wrote: > > >> On Jan 25, 2017, at 6:13 PM, Joe Groff wrote: >> >>> Naturally, opaque types must limit some optimizations, such as inlining. >> >> I don't see how opaque types by themselves prevent inlining. You

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 5:07 AM, Andrew Trick via swift-dev > wrote: > Before I pull in a large PR that "accidentally" reformats a bunch of code, I > want to get feedback on how Swift compiler devs plan to use `clang-format`. > (BTW, here's the PR

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev > wrote: > I’m sending out a proposal for fundamentally changing SIL. This work feeds > into generic code optimization, resilience, semantic ARC, and SIL ownership. > This was discussed at length back in

Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

You are probably missing the package libblocksruntime-dev. That would cause that failure. Sent from my iPhone > On Jan 26, 2017, at 6:33 AM, Dennis Schafroth wrote: > > Thanks for the suggestions. > > It works with 3.0.2 but won't compile with 3.1 beta for Ubuntu

Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

Thanks for the suggestions. It works with 3.0.2 but won't compile with 3.1 beta for Ubuntu 14.04. Missing a Block.h which does exist in 3.0.2 :-Dennis > On 26 Jan 2017, at 05.20, Philippe Hausler wrote: > > We should run those tests with ASAN, I thought I had fixed that

[swift-dev] Using git-clang-format in the Swift compiler code base.

Before I pull in a large PR that "accidentally" reformats a bunch of code, I want to get feedback on how Swift compiler devs plan to use `clang-format`. (BTW, here's the PR https://github.com/apple/swift/pull/6922). During the code review, I ran `git clang-format` as part of being a good

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 25, 2017, at 4:22 PM, Karl Wagner wrote: > > >> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev > > wrote: >> >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into generic

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 25, 2017, at 6:13 PM, Joe Groff wrote: > >> Naturally, opaque types must limit some optimizations, such as inlining. > > I don't see how opaque types by themselves prevent inlining. You can inline a > generic into another generic, or a function using a resilient