Re: [swift-dev] Problems caused by "is"

Hi Jacob, Maybe it would be better to figure out why getMemberSubstitutions() is being called on the invalid type, and try to catch the problem further up? Otherwise, Doug Gregor might have further suggestions. Slava > On Dec 5, 2015, at 11:41 PM, Jacob Bandes-Storch via swift-dev > wrote: >

Re: [swift-dev] Starter project: Remove old mirrors

Hi Jean-Pierre, > On Dec 7, 2015, at 12:21 PM, Jean-Pierre Simard via swift-dev > wrote: > > > Note that I'm already working on this part. The Swift runtime needs to > > provide low-level reflection interfaces that allow the standard library to > > implement Mirror without depending on priva

Re: [swift-dev] Location of "indirect" declaration modifier

Hi Marc, > On Dec 11, 2015, at 3:06 AM, Marc Knaup via swift-dev > wrote: > > Hey guys, > > I'm working on a proposal and the question arose why the declaration modifier > indirect can only be specified for the whole enum case and the whole enum but > not for the a

Re: [swift-dev] Proof-of-concept port of Swift for Android

> On Dec 11, 2015, at 4:33 AM, Geordie Jay via swift-dev > wrote: > > Hi, maybe one of the Apple devs can help out with this quick Q: > > To interface with the JNI, we’d presumably need to call swift functions from > our compiled swift binaries from C (or directly from Java, the result being

Re: [swift-dev] Location of "indirect" declaration modifier

> On Dec 11, 2015, at 8:01 AM, Marc Knaup wrote: > > Thank you for your thorough answer. > > So when direct and indirect cases already look the same for the type system > then why is there the indirect modifier in the first place? > Couldn't the compiler just automatically box variables which

Re: [swift-dev] Value-result ABI for small trivial inouts

> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev > wrote: > > We currently always pass inout parameters indirectly, but it seems to me that > for inout parameters that are of small trivial types like Int or CGSize, a > value-result calling convention might always be preferable, and we m

Re: [swift-dev] metatype of Int

You can probably get the mangled name of the metatype, and refer to that. Eg, public func f() -> Any.Type { return Int.self } f() Compile this with -emit-ir: @_TMSi = external global %swift.type, align 8 define %swift.type* @_TF4blah1fFT_PMP_() #0 { entry: ret %swift.type* @_TMSi } So in

Re: [swift-dev] Making sense of Swift AST - pattern_binding_decl and var_decl

I'm still learning, but I think its just the distinction between introducing the name and performing the name binding. Consider this example, let (x, y) = (1, 2) This parses into one PatternBindingDecl and two VarDecls. Slava > On Dec 18, 2015, at 8:08 AM, Lee M via swift-dev wrote: > > With

Re: [swift-dev] Understanding runtime entry points

Hi Austin, > On Jan 1, 2016, at 10:58 PM, Austin Zheng via swift-dev > wrote: > > Hello, > > I'm trying to better understand how calls are made between the Swift standard > library code and the runtime entry points. I've read through most of the > documentation in the repo but still have som

Re: [swift-dev] Understanding runtime entry points

> On Jan 6, 2016, at 12:57 PM, Austin Zheng wrote: > > Hey Slava, > > Thanks a lot for your detailed responses; it definitely helps to understand > how structs are passed to the C++ function. > > In a separate email, Joe Groff mentioned that there was a difference between > passing the enum

Re: [swift-dev] Problem in parsing SIL

Hi Mikio, Try this: swiftc -frontend -emit-silgen classdecl.swift > classdecl.sil swiftc -parse-sil classdecl.sil I'm not sure why -emit-silgen sometimes emits type declarations and other times not. The only difference I can see is what without the -frontend flag, the driver passes in -primary

Re: [swift-dev] Swift merge commits no diff

Hi Vassil, Since a merge commit has two parents you might potentially want to diff against, I'm assuming the tool is not smart enough to know which one is the PR and which one is trunk. Perhaps this is not too hard to fix with some kind of heuristic though. Slava > On Jun 21, 2016, at 2:49 PM

Re: [swift-dev] Requiring blocks (universally)

> On Jun 24, 2016, at 11:23 AM, Joe Groff via swift-dev > wrote: > > >> On Jun 24, 2016, at 11:05 AM, Saleem Abdulrasool via swift-dev >> wrote: >> >> Hi, >> >> The blocks runtime itself is pretty tiny, and works across various targets >> already, so including it is not too onerous. As s

Re: [swift-dev] Type inference of functions with more than one statement

Hi Ross, Swift's type inference operates at the level of a single statement. This is why we can infer parameter and return types for single-expression closures. While conceptually, it would not be a huge change to the type checker algorithm to support global type inference for closures and othe

Re: [swift-dev] Type inference of functions with more than one statement

Hi Ross, That's a good point. Do you mind filing a JIRA issue for this? Slava > On Jul 8, 2016, at 11:56 AM, Ross LeBeau wrote: > > Hi Slava, > > Thanks for the insight. This is what I suspected, but I wasn't sure about how > set the team was on this concept. Currently, it seems that if the

Re: [swift-dev] End of source-breaking changes for Swift 3

> On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev > wrote: > > > SE-0092 - Typealiases in protocols and protocol extensions > > SE-0102 - Remove @noreturn attribute and introduce an empt

Re: [swift-dev] Question about size of Character type

> On Aug 19, 2016, at 2:04 PM, Jordan Rose via swift-dev > wrote: > > We have an old Radar about this, rdar://problem/16754935 > . It's probably just a case we're missing in enum > layout. My guess is that it's because we don't have a whole spare bit in a > RawPointer, but we should be able

Re: [swift-dev] Reflection: typeref_lowering test case on Linuxone

You’ll notice the existing CHECK-64’s already have stuff like > // CHECK-64-NEXT: (struct size=72 alignment=8 stride=72 > num_extra_inhabitants=[[PTR_XI:2048|2147483647]] To deal with Linux vs Darwin. You could just fold all the different possible values into the alternation there, instead of h

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

This error is caused by stale build artifacts: /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation: symbol lookup error: /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/

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

upon the dependency graph for swift; > perhaps we should just be recompiling everything every single time for > libFoundation.so. It seems like a waste of CPU cycles but I don’t really see > any way around it. > >> On Sep 6, 2016, at 2:41 PM, Slava Pestov via swift-dev &g

[swift-dev] Flaky test - objc_nonnull_lie_hack

Hi all, Is anyone else seeing this? I haven’t seen it in CI, but for me this test fails at random, very rarely too — looks like something is non-deterministic in the optimizer? /Users/slava/new/swift/test/SILGen/objc_nonnull_lie_hack.swift:30:9: error: expected string not found in input // OPT

Re: [swift-dev] Flaky test - objc_nonnull_lie_hack

Running it in a loop on another machine doesn’t trigger it, so I’m thinking it might be a random variation in how the standard library is built? > On Sep 9, 2016, at 2:49 PM, Mark Lacey wrote: > > >> On Sep 9, 2016, at 2:45 PM, Slava Pestov via swift-dev > <mailto:swift-

Re: [swift-dev] Flaky test - objc_nonnull_lie_hack

ttps://github.com/apple/swift/pull/4622 > <https://github.com/apple/swift/pull/4622> > > Jordan > > >> On Sep 9, 2016, at 14:50, Slava Pestov via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Running it in a loop on another machine doe

Re: [swift-dev] SIL to IR lowering

> On Sep 9, 2016, at 9:27 AM, Douglas Gregor via swift-dev > wrote: > > >> On Sep 8, 2016, at 1:17 PM, Rebecca Chen via swift-dev >> wrote: >> >> I was wondering where the SIL to IR lowering code is in the Swift source >> code. > > That’s the responsibility of IRGen: > > https://g

Re: [swift-dev] Xcode 8 GM: Compiler segfaults on ExpressibleByArrayLiteral

This bug was fixed in the following commit: https://github.com/apple/swift/commit/75bd88968bcb0e77bc0a9d6d6191c5ab362d2736 The JIRA bug is https://bugs.swift.org/browse/SR-488>. Slava > On Sep 8, 2016, at 11:42 AM, Ole Begemann via swift-dev > wrote: > >> FWIW, it’s actually fixed in master

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

Fixed with an lldb patch: https://github.com/apple/swift-lldb/commit/17e76c3d4df10f109bca92c3095e388a9f39a7ce > On Sep 14, 2016, at 4:53 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#2099] > > Build URL: > https://ci.swift.org/job/oss-swift-package-linux

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

This is a random one-off failure. Also my PR for the swift-3.0-branch hit a set of segfaults in the Dictionary tests, but this time in the iphone simulator tests: https://ci.swift.org/job/swift-PR-osx/3639/consoleFull#-1473877083fca400bf-2f4a-462e-b517-e058d770b2d7 The only relevant patch commo

Re: [swift-dev] Purpose of validation-test/Reflection/reflect_*.swift

The tests are there to ensure the reflection output doesn’t accidentally break or change. However if you’re updating the layout of those types you need to update the tests. Slava > On Oct 26, 2016, at 5:41 PM, Michael Gottesman via swift-dev > wrote: > > >> On Oct 26, 2016, at 5:29 PM, Alex

Re: [swift-dev] Inability to leverage privacy in the stdlib

> On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev > wrote: > > >> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev >> wrote: >> >> Dave pointed out to me this week that the build crashes if the stdlib tries >> to use private/fileprivate. I tried it myself and lo a

Re: [swift-dev] Inability to leverage privacy in the stdlib

It will become the default, but not yet, so yeah, you shouldn’t merge anything that only builds with this flag set. Can you share the patch that adds private modifiers along with the linker errors you are seeing? Now would be a good time to sort out these issues. > On Oct 28, 2016, at 4:16 PM,

Re: [swift-dev] Inability to leverage privacy in the stdlib

The problem is if a private type or function X is referenced from a function Y with a serialized body, then if Y is inlined inside of another module, it cannot see the symbol for X. The solution is to disable -sil-seiralize-all and replace it with an explicit ‘fragile’ attribute that is put on c

Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

> On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev > wrote: > > - Does this help us with the nested dictionary CoW problem? > `foo["bar"]["baz"] += 1` My understanding is that this problem arises because we don’t have ‘optional addressors’. A dictionary lookup might return nil. If addr

Re: [swift-dev] Casting shadow protocols

If the casts are always in one direction, can you make one protocol refine another? Also note that @objc protocols are self-conforming as long as they don’t contain initializers or static methods, but I’m not sure if that helps. > On Nov 4, 2016, at 4:29 PM, Alexis via swift-dev wrote: > > Th

Re: [swift-dev] Magic Metadata Symbol In Stubs

> On Nov 17, 2016, at 12:36 PM, Alexis via swift-dev > wrote: > > I’m currently looking at pushing the storage of the empty Dictionary > singleton into rodata, using Array as a reference. Most things are pretty > straightforward, except the symbol for the metadata for _EmptyArrayStorage > th

Re: [swift-dev] Linux full-test CI broken?

I think this was caused by my generics refactoring. Looks like Graydon reverted it already. Sorry for the inconvenience y’all! Slava > On Nov 22, 2016, at 12:46 PM, Graydon Hoare via swift-dev > wrote: > > Yes, that configuration has been failing LLDB tests for a few days; it's > being looke

Re: [swift-dev] High-level SIL Optimization: How do I get a FuncRef from the stdlib?

> On Nov 27, 2016, at 6:12 PM, Ben Ng wrote: > > I managed to create the substitution, and the generated SIL looks right, but > I’m failing verification: > > SIL verification failed: substituted callee type should not be generic: > !site.getSubstCalleeType()->isPolymorphic() > Verifying instr

Re: [swift-dev] High-level SIL Optimization: How do I get a FuncRef from the stdlib?

One more thing: > > auto subTy = V->getType(); This is a SILType. > auto &ValLowering = Builder.getModule().getTypeLowering(subTy); > auto copiedVal = ValLowering.emitCopyValue(Builder, SemanticsCall->getLoc(), > V); > auto allocStackInst = Builder.createAllocStack(SemanticsCall->getLoc(), >

Re: [swift-dev] [Pitch] Remove "Default will never be executed" Warning?

> On Nov 26, 2016, at 3:25 PM, Robert Widmann via swift-dev > wrote: > > Hello all, > > I’ve seen and been a part of a number of conversations recently where talk of > planning for “resilient enums”, or even just authors that ship frameworks > that will eventually offer a binary option that

Re: [swift-dev] [Pitch] Remove "Default will never be executed" Warning?

> On Nov 27, 2016, at 4:32 PM, David Sweeris via swift-dev > wrote: > >> >> On Nov 26, 2016, at 5:25 PM, Robert Widmann via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Hello all, >> >> I’ve seen and been a part of a number of conversations recently where talk >> of planning for

Re: [swift-dev] High-level SIL Optimization: How do I get a FuncRef from the stdlib?

Hi Ben, > On Nov 29, 2016, at 12:10 AM, Ben Ng wrote: > > Hi Slava, > > The use of the unsubstituted function type turned out to be the issue. The > verifier was satisfied after I fixed that, and my proof of concept worked. Great to hear! > > For context, I'm working on an addition to the A

Re: [swift-dev] High-level SIL Optimization: How do I get a FuncRef from the stdlib?

What is the generic signature of the method you’re generating the call to? if it’s always something like func foo(a: Array) ie, single generic parameter, without any constraints, then you can manually create a single-element substitution list with no conformances. Slava > On Nov 29, 2016, at

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

Maybe it’s a flaky test? We’ve had a few of those lately. Mark is working on a systemic fix for the issue they keep exposing. > On Dec 6, 2016, at 12:56 PM, Xi Ge via swift-dev wrote: > > The newly added crash is fixed. I’ll update the validation test suite. > > >> On Dec 6, 2016, at 12:54 PM

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

Looks like a non-deterministic failure. Could be the same root cause as https://ci.swift.org//job/oss-swift-incremental-RA-osx/7570/consoleFull#577085863ee1a197b-acac-4b17-83cf-a53b95139a76

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

Does anyone know what happened here? It doesn’t look like any of the patches in the blame log could have caused this: /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swift/stdlib/public/SDK/XPC/XPC.swift:14:8: error: no such module '_SwiftXPCOverlayShims' import _SwiftXPCOverlayS

Re: [swift-dev] Including the requirement, but not the SILFunction in default witness tables

That’s a good idea. Default witness tables are still not 100% done and need some work. I’ll be sure to revisit the printing part too. Slava > On Dec 17, 2016, at 9:52 PM, Michael Gottesman wrote: > > Hey Slava. > > I just noticed that when we print out the SIL for default witness tables: > >

Re: [swift-dev] SubstitutionMap questions

Hi Jacob, > On Dec 30, 2016, at 12:14 PM, Jacob Bandes-Storch wrote: > > Happy holidays :-) > > I started looking at this bug to see if I could figure out how to fix it: > https://bugs.swift.org/browse/SR-3500 > > As the bug author points out, there is

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

This is an intermittent failure. I’ve seen it before. Slava > On Jan 3, 2017, at 4:59 PM, mishal_shah via swift-dev > wrote: > > SwiftPM test failure: > > Test Case 'PackageToolTests.testPackageEditAndUnedit' started at 18:55:30.116 > > <>/home/buildnode/jenkins/workspace/oss-swift-increme

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

A quick scan through the list of merged patches suggests this might not be related to any of these — does anyone have any ideas? python: /home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-16_04/llvm/include/llvm/Support/Casting.h:95: static bool llvm::isa_impl_cl::doit(const From *)

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

Non-determinism in swiftpm test, unrelated to my changes: /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swiftpm/Tests/CommandsTests/PackageToolTests.swift:195: error: PackageToolTests.testPackageEditAndUnedit : XCTAssertEqual failed: ("5 ") is not equal to ("88 “)

[swift-dev] Anonymous closure arguments vs varargs

Hi all, In Swift 3.0, the following examples both typecheck: let fn1: ([Int]) -> () = { let _: [Int] = $0 } let fn2: (Int...) -> () = { let _: [Int] = $0 } This stopped working due to a regression in master so I'm looking at fixing it. While investigating this, I noticed that this variant

Re: [swift-dev] Anonymous closure arguments vs varargs

> On Jan 5, 2017, at 1:05 AM, Tino Heth <2...@gmx.de> wrote: > > Hi there, > >> I think it would be better if we permitted an implicit conversion between >> (T…) -> () and ([T]) -> () > There has been a proposal to replace the "…" with a "variadic"-annotation (on > arrays, or even on all types

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

Assertion failed: (hasVal), function getValue, file /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/llvm/include/llvm/ADT/Optional.h, line 122. This has been failing on and off all day… has anyone tried reproducing it locally? Slava > On Jan 8, 2017, at 11:11 PM, no-re...@swif

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

I went ahead and changed REQUIRES: OS=linux-gnu to REQUIRES: deterministic-behavior in the remaining crashers that had this annotation. > On Jan 11, 2017, at 10:34 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#1308] > > Build URL: > https://ci.swi

Re: [swift-dev] How to test -assume-single-threaded option?

Hi Jiho, Some low-level frontend flags are not exposed to the driver. To pass frontend flags directly via the driver, use -Xfrontend, eg swiftc -Xfrontend -assume-single-threaded mytest.swift This is different from -frontend — -frontend skips the driver entirely, -Xfrontend runs the driver but

Re: [swift-dev] How to test -assume-single-threaded option?

> correct one—to check for a difference of behavior in the Swift compiler > itself—but please do not use these in production code. > > Jordan This is swift-dev, not swift-users, so I’m assuming anything goes, even questions about SIL syntax :) > > >> On Jan 13, 201

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.04 (swift 3.1) #148

Looks like this PR needs to go into 3.1 branch: https://github.com/apple/swift-corelibs-foundation/pull/772/files Philippe, do you cherry picking it over? Slava > On Jan 17, 2017, at 5:20 PM, Joe Groff wrote: > > Sorry, I may have cc'ed you on the wrong build failure. This one: > > https://c

Re: [swift-dev] problem with compiler_crashers/28616-swift-parser-parseexprsequence-swift-diag-bool-bool.swift

I think this is fine. We have a bunch of compiler_crashers which are non-deterministic because they trigger undefined behavior at runtime, such as dangling pointers, stack overflow, etc. Disabling this is OK for now (it is still in compiler_crashers/ so it is understood it is not yet fixed). I

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

Old compiler bug. Doug, it’s baack! > On Jan 30, 2017, at 1:26 PM, Michael Ilseman via swift-dev > wrote: > > Any recent changes to this code area, or new compiler bug? > > Compile Swift Module 'PackageGraph' (4 sources) > Compile Swift Module 'Get' (9 sources) > Link Get > Valid

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

I saw one of these before Joe’s change went in. It might be more non-determinism with archetypes... > On Jan 30, 2017, at 3:11 PM, Michael Ilseman via swift-dev > wrote: > > Joe, could this be due to your changes? > > Assertion failed: ((inContext->isEqual(repInContext) || inContext->hasError

Re: [swift-dev] Change of requirements to build swift?

I think it should still build with 10.11, however you need Xcode 8.3 beta 1 now. Slava > On Feb 1, 2017, at 2:48 PM, Guillaume Lessard via swift-dev > wrote: > > Hello, > > Is master supposed to have dropped support for building on 10.11.x? > The previous snapshot I’d built was January 24th,

Re: [swift-dev] ArchetypeBuilder rename

Do you mind if I merge https://github.com/apple/swift/pull/7319 first? It’s ready to go in. Slava > On Feb 7, 2017, at 4:59 PM, Douglas Gregor via swift-dev > wrote: > > Hi all, > > The ArchetypeBuilder >

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev > wrote: > > I just learned about CaptureListExpr when working on some diagnostics. Is > there a particular reason that its member "closureBody" is an Expr* and not a > ClosureExpr*? There seems to be only one place it's built >

Re: [swift-dev] ArchetypeBuilder rename

It’s merged. Rename all you want, see if I care!!! > On Feb 7, 2017, at 7:46 PM, Douglas Gregor wrote: > > Go for it! I haven't even created the renaming PR and don't want to step on > toes. > > Sent from my iPhone > > On Feb 7, 2017, at 7:13 PM, Slava Pestov > wro

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch wrote: > > PR'd: https://github.com/apple/swift/pull/7326 > > > Although I would also ask: why is CaptureListExpr a parent of ClosureExpr and > not a child? I think it’s kind of arbitrary. You could

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 7, 2017, at 9:18 PM, Jacob Bandes-Storch wrote: > > I don't think it would be a very big parser change to invert the > relationship. Maybe I'll try it out and put up another PR. Unless you think there’s something to be gained, I’m not sure it’s worth it… > > On the other hand, notic

Re: [swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

> On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch wrote: > > Thanks to the magic of git blame: > > > https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b > > > > > > Unless you thin

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

I’ve seen this before. It would be useful if we kept all old CI logs in an easily searchable form. Slava > On Feb 13, 2017, at 1:28 PM, Jordan Rose via swift-dev > wrote: > > clang-4.0: error: unable to execute command: Bus error > clang-4.0: error: linker command failed due to signal (use -v

Re: [swift-dev] Profiling ARC

> On Feb 16, 2017, at 6:48 PM, Jiho Choi via swift-dev > wrote: > > Hi, > > I was curious about the overhead of ARC and started profiling some benchmarks > found in the Computer Language Benchmark Game > (http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift >

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

This needs someone to clean the workspace. > On Feb 20, 2017, at 9:30 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2035] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2035/ >

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

I thought this was my changes but then it cleared up on the next build. Xi, I filed rdar://31234811 with some information. Since you’re the build czar can you keep an eye on this bot and see if this test fails again? Slava > On Mar 23, 2017, at 8:32 PM, no-re...@swift.org wrote: > > [FAILURE

[swift-dev] PR test failing with clang compile error

Hi all, I’m hitting this in github PR testing: /Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/swift/lib/ClangImporter/ImportDecl.cpp:994:34: error: no matching constructor for initialization of 'clang::BinaryOperator' auto cSetterExpr = new (Ctx) clang::BinaryOpera

Re: [swift-dev] PR test failing with clang compile error

il > <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>) > Another attempt to fix the sphinx warning from r299470 (detail > <https://ci.swift.org/job/oss-swift-incremental-RA-osx/9254/changes#detail>) > > Thanks, > Mishal Shah >> On Apr 6, 2

Re: [swift-dev] Unexpected Expr type

Here’s what the AST looks like in this case — there is a ParenExpr but it’s inside a LoadExpr — we’re semantically loading the largest sub-expression that’s an lvalue, which here is ‘(x)’ not ‘x’: (assign_expr (declref_expr type='@lvalue Int' accessKind=write location=x.swift:3:1

Re: [swift-dev] Compiler crash when optimisation enabled

There’s a chance this might already be fixed — https://github.com/apple/swift/pull/8588 . Do you mind trying a 4.0 snapshot when it rolls around (probably tomorrow)? Slava > On Apr 7, 2017, at 8:32 AM, Mark Woollard via swift-dev > wrote: > > https:

Re: [swift-dev] Compiler crash when optimisation enabled

tps://github.com/apple/swift/commit/2307145c0ef7daaefe4fe0ac20fedb17f0b22730> Slava > On Apr 7, 2017, at 7:55 PM, Slava Pestov via swift-dev > wrote: > > There’s a chance this might already be fixed — > https://github.com/apple/swift/pull/8588 > <https://github.com/apple/sw

Re: [swift-dev] IRGen variadic function declaration

Please don’t use @_silgen_name. Soon it will only be available within the standard library. Instead, write C wrappers around your intrinsics and create a Clang module that you can import from Swift. If you define the wrappers as static inline functions in a header file there won’t be any runtim

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

This could be a regression from https://github.com/apple/swift/pull/8770 . I’ll take a look. > On Apr 14, 2017, at 9:08 PM, Andrew Trick via swift-dev > wrote: > > > runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED > > This is unr

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

This is most definitely not your fault, because it is my fault, from the subclass existential runtime changes. I first saw the failure a few days ago but it slipped my mind. Will look at it now. Slava > On Apr 18, 2017, at 6:01 PM, Jordan Rose via swift-dev > wrote: > >

[swift-dev] IRGen's swift_rt_* functions

Hi all, Now that we’re using swiftcc, does IRGen still need to emit the swift_rt_* wrappers around runtime calls? They look like no-ops at this point since the runtime entry points themselves should be swiftcc with the callee save variant? Slava ___ s

[swift-dev] Miscompile with protocol compositions

Hi all, I’ve spent most of the last two days debugging various issues with property and subscript accesses on class-constrained existentials and I’ve just now realized the root cause is a much more fundamental issue. Consider the following code: protocol P { var x: Int { get set } init()

Re: [swift-dev] Miscompile with protocol compositions

Q : class, P {} extension P { mutating func foo() { bar() } } class C : Q { let x: Int = 100 func bar() { print(x) // crash here } } func takesQ(q: Q) { var qq = q qq.foo() } takesQ(q: C()) > On Apr 27, 2017, at 12:35 AM, Slava Pestov via swift-dev > wrote: >

Re: [swift-dev] PR review process

Hi Pavol, Bug us mercilessly if you need something reviewed. Slava > On May 4, 2017, at 9:26 AM, Pavol Vaskovic via swift-dev > wrote: > > Hello! > > What is the process for getting a PR reviewed and merged into Swift? My > experience so far is inconsistent. Sometimes I get a response in a

Re: [swift-dev] PR review process

y 4, 2017, at 2:40 PM, Slava Pestov via swift-dev > wrote: > > Hi Pavol, > > Bug us mercilessly if you need something reviewed. > > Slava > >> On May 4, 2017, at 9:26 AM, Pavol Vaskovic via swift-dev >> wrote: >> >> Hello! >> >> Wh

Re: [swift-dev] CI failure: .../TestFoundation: undefined symbol: _T0ScN

It’s an incremental build issue. The bots don’t always rebuild Foundation, or something. I think we need to clean the workspace out. Slava > On May 13, 2017, at 12:13 AM, Boris Buegling via swift-dev > wrote: > > Hi everyone, > > I am seeing a CI failure on llbuild for seemingly unrelated re

Re: [swift-dev] Pathway to becoming an effective contributor

> On Jun 21, 2017, at 2:12 PM, Natthan Leong via swift-dev > wrote: > > Hi, > > As someone who also recently started contributing, I was surprised to discover > how much computing power was needed to build Swift. My first few build > attempts > on a mid-2014 rMBP took more than an hour with 1

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

FWIW I filed rdar://33276769 to track the issue internally. > On Jul 12, 2017, at 3:44 PM, Pavel Yaskevich wrote: > > Log says: > > /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/swift/utils/build-script-impl: > line 262: 27497 Segmentation fault "$@" > /home

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

Hi David, I reverted your PR because it appears to have broken the build: https://github.com/apple/swift-corelibs-libdispatch/pull/278 Please take a look when you get a chance. Slava > On Jul 13, 2017, at 9:02 PM, no-re...@swift.o

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

> On Jul 29, 2017, at 12:53 PM, John McCall via swift-dev > wrote: > >> On Jul 29, 2017, at 12:48 AM, Andrew Trick > > wrote: >>> On Jul 28, 2017, at 8:13 PM, John McCall >> > wrote: On Jul 28, 2017, at 11:11 PM, John McCall via swift-dev

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

> On Jul 28, 2017, at 4:07 PM, Jordan Rose via swift-dev > wrote: > > My point is we can't use our usual mangling in the string, because that > contains type names. > We could invent a ‘mangling’ format (either using the existing demangler with a special flag or something else) where types

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

> On Jul 30, 2017, at 5:47 PM, John McCall wrote: > >> On Jul 29, 2017, at 7:35 PM, Slava Pestov > > wrote: >>> On Jul 29, 2017, at 12:53 PM, John McCall via swift-dev >>> mailto:swift-dev@swift.org>> wrote: On Jul 29, 2017, at 12:48 AM, Andrew Trick >>>

Re: [swift-dev] 107 lines of "dead" code in ConstraintSystem::performMemberLookup?

> On Aug 8, 2017, at 3:34 PM, David Zarzycki via swift-dev > wrote: > > In ConstraintSystem::performMemberLookup(), constructors with “simple” names > have a dedicated lookup path. In contrast, constructors with compound names > are handled by the normal lookup. If I delete this code and let

Re: [swift-dev] 107 lines of "dead" code in ConstraintSystem::performMemberLookup?

I see you’re two steps ahead of me already: https://github.com/apple/swift/pull/11397 This looks good, nice catch! Slava > On Aug 8, 2017, at 8:45 PM, Slava Pestov wrote: > > >> On Aug 8, 2017, at 3:34 PM, David Zarzycki via swift-dev >> wrote:

Re: [swift-dev] switches versus the visitor pattern?

I’ve seen some switches over TypeKind more easily expressed as a series of if/else if statements also. However unless you come across an ugly switch that you want to refactor while working on something else, I probably wouldn’t spend time actively seeking them out and changing them. I don’t thi

Re: [swift-dev] Is swift.org/contributing/ stale?

I think it’s still up to date. You need commit access to trigger CI, and to merge PRs. Otherwise you’ll have to ask someone with commit access to do that for you. Slava > On Aug 14, 2017, at 1:14 PM, David Zarzycki via swift-dev > wrote: > > On the swift.org/contributing/ web page, under “Co

Re: [swift-dev] Portable stdlib

> On Aug 14, 2017, at 9:44 AM, Andy Best via swift-dev > wrote: > > Hey, > > I'm currently looking at building a portable version of the standard library > (for targeting microcontrollers, kernel dev, etc). I’m a bit confused about your terminology. By “portable” do you mean no dependencies

Re: [swift-dev] Build Failure with Xcode 9.0 beta 5

> On Aug 16, 2017, at 6:21 PM, David Sweeris via swift-dev > wrote: > > Does it hurt anything to have both betas installed? I'm in the process of > installing the 4th beta now. Once that's done, I'm going to build the Xcode > project. I'd like to reinstall beta 5 after that, but not if that'l

Re: [swift-dev] swift module format

Yeah, it’s important to keep in mind we don’t have a stable module format right now, so anything developed Swift 4 will likely need to be revised again with the next version. The C++ API is not stable either, but approach could be to dump the ‘generated interface’ using swift-ide-tool or simila

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

I think this is a transient failure because my patch changed ABI — can someone clean the workspace? > On Aug 24, 2017, at 6:17 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#254] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-li

Re: [swift-dev] swift module format

> On Aug 24, 2017, at 10:56 PM, John McCall via swift-dev > wrote: > > Or if you really want to avoid the FFI, you could take our current ASTDumper > output, which is currently pseudo-machine-readable, and make it actually > machine-readable. The elegant approach there would be to take the e

Re: [swift-dev] Making a protocol's associated type concrete via inheritance

This is not supported right now but it is within the realm of possibility of things that we can support. The restriction on using protocols as types is artificial — it was put in place to avoid confusing users. So it is a matter of tweaking the logic which diagnosed unsupported protocol types t

  1   2   >