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

functions passed to the Windows API via parameters or struct fields are often __stdcall but the default calling convention is __cdecl. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Adding a CHECK to test case.

e by looking at > other similar files: > // REQUIRES: CPU=i386 || CPU=x86_64 > // XFAIL: Linux > > But this too is not working, How do I make this test skip on ppc64le > otherwise? The simple way to disable the test on ppc64le is probably spelled like this: // UNSUPPORTED: C

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

oved enough since then that Swift could use more of CMake's built-in capabilities. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Help request for test failure "IRGen/objc_simd.sil".

somewhere on or after the "…simd_c_args_float3…" line. The expected output was not found so the test failed. You can read more about FileCheck's syntax here: https://llvm.org/docs/CommandGuide/FileCheck.html The likely problems are: 1. the ppc64le compiler is not generat

[swift-dev] Bug for FIXME(sil-serialize-all) @_inlineable cleanup?

be un-exported until the @_inlineable tide is rolled back. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Default deployment target for swiftc

There should not be any availability checks required in the common fast-prototyping case, where your SDK version and your running OS version are the same. Availability checks are required when some API has changed since the OS version that is your deployment target. In the fast-prototyping sce

Re: [swift-dev] No attribute(swiftcall) support on Linux?

> On Nov 14, 2017, at 7:52 AM, Arnold Schwaighofer > wrote: > >> On Nov 14, 2017, at 12:33 AM, Slava Pestov via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> > >>> On Nov 13, 2017, at 10:47 PM, Greg Parker via swift-dev >>> mail

[swift-dev] No attribute(swiftcall) support on Linux?

/swift/include/swift/Runtime/Metadata.h:3015:1: warning: unknown attribute 'swiftcall' ignored [-Wunknown-attributes] How bad is this? Do we not use a custom calling convention on Linux platforms today? -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> R

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

hat is _not true_. Some generic code (for instance, that which > uses `Numeric`) relies on partial equivalence semantics and some > floating-point code can nonetheless benefit from a notion of full equivalence. I agree that providing a way to get IEEE equality in a generic context is usef

Re: [swift-dev] Question: memory management on Stack with Structs ?

ON_RETAIN_NONATOMIC) > } > } > } > } > > The question is: what happens when it is a struct that conforms to this > protocol ? Nothing good. It is unsafe to use objc_setAssociatedObject() with a Swift struct. For that matter you can't use objc_syn

Re: [swift-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (master) #443

Probably Andy's https://github.com/apple/swift/pull/12420. Automatic revert didn't work, and I won't be able to revert manually for a few hours. > On Oct 17, 2017, at 2:48 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-ASAN-RA-osx [#443] > > Build URL:https://ci.swift.or

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

Missing build dependency somewhere? [7/78] Generating swiftDispatch.o, swift/Dispatch.swiftmodule, swift/Dispatch.swiftdoc FAILED: src/swiftDispatch.o src/swift/Dispatch.swiftmodule src/swift/Dispatch.swiftdoc cd /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04-lon

Re: [swift-dev] Strange Linux smoke test failures?

bout what might be going > on? Or recommendations on how to workaround the smoke test failing? https://github.com/apple/swift/pull/11311 is causing failures. I'm trying to revert it now but there's probably a conflict somewhere. -- Greg Parker gpar...

Re: [swift-dev] Test case "tuple_arguments.swift" failed when compiler is built in debug mode on x86_64

wift" is built > in release mode. > Note that the all "fixed-it"s are stored in a list, originally is added by > "DiagnosticVerifier::addDiagnostic" > > Can anyone let me know how the compiler build options affect the test results. > I tested the same case

[swift-dev] Segfaults in swift-build bootstrap on Linux?

non-zero exit status 1, aborting -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] Code that uses the is-Swift metadata bit

Swift apps. We will need to find all of these locations and change them.) -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Adding a field to StrongRefCount class

ongRefCount inline form if you only need a few bits for your storage. Or you could force StrongRefCount to always use the out-of-line form and store whatever data you want there. This would be slower but probably fine for experimentation. -- Greg Parker gpar...@apple.com <mailto:gpar

Re: [swift-dev] Metadata Representation

pad it to 64 bits by prepending a 32-bit zero, the result is not a 64-bit signed offset. Negative offsets would become large positive offsets. You would also have to adjust all code that reads these offsets. Such code must read only 32 bits and sign-extend if necessary to get 64 bits.

Re: [swift-dev] What can you change in a fixed-contents struct?

source code rearrangement. In addition, erroneous name changes are more likely to be caught downstream (for example when clients fail to build because they didn't change their use of the name), but erroneous order changes are less likely to be caught later. The goal of preventing accidental AB

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

something much larger. Don't worry about that. Starter bugs are unlikely to be a scarce resource. If too many starter bugs get fixed then we will (1) celebrate, and then (2) find some more bugs that are good starter candidates. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.c

Re: [swift-dev] statically initialized arrays

> On Jun 19, 2017, at 9:58 AM, Joe Groff wrote: > >> On Jun 15, 2017, at 8:30 PM, Greg Parker via swift-dev >> wrote: >> >> swift_once is not the most efficient solution here - we don't need separate >> once token storage in this case - but it's

Re: [swift-dev] statically initialized arrays

on't need separate once token storage in this case - but it's fine for now. If necessary we can get rid of the once token requirement in a backwards-compatible way. (You can do without a separate token if (1) your storage is two pointers or less in size, (2) your storage is suff

Re: [swift-dev] statically initialized arrays

like the linker and shared cache to find these objects for optimization purposes. (That's probably less important for arrays than it is for strings. Note that C strings have their own section for just this reason.) And if these objects are read-only when the ABI is unchanged then the s

Re: [swift-dev] Override the path to the Swift compiler?

but that is designed to substitute the entire Swift toolchain, not just the Swift compiler itself. SWIFT_EXEC might work if your wrapper script lives next to swiftc in the filesystem. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler

Re: [swift-dev] Xcode pauses when I add a toolchain

. Any thoughts for what I might try > to fix it? Can you capture a sample of Xcode (`sample Xcode`) while it is spinning? That should help tell us what Xcode is doing or waiting to do. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.co

Re: [swift-dev] Mysterious memory improvement and regression

> On Apr 24, 2017, at 8:52 PM, Pavol Vaskovic wrote: > >> On 25 Apr 2017, at 01:28, Greg Parker wrote: >> >> The value of MAX_RSS depends on OS behavior. Other activity on the same >> machine may change MAX_RSS of the benchmark. > > Can you please

Re: [swift-dev] Mysterious memory improvement and regression

u saw might not be "real". If you re-run the 2017-04-15 builds today, do you still see 3 MB instead of 10 MB? -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (master) #212

Michael, one of your changes broke all three ASAN bots. Please fix or revert ASAP. (Could this be related to https://github.com/apple/swift/pull/8169 ? I didn't confirm that the bot's change lists are correct.) > On Mar 18, 2017, at 11:48 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-

Re: [swift-dev] Statically-emitted or statically-allocated objects with new refcounting

> On Mar 17, 2017, at 4:07 PM, Joe Groff wrote: > >> On Mar 17, 2017, at 4:04 PM, Greg Parker > <mailto:gpar...@apple.com>> wrote: >> >>> On Mar 17, 2017, at 8:19 AM, Joe Groff >> <mailto:jgr...@apple.com>> wrote: >>> >>>

Re: [swift-dev] Statically-emitted or statically-allocated objects with new refcounting

> On Mar 17, 2017, at 8:19 AM, Joe Groff wrote: > > >> On Mar 16, 2017, at 9:02 PM, Greg Parker wrote: >> >>> >>> On Mar 16, 2017, at 7:35 PM, John McCall wrote: >>> >>>> On Mar 16, 2017, at 4:23 PM, Joe Groff wrote: >&g

Re: [swift-dev] Statically-emitted or statically-allocated objects with new refcounting

> On Mar 16, 2017, at 7:35 PM, John McCall wrote: > >> On Mar 16, 2017, at 4:23 PM, Joe Groff wrote: >> >>> On Mar 14, 2017, at 3:53 PM, Greg Parker via swift-dev >>> wrote: >>> >>>> On Mar 14, 2017, at 2:16 PM, John McCall wrote:

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

This was https://github.com/apple/swift/pull/8099 . I reverted it. The rest of you are off the hook. > On Mar 14, 2017, at 11:31 PM, Greg Parker via swift-dev > wrote: > > I don't know what broke here, so I'm going to revert all of these changes in > about an hour u

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

I don't know what broke here, so I'm going to revert all of these changes in about an hour unless somebody knows what is wrong. • IRGen: Consider the conforming type’s accessibility for lazy witness (detail) • [sil-generic-specializer] Provide a possibility to disable the (detai

Re: [swift-dev] Statically-emitted or statically-allocated objects with new refcounting

> On Mar 14, 2017, at 2:16 PM, John McCall wrote: > >> On Mar 14, 2017, at 5:08 PM, Jordan Rose via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >>> On Mar 14, 2017, at 13:52, Greg Parker via swift-dev >> <mailto:swift-dev@swift.org>&

Re: [swift-dev] Statically-emitted or statically-allocated objects with new refcounting

> On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev > wrote: > > >> On Mar 14, 2017, at 12:43 PM, Joe Groff > <mailto:jgr...@apple.com>> wrote: >> >> Hey Greg, what are the correct refcounting bits now to set in a global >> statically-emi

Re: [swift-dev] Statically-emitted or statically-allocated objects with new refcounting

attern is exactly. (I assume you are not in strictly read-only memory and can tolerate writes to the refcount word. We don't yet have an implementation for immortal read-only objects.) -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.c

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

Thanks, Robert. > On Mar 13, 2017, at 10:13 PM, Robert Widmann wrote: > > This one is mine and will be resolved shortly. Practical Swift and I have > been stepping on each others toes trying to introduce and fix the same > crashes. > > ~Robert Widmann > >> On Mar 14, 2017, at 1:04 AM, no-r

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

Password expired. -- scp toolchain tar -- WARNING: Your password has expired. Password change required but no TTY available. Build step 'Execute shell' marked build as failure > On Mar 13, 2017, at 7:22 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-package-linux-ubuntu-16_04 [#605] > > B

Re: [swift-dev] JIT-ting Swift

What exactly does your code that 'passes argc=1 and argv=["foo"]' look like? Did you null-terminate argv as is required? > On Mar 10, 2017, at 1:45 AM, Alex Denisov via swift-dev > wrote: > > Thank you everybody for your hints and suggestions. It helped me a lot! > I have found the source of

Re: [swift-dev] Marking a function as __attribute__((weak))

s are expensive. What are you trying to do? -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] master fails to build

ftNativeNSXXXBase.mm.o > > Is anyone else running into this? This was a hiccup after an LLVM change a few weeks ago. Try deleting your entire build directory and rebuilding. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___

Re: [swift-dev] No return functions and program exit

nups before exceptional exits is important. We don't want to increase the code size of assert() and abort(). We also don't want to introduce additional potential crash points if the program's state is broken and it is merely trying to print a helpful error message on

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

but > paying with 4 extra static instructions per class. > > It would be lame if we can't force @local.A.cache_table to be ±1MB relative > to the helper. You should assume that code and data are far apart from each other. The linker will optimize two-instruction far loads

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

Failed during package construction, I think: -- scp code sign tar -- WARNING: Your password has expired. Password change required but no TTY available. Build step 'Execute shell' marked build as failure > On Feb 2, 2017, at 6:41 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-package-linu

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

if (condition) single_line_body(); But the first rule of code style is "do as the rest of the code does", so I write my LLVM and Swift code like that. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

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

IIRC I saw something like this earlier this week, probably Tuesday, but I can't remember if it was in a CI PR build or in a local build on rad-main. > On Dec 21, 2016, at 5:35 PM, Jordan Rose via swift-dev > wrote: > > This can't possibly be me. > > Compile Swift Module 'Get' (9 sources) > V

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

Smells like a missing build dependency somewhere. > On Dec 14, 2016, at 5:40 PM, Slava Pestov via swift-dev > wrote: > > 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-in

Re: [swift-dev] Way to --clean only the Swift parts of Swift?

lvm and clang and swift. Deleting the swift directory will safely preserve llvm and clang, but not swiftc. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

f Xcode on your machine. What is the output of `xcode-select -p` and `xcodebuild -version`? If those are pointing at some other install of Xcode then you can use `xcode-select -s` to tell the command-line tools which copy of Xcode to use. You can also re-run the failing clang command by h

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

I wonder if running compiler_crashers with guard malloc set would make most of the indeterminisms go away. > On Dec 7, 2016, at 4:53 PM, Xi Ge via swift-dev wrote: > > I’ll disable it for now. > > >> On Dec 7, 2016, at 4:50 PM, Douglas Gregor > > wrote: >> >> this

Re: [swift-dev] No commit emails

FWIW most commits go through GitHub pull requests nowadays, so setting up GitHub's notifications for the apple/swift repository will keep you informed of most changes. > On Dec 1, 2016, at 11:53 AM, Kenny Leung via swift-dev > wrote: > > Hi All. > > Just a heads up. > > We got a big bolus

Re: [swift-dev] Initializing constant object graph with cycles

) > } > } The IUO is the typical pattern here. Forgetting to initialize an IUO is less of a problem than it would be in C or ObjC. Access to an IUO is checked at runtime. If you forget to initialize self.object then the process will deliberately halt the first time you try to use it. --

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

them and some do not. Allowing ABI space for tagged pointer objects is a much bigger problem than the check in swift_retain/release. For example, all vtable and witness table dispatch sites to AnyObject or any other type that might someday have a tagged pointer subclass would need to compi

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

e are any functions with those names, they do match the abstract > prototypes. Hope that all such interactions use only portable IRGen > call-lowering patterns. Or perhaps have a swiftc mode that generates a C prototype for every function marked with @_silgen_name, and use that to build an a

[swift-dev] Starter bug: SR-2875 Emit objc_allocWithZone(cls) instead of [cls allocWithZone:nil]

rBug%20AND%20assignee%20in%20(EMPTY) -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

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

ore reliable > than waiting to land them independently with the @swift-ci lag. > > - Daniel > >> On Aug 17, 2016, at 8:01 PM, Greg Parker > <mailto:gpar...@apple.com>> wrote: >> >> #4361 failed its Linux smoke test and never started its OS X test.

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

e/swift/pull/4361 > <https://github.com/apple/swift/pull/4361> > to finish testing, which it looks like is close. > > - Daniel > >> On Aug 17, 2016, at 4:54 PM, Greg Parker via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> This is about t

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

This is about to break all of the bots. When do you expect a fix? > On Aug 17, 2016, at 4:28 PM, Max Moiseev via swift-dev > wrote: > > Unfortunate but expected. Need this change in the SwiftPM in order to test > the https://github.com/apple/swift/pull/4361 >

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

atible ways in the past and reserves the right to do so in the future. Any real x86 iOS would have a real ABI which would likely differ from today's simulator. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler

Re: [swift-dev] JIRA labels (no worries)

l names would be very welcome! Inside Apple we often use the term "nominated" for "I think this should go into release X, but it's not my call". Here that suggests labels like "Swift3Nomination". -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com&g

Re: [swift-dev] How to run the tests out-of-tree?

rcing test authors to separate the device-side content. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

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

> On Apr 22, 2016, at 4:13 PM, Greg Parker wrote: > > >> On Apr 22, 2016, at 3:14 PM, no-re...@swift.org wrote: >> >> [FAILURE] oss-swift-incremental-RA-osx [#3573] >> >> Build URL: https://ci.swift.org/job/oss-swift-incremental-RA-osx/3573/ >&

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

dump -- Exit Code: 1 Command Output (stderr): -- /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swift/test/attr/attr_objc.swift:2032:14: error: unexpected note produced: candidate has non-matching type '(Int) throws -> String' @ob

Re: [swift-dev] test-repl-glibc failure

se @swift-ci please test and merge. https://bugs.swift.org/browse/SR-1109 <https://bugs.swift.org/browse/SR-1109> -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ swift-dev mailing list swift-d

[swift-dev] Starter bug: SR-1286 Incorrect memory management in PotentialArchetype::getNestedType

There are also possibly similar bugs nearby; if so a change to a safer data structure might be in order. Your job: examine the nearby code, evaluate the trade-offs, and write a fix. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swif

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 14.04 (master) #1072

> On Apr 20, 2016, at 5:14 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#1072] > > Build URL: > https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/1072/ > Project: oss-swift-package-linux-ubuntu-14_04 > Date of build:

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (master) #1059

v >> mailto:swift-dev@swift.org>> wrote: >> >> Xin and I working on a fix for the original problem. >> I think we should _disable_ this test on linux in the meantime and not >> _xfail_ it. >> >> Erik >> >> >>> On Apr

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (master) #1059

Nope, not your fault. This is a pre-existing problem. I'm not sure why the CI system thought that was a new issue. > On Apr 20, 2016, at 2:08 PM, Michael Ilseman wrote: > > > Unexpected Passing Tests (1): > Swift :: 1_stdlib/ArrayTraps.swift.gyb > > I don’t think my c

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

pr 19, 2016, at 10:05 PM, Xin Tong > <mailto:xin_t...@apple.com>> wrote: >> >> >>> On Apr 19, 2016, at 10:03 PM, Xin Tong via swift-dev >> <mailto:swift-dev@swift.org>> wrote: >>> >>> >>>> On Apr 19, 2016, at 10:00 PM

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

; On Apr 19, 2016, at 9:40 PM, Greg Parker > <mailto:gpar...@apple.com>> wrote: >> >> Thanks. I'll try that. >> >> >>> On Apr 19, 2016, at 9:35 PM, Xin Tong >> <mailto:xin_t...@apple.com>> wrote: >>> >>> I w

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

Thanks. I'll try that. > On Apr 19, 2016, at 9:35 PM, Xin Tong wrote: > > I will check in something to disable the pass. > > -Xin > > > >> On Apr 19, 2016, at 9:34 PM, Greg Parker wrote: >> >> Looks like it was caused by the RR code motion

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

n Apr 19, 2016, at 8:50 PM, Erik Eckstein wrote: > > This looks like there is some kind of non-determinism in the compilation. > >> On Apr 19, 2016, at 8:14 PM, Greg Parker wrote: >> >> >>> On Apr 19, 2016, at 12:45 PM, no-re...@swift.org wrote: >>&g

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

../../../stdlib/public/SwiftShims/RefCount.h:198: void StrongRefCount::decrementFromOneAndDeallocateNonAtomic(): Assertion `refCount == RC_ONE && "Expect a count of 1"' failed. stderr>>> CRASHED: SIGABRT the test crashed unexpectedly [ FAIL ] ArrayTraps.remove(at

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

Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o: prev MD5=e888cbc861bdeaaf786df90c4e5a40da recompiling thread 1: done thread 0: done -- Greg Parker gpar...@apple.com Runtime Wrangler __

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

Dmitri, your commit 265fa20c re-enabled tests that were previously not running, correct? > On Apr 19, 2016, at 12:15 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#4226] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubun

Re: [swift-dev] print buffering

assert(false) } Making print() less than fully buffered (either unconditionally or conditional on stdout being sufficiently terminal-like) ought to be reasonable. I mirrored the bug report to https://bugs.swift.org/browse/SR-1127 . -- Greg Parker gpar...@apple.com Runtime Wrangler __

[swift-dev] Web browser extension for SR-nnn links?

Is there a web browser extension developer in the house? I want a Safari extension that transforms SR-nnn text into links to https://bugs.swift.org/browse/SR-nnn . -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing

Re: [swift-dev] Swift kernel hacking, compiler options and target triples

> large > option list. swiftc has a hidden -Xllvm flag that passes options to the LLVM code generator. That might work for low-level options like instruction selection and maybe the red zone. It's not the right answer for production use, but it might be good enough for your exp

Re: [swift-dev] [Discussion] New refcount representation

free the side allocation > > I take it the refcount field's pointer is itself considered a weak reference, > so the weak refcount starts +1 like the unowned refcount does? You need to do something to make sure the side allocation is not freed if the object is live with no wea

Re: [swift-dev] Developing Swift in Xcode

obably a warning that is enabled by default in new Xcode projects but is not enabled in our other builds. (Starter project suggestion: pick a compiler warning, turn it on, and fix the problems.) -- Greg Parker gpar...@apple.com Runtime Wrangler

Re: [swift-dev] [Discussion] New refcount representation

> On Mar 15, 2016, at 11:59 PM, Greg Parker via swift-dev > wrote: > > I am considering a new representation for Swift refcounts and other > per-object data. This is an outline of the scheme. Comments and suggestions > welcome. > > Today, each object stores 64-bit

Re: [swift-dev] [Discussion] New refcount representation

> On Mar 16, 2016, at 2:23 PM, John McCall wrote: > >> On Mar 15, 2016, at 11:59 PM, Greg Parker via swift-dev >> wrote: >> I am considering a new representation for Swift refcounts and other >> per-object data. This is an outline of the scheme. Commen

Re: [swift-dev] [Discussion] New refcount representation

e pointer-size field becomes more plausible. Joe, did you measure the cost of a mask operation at every Swift virtual call? I can't remember. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] [Discussion] New refcount representation

// object in x0 add x1, x0, #8 1: ldxr x2, [x1] mov x3, #0x2 subs x2, x2, x3 b.mi release_slow stlxr w4, x2, [x1] cbz w4, 1b -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swi

[swift-dev] Starter bug: SR-946 Unify mutexes in the Swift runtime.

Starter bug: SR-946 Unify mutexes in the Swift runtime. https://bugs.swift.org/browse/SR-946 "The Swift runtime uses two different mutexes internally. Neither one is good. We should write a new swift::mutex or adopt some LLVM mutex that solves these problems. ..." -- Greg Parke

Re: [swift-dev] Build Error: Relocation R_X86_64_PC32

d of mine > `/tmp/binutils/2.25/usr/local/bin/ld`. > > I tried to update the PATH environment variable such that mine is before > `/usr/bin` but that doesn't seem to work. Is there an argument to send > that can force mine? Dumb answer: temporarily move /usr/bi

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

> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev > wrote: > > On ARMv7 and ARM64, the argument and return register sets are the same Nit: True on arm64. Not true on armv7; the GPR parameters are r0-r3 but GPR return is r0-r1. -- Greg Parker gpar...@apple.com Runt

Re: [swift-dev] Thread safety of weak properties

> On Dec 15, 2015, at 5:32 PM, Kevin Ballard wrote: > >> On Tue, Dec 15, 2015, at 01:38 PM, Greg Parker via swift-dev wrote: >> >> Another solution is to use a handoff lock algorithm. This is what libobjc >> does now. The lock owner stores its thread ID

Re: [swift-dev] Thread safety of weak properties

> On Dec 14, 2015, at 7:51 PM, Mike Ash wrote: > >> On Dec 14, 2015, at 3:19 PM, Greg Parker via swift-dev >> wrote: >> >>> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev >>> wrote: >>> >>>> On Dec 12, 2015, at 7:04 PM

Re: [swift-dev] Thread safety of weak properties

> On Dec 14, 2015, at 7:39 PM, Kevin Ballard wrote: > >> On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote: >> >>> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev >>> wrote: >>> >>>> On Mon, Dec 14, 2015, at 12:19 PM, Gre

Re: [swift-dev] Thread safety of weak properties

> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev > wrote: > >> On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote: >> >>> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev >>> wrote: >>> >>>> On De

Re: [swift-dev] Thread safety of weak properties

ll word of storage instead of a single bit. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Trouble minimizing test case: code completion

monstration at all. In the bug report you can describe the reductions that you tried that didn't work. That might help whoever gets it next. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Determining if a crash is a known issue?

r_crashers{,_2}/ which I assume are all existing > crashers. They are not. They are crashes collected by https://github.com/practicalswift/swift-compiler-crashes . Some were discovered by users, most were discovered by automated fuzzers, and there are often duplicates among them. --

Re: [swift-dev] Optional to String conversion

ng "Optional" belongs in the textual representation. There are unfortunate output ambiguities if you don't include it. Consider the output of all of these: print(String?("test")) print(String?("nil")) print(String?.None) The current

Re: [swift-dev] Develop apps with swift 2 on ubuntu 14.04 LTS x86_32 bit

Linux should be easier than adding a brand new OS or architecture would be. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev