[swift-dev] Namespacing Compiler-Stdlib Interfaces

Triaging old radars, I came across rdar://27268632 from Dmitri. The gist of it is that he was proposing grouping up all the random global functions that are implicitly called by the compiler under a “namespace” by making them static methods of an enum called _Intrinsic. (This name is kind’ve c

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

I find that build-script tends to get corrupted state very easily, forcing me to do a —clean build. This is usually because of git, but seemingly from benign things like checking out HEAD~1. Since I’m working on the stdlib, the corruption often shows up in there, so —clean is needlessly heavy-ha

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

> On Nov 30, 2016, at 5:02 PM, Jordan Rose via swift-dev > wrote: > >> >> On Nov 27, 2016, at 16:32, 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

Re: [swift-dev] Questions about ARC

> On Nov 30, 2016, at 12:41 PM, John McCall via swift-dev > wrote: > > When we say that we don't have a concurrency model, we mean that (1) we > aren't providing a more complete language solution than the options available > to C programmers and (2) like C pre-C11/C++11, we have not yet forma

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

I wouldn’t recommend this in general. This will just make resiliently linked programs incredibly unstable. There’s often something better that can be done, but it requires thinking about your particular case and the particular enum. * ignore what you don’t understand (or care about) * map it to

[swift-dev] Magic Metadata Symbol In Stubs

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 that’s hardcoded in GlobalObjects.cpp: extern "C" ClassMetadata _TMCs18_Empt

[swift-dev] Type Pun in Test Suite

Just stumbled across this mock NSDictionary implementation in the test suite: https://github.com/apple/swift/blob/a1dbe066adf826b27dd8e71234ba7e8ce2b26b73/validation-test/stdlib/Dictionary.swift#L1260-L1306

Re: [swift-dev] [Swift CI] Build Still Failing: 1. OSS - Swift (Tools Opt+Assert, Stdlib Opt+DebInfo+Assert, Resilience) - macOS (master) #11

About 400 tests instantly crashing. I can reproduce that locally. This is however an improvement over the rest of the week, where the stdlib didn’t even get past SIL validation. I can’t see any obvious connection to Dictionary, so it might be something else that slipped in while this was untest

Re: [swift-dev] Casting shadow protocols

> On Nov 8, 2016, at 6:22 PM, Andrew Trick wrote: > > >> On Nov 7, 2016, at 12:15 PM, Alexis via swift-dev >> wrote: >> >> Does _unsafeReferenceCast at least verify that the types in question could >> theoretically be cast into each other? That is, o

Re: [swift-dev] Casting shadow protocols

or static methods, but I’m not sure if that >>>> helps. >>> >>> Doesn't; we're not using these in a generic context; they're just >>> existentials. >>> >>>> >>>> >>>>> On Nov 4, 2016, at 4:29

Re: [swift-dev] Casting shadow protocols

t sure if that >> helps. > > Doesn't; we're not using these in a generic context; they're just > existentials. > >> >> >>> On Nov 4, 2016, at 4:29 PM, Alexis via swift-dev >>> wrote: >>> >>> The swift standard libr

[swift-dev] Casting shadow protocols

The swift standard library has this nasty little pattern/problem in it: The types in the core library want to know about several types defined in foundation: NSString, NSArray, NSDictionary, etc. But core is imported by Foundation, so it can’t (circular references between modules). Thankfully,

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

gessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/SwiftOnoneSupport/macosx/x86_64/SwiftOnoneSupport.o ninja: build stopped: subcommand failed. utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting > On Nov 1, 2016, at 12

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

I made a PR with some basic privacy usage for Array, and everything seems to be working on OSX, but not Linux. https://github.com/apple/swift/pull/5573 Exit Code: 1 Command Output (stderr): -- /usr/bin/ld.gold: error: /home/buildnode/jenkins/workspa

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

> On Oct 29, 2016, at 12:13 AM, Slava Pestov wrote: > > 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 g

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

I’m not clear on what the reflection tests are attempting to actually verify. Just that we don’t change the internal layout of these types accidentally? We’re churning up the layouts of a lot of the collections to get things all set up for ABI stability, which means mechanically updating these t

Re: [swift-dev] PR Tests Failing

This was fixed by https://github.com/apple/swift/pull/5372 Thanks Doug! > On Oct 19, 2016, at 5:39 PM, Michael Gottesman via swift-dev > wrote: > > My PR test is failing due to something unrelated: > > https://ci.swift.org/job/swift-PR-osx-smoke-tes

Re: [swift-dev] builtin command for invoking a subset of the tests

ser to what you want, in > swift/utils/run-test. It could probably use some additional love and > attention to be a bit more usable (for example, printing out the help if you > invoke it with no arguments), but I use it all the time. > > - Tony > > >> On Oct 14, 2016, a

[swift-dev] builtin command for invoking a subset of the tests

When fixing tests, it’s often useful to be able to run some subset of them, usually based on some pattern. From my searching, the recommended way to do this seems to be to directly invoke `lit.py`. Doing this by hand is tedious, so I use the following script: #!/bin/bash ../llvm/

Re: [swift-dev] Dictionary Collision Resolution Guarantees

> On Oct 13, 2016, at 6:09 PM, Dave Abrahams via swift-dev > wrote: > > > on Thu Oct 13 2016, Alexis > wrote: > >> I’m currently cleaning up the docs on Dictionary to reflect the new indexing >> model, and I stumbled >> across the note that the following code

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

> On Oct 13, 2016, at 5:14 PM, Joe Groff wrote: > > >> On Oct 13, 2016, at 2:04 PM, Alexis wrote: >> >> Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and >> AArch64? Would this then mean any attempt to use Swift in kernel-space >> requires a distinct ABI? > > Th

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

Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and AArch64? Would this then mean any attempt to use Swift in kernel-space requires a distinct ABI? > On Oct 13, 2016, at 12:04 PM, Joe Groff via swift-dev > wrote: > > >> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift

[swift-dev] Dictionary Collision Resolution Guarantees

I’m currently cleaning up the docs on Dictionary to reflect the new indexing model, and I stumbled across the note that the following code should work assuming no reallocations occur: // // var (i, found) = d.find(k) // i is associated with d's buffer // if found { // var e = d

Re: [swift-dev] copy-on-write proposal

I’m having trouble figuring something out: is all of this contingent on all of the relevant operations being completely inlined into a single function at the SIL level? Could failing to inline a standard library function lead to performance cliffs? I understand this is generally true of inlining

[swift-dev] The Legend of the Toll-Free Swift -> ObjC Collection Bridge

I’ve been looking a lot into how Swift and Objective C collections inter-convert because a bunch of necessary cleanup for ABI stability interacts with it. Unfortunately I’ve run into some conflicting information with respect to how stuff should work, and how it seems to actually work. Hoping y'a

Re: [swift-dev] Representing "address-only" values in SIL

When I first started reading this proposal, my primary objection was going to be that SSA doesn’t seem to really jive well with the idea of values becoming (in)valid at some point in the future (due to moves). You can see this in the definite-init pass, which it works entirely with addresses to