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

Hi Francis, That PR is on the 4.1 branch. I can’t merge it either. The failure below is on master though. -Andy > On Jan 2, 2018, at 3:08 AM, Francis Visoiu Mistrih > wrote: > > Hi Andy, > > I have a pull request ready: https://github.com/apple/swift/pull/13668 >

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

/Users/buildnode/jenkins/workspace/oss-swift_tools-RA_stdlib-RDA_test-macos-resilience/swift/tools/swift-ide-test/ModuleAPIDiff.cpp:243:1: error: cannot initialize return object of type 'bool' with an rvalue of type 'llvm::yaml::QuotingType' Francis, Maybe another test needs to be updated? -Andy

[swift-dev] [proposal] SIL implementation of ownership and borrowing

I'm sending out an updated version of my notes on SIL redesign in support of reasoning about lifetimes, including ownership and borrowing. I sent a very preliminary version of these notes a year ago. Since then, a lot has changed. Work on the SIL representation has been going on "in the background"

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

Thanks Slava, I didn’t realize that. -Andy > On Nov 18, 2017, at 7:24 AM, Slava Pestov via swift-dev > wrote: > > I reverted Kelvin’s change in the swift-4.1-branch. Foundation auto merges > from master to swift-4.1-branch but Swift does not, so the two repositories > were out of sync. > htt

Re: [swift-dev] deprecating -Ounchecked

> On Nov 3, 2017, at 12:45 PM, Slava Pestov via swift-dev > wrote: > > >> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev > > wrote: >> >> So if we replace Ounchecked with an option -unsafe-remove-checks (similar to >> -assume-single-threaded), as Johanne

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

Yeah, that error I saw was really just an @error. But I don’t see any bots that have passed with long tests and don’t see any other commits that would affect the stdlib serialized SIL. It should reproduce locally with python /s/s/llvm/utils/lit/lit.py ./validation-test-macosx-x86_64 -v --filter

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

These look like “same type constraint” errors. -Andy > On Sep 22, 2017, at 7:39 PM, no-re...@swift.org wrote: > > swift/Runtime/Concurrent.h > edit: include/swift/Runtime/MutexPThread.h > edit: stdlib/private/SwiftPrivateLibcExtras/CMakeLists.txt > edit: stdlib/private/SwiftPrivateLibcExtras/Subp

[swift-dev] Benchmark Categories

Hi swift-dev, Joe Shajrawi is adding a categorization framework to our in-tree benchmark suite (swift/benchmark). We're going to have a initial set of tags as defined below (comments welcome). These are free-form tags, but they will fall into a natural hierarchy. The purpose of tagging a benchmar

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

> On Sep 5, 2017, at 5:11 PM, Jordan Rose via swift-dev > wrote: > > Another idea would be to restrict @fixedContents to require that all stored > properties appear contiguously in the struct, possibly even pinned to the top > or bottom, to indicate that order's not completely arbitrary. Agai

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

I don’t know what this is about. Could you clean the workspace to see if it clears up? Test Case 'TestURLSession.test_httpRedirection' started at 2017-08-19 04:43:11.694 /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/utils/build-script-impl: line 261: 30177

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

ple/swift-corelibs-foundation/pull/1156> -Andy > On Aug 2, 2017, at 3:41 PM, Andrew Trick via swift-dev > wrote: > > Ian, I’m not sure why PR testing didn’t report this failure (is there a PR?). > Would you be able to revert to unblock PR testing until th

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

Ian, I’m not sure why PR testing didn’t report this failure (is there a PR?). Would you be able to revert to unblock PR testing until this is fixed? Test Case 'TestNotificationCenter.test_postNotification' started at 2017-08-02 22:33:02.555 /home/buildnode/jenkins/workspace/oss-swift-incremental

Re: [swift-dev] Enums with Many Cases/Covered Switches

> On Aug 1, 2017, at 10:49 AM, Michael Gottesman wrote: > > I was reading https://github.com/apple/swift/pull/11098 and it brought my > mind back to a strawman discussion that Roman and I had some time ago. > Namely, in some cases, we want the functionality of a covered switch, but it > would

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (master) #3906

Jordan and Alex are racing to fix it: https://github.com/apple/swift/pull/11288 Commit Summary [swift-api-digester] Update for 'deinit' as a special name. > On Aug 1, 2017, at 10:41 AM, Mishal Shah wrote: > > /Users/buildnode/jenkins/workspace/oss-s

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

Jordan, Dave, Are you reverting/fixing now? -Andy > On Aug 1, 2017, at 9:41 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#11359] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/11359/ >

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

e: >>>> On Jul 28, 2017, at 3:15 PM, John McCall >>> <mailto:rjmcc...@apple.com>> wrote: >>>>> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev >>>>> mailto:swift-dev@swift.org>> wrote: >>>>> >>>>> >>>

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

> On Jul 28, 2017, at 3:15 PM, John McCall wrote: > >> >> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev >> wrote: >> >> >>> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev >>> wrote: >>> >>> The Swift

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

> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev > wrote: > > The Swift runtime currently maintains globally unique pointer identities for > type metadata and protocol conformances. This makes checking type equivalence > a trivial pointer equality comparison, but most operations on gene

Re: [swift-dev] statically initialized arrays

> On Jun 15, 2017, at 8:30 PM, Greg Parker wrote: > > (You can do without a separate token if (1) your storage is two pointers or > less in size, (2) your storage is sufficiently well-aligned that it does not > cross cache line boundaries, (3) your uninitialized value is zero, and (4) > your

Re: [swift-dev] statically initialized arrays

> On Jun 15, 2017, at 4:26 PM, Andrew Trick wrote: > > >> On Jun 14, 2017, at 12:03 PM, Jordan Rose via swift-dev > > wrote: >> >>> ad 3) IRGen support >>> >>> Generating statically initialized globals is already done today for structs >>> and tuples. >>> What’s n

Re: [swift-dev] statically initialized arrays

> On Jun 14, 2017, at 12:03 PM, Jordan Rose via swift-dev > wrote: > >> ad 3) IRGen support >> >> Generating statically initialized globals is already done today for structs >> and tuples. >> What’s needed is the handling of objects. >> In addition to creating the global itself, we also need

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 10:36 PM, Pavol Vaskovic wrote: > > As the next two paragraphs after the part you quoted go on explaining, I'm > hoping that with this approach we could adaptively sample the benchmark until > we get stable population, but starting from lower iteration count. > > If the

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 5:29 PM, Michael Gottesman wrote: > >> I don't know what that is. > > Check it out: https://en.wikipedia.org/wiki/Mann–Whitney_U_test > . It is a > non-parametric test that two sets of samples are from the same

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 5:55 PM, Pavol Vaskovic wrote: > > > > On Tue, Jun 13, 2017 at 2:31 AM, Michael Gottesman > wrote: >> I don't think we can get more consistent test results just from re-running >> tests that were detected as changes in the first pass, as des

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 4:45 PM, Pavol Vaskovic wrote: > > I have sketched an algorithm for getting more consistent test results, so far > its in Numbers. I have ran the whole test suite for 100 samples and observed > the varying distribution of test results. The first result is quite often an

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 4:45 PM, Pavol Vaskovic wrote: > > We really have two problems: > 1. spurious results > 2. the turnaround time for the entire benchmark suite > > > I don't think we can get more consistent test results just from re-running > tests that were detected as changes in the fi

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 2:55 PM, Michael Gottesman wrote: > >> Current approach to detecting performance changes is fragile for tests that >> have very low absolute runtime, as they are easily over the 5% >> improvement/regression threshold when the test machine gets a little bit >> noisy. For

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 1:45 PM, Pavol Vaskovic wrote: > > On Tue, May 16, 2017 at 9:10 PM, Dave Abrahams via swift-dev > mailto:swift-dev@swift.org>> wrote: > > on Thu May 11 2017, Pavol Vaskovic wrote: > > I have run Benchmark_O with --num-iters=100 on my machine for the the > whole performa

Re: [swift-dev] PR-9995: enable exclusivity runtime checks.

Runtime checks only take effect at -Onone. Even if you explicitly ask for checks via -enforce-exclusivity=checked, they will be stripped (with a warning from the driver). Support for dynamic checking at -O is something that will be considered post Swift 4. -Andy > On Jun 1, 2017, at 4:47 PM,

[swift-dev] PR-9995: enable exclusivity runtime checks.

Hi swift-dev, PR-9995 enables exclusivity runtime checks: https://github.com/apple/swift/pull/9995 These checks catch violations of exclusivity that can't be discovered statically [0], printing the message: "Simultaneous accesses to 0x*, but modification requires exclusive access." The error m

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

Either I’m not properly greping the build log, or libdispatch tests fail nondeterministically. -Andy > On May 19, 2017, at 3:54 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3767] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-

Re: [swift-dev] Questions about Swift-CI

> On May 11, 2017, at 1:33 PM, Pavol Vaskovic via swift-dev > wrote: > > Douglas Gregor suggested in SR-4814 (that was merged as dupe into SR-4669) > that I get in contact with you because I’m working on issue SR-4669 Add a > Benchmark_Driver --rerun N option

Re: [swift-dev] Dependencies on Benchmark_O(& co.) --verbose format

> On May 15, 2017, at 11:20 PM, Pavol Vaskovic wrote: > > On Mon, May 15, 2017 at 7:48 PM, Andrew Trick > wrote: > The compare_perf_tests.py script parses that output. > > I am aware of that one. But my question is specifically about the `--verbose` > output. AFAIK co

Re: [swift-dev] Dependencies on Benchmark_O(& co.) --verbose format

Hi Pavol, The compare_perf_tests.py script parses that output. I don’t actually use the driver. I might start using the driver once it has a —rerun option, but the compare script should still work directly on the benchmark output. -Andy > On May 15, 2017, at 2:42 AM, Pavol Vaskovic via swift-d

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

TestFoundation/TestFoundation: undefined symbol: _T0s10DictionaryV4keyss17LazyMapCollectionVyAByxq_GxGfg -Andy > On Apr 28, 2017, at 9:51 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3350] > > Build URL: > https://ci.swift.

Re: [swift-dev] Renaming SILSuccessor -> SILCFGEdge

> On Apr 26, 2017, at 1:24 PM, Michael Gottesman via swift-dev > wrote: > > Hey everyone. > > I am currently doing some small fixes to SILSuccessor (adding some comments > and fixing some issues exposed by LLVM upstream). As I read the code it > became pretty apparent that the name is a misn

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

Backtrace: #1 0x0398c9f6 SignalHandler(int) (/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x398c9f6) #2 0x7f5e37c6f670 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11670) #3 0x0392f35e

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

> runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED This is the same failure again, which seems sensitive to me checking anything at all in. -Andy > On Apr 14, 2017, at 10:10 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [

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

> runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED This is unrelated to my commit and recovered on the next build. Is it spurious? Can CI be taught to recognize known spurious asserts? -Andy > On Apr 14, 2017, at 7:51 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-

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

I probably messed up an instruction iterator… fixing. -Andy > On Apr 10, 2017, at 1:13 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-ASAN-RA-osx [#398] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/398/ >

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

Something must have changed between the test and the merge. I’m just waiting on the PR revert’s smoke test. -Andy > On Apr 6, 2017, at 10:34 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#9249] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9

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

Building CoreAudio on armv7k: (dependent_member_type assoc_type=Swift.(file).Strideable.Stride (base=generic_type_param_type depth=0 index=0 decl=Swift.(file).func decl.T)) deserialization produced an invalid type (rdar://problem/30382791) <>UNREACHABLE executed at /Users/buildnode/jenkins/wor

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

> On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev > wrote: > > >> On Feb 6, 2017, at 11:44 AM, Jordan Rose > > wrote: >> >> >>> On Feb 6, 2017, at 11:25, Joe Groff via swift-dev >> > wrote: >>> >>> On Feb 6, 2017,

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

> On Feb 5, 2017, at 7:45 AM, Karl Wagner wrote: > > I have a question about current dispatching behaviour with protocols and > ‘Self’. > > protocol CustomEquatable { > func equal(to: Self) -> Bool > } > > open class Super : CustomEquatable { > func equal(to: Super) -> Bool { print("s

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

> On Feb 3, 2017, at 4:12 PM, Joe Groff wrote: > > Given that most open-coded resilient method lookup paths require an extra > load dependency to grab the method offset before loading the method address > itself, we might possibly consider indirecting the vtables for each class, so > that the

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

> On Feb 6, 2017, at 9:02 AM, Greg Parker wrote: > >> >> On Feb 4, 2017, at 2:35 AM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> >>> On Feb 3, 2017, at 9:37 PM, John McCall >> <mailto:rjmcc...@apple.com&g

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

> On Feb 3, 2017, at 9:37 PM, John McCall wrote: > >>> IV. The function that performs the lookup: >>> IV1) is parameterized by an isa >>> IV2) is not parameterized by an isa >>> IV1 allows the same function to be used for super-dispatch but requires >>> extra work to be inlined at the call si

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

> On Feb 3, 2017, at 3:12 PM, John McCall wrote: > > I think we can generalize this discussion a bit by describing some > mostly-independent axes of variation: That's great (sorry I used up the arabic+letter naming convention earlier in the thread)... > I. A call site: > I1) inlines the loo

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

> On Feb 3, 2017, at 1:27 PM, John McCall wrote: > >> On Feb 3, 2017, at 4:18 PM, Andrew Trick > <mailto:atr...@apple.com>> wrote: >>> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >&g

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

> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev > wrote: > >>> #3b. (lazy resolution) Offset tables can be completely localized. >>> >>> method_index = immediate >>> { // common per-class method lookup >>> isa = load[obj] >&

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

> On Feb 3, 2017, at 10:58 AM, John McCall wrote: > >> On Feb 2, 2017, at 9:57 PM, Andrew Trick via swift-dev >> wrote: >> --- >> #1. (thunk export) The simplest, most flexible way to expose dispatch >> across resilience boundaries is by exporting a sing

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

I don’t know what this could have to do with the changes in Runtime.swift. Speculatively reverting until it clears up: https://github.com/apple/swift/pull/7227 ArchetypeBuilder.cpp:2461: auto swift::ArchetypeBuilder::getGenericEnvironment(swift::GenericSignature *)::(anonymous class)::operator(

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

I'm following up on a resilient dynamic dispatch discussion kicked off by Slava during a performance team meeting to summarize some key points on public [swift-dev]. It's easy to get sidetracked by the details of dynamic dispatch and various ways to generate code. I suggest approaching the problem

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

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

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 > <mailto:jordan_r...@apple.com>> wrote: >> >>> >>> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev >> &l

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 > <mailto:swift-dev@swift.org>> wrote: >> >>> >>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir >> <mailto:blangm...

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: ** Option 1: Add a simple configuration option to swi

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

> On Jan 26, 2017, at 8:33 AM, John McCall wrote: > >> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into generic code optimiz

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 1a and 1b. It's purely

[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 citize

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 > <mailto:swift-dev@swift.org>> wrote: >> >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into generi

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 type into > another f

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

> On Jan 24, 2017, at 8:56 PM, Chris Lattner wrote: > > >> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into ge

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

e workspace. Can you do that? -Andy > On Tue, Jan 24, 2017 at 9:46 PM, Andrew Trick via swift-dev > mailto:swift-dev@swift.org>> wrote: > Mishal, > > I don’t see a failure here do you? What’s the magic string to search for in > the console output? > > -Andy > &g

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

Mishal, I don’t see a failure here do you? What’s the magic string to search for in the console output? -Andy > On Jan 24, 2017, at 9:43 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1549] > > Build URL: > https://ci.swift.

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

I’m trying to revert this now: https://github.com/apple/swift/pull/7022 -Andy > On Jan 24, 2017, at 8:22 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#1474] > > Build URL: > https://ci.swift.org/job/oss-s

[swift-dev] Proposal: Opaque SIL values

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 October—some info went out on swift-dev—but I realized there hasn’t been a formal proposal. So here it is. I w

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

This crasher is still failing to crash on Ubuntu 14.04 (crashes as expected on 16). I can’t imagine why the test would behave differently with the same target triple (x86_64-unknown-linux-gnu). Does anyone know how to REQUIRES: some-host? If not, I can lump this into deterministic-behavior. -And

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

> On Jan 9, 2017, at 12:00 AM, Andrew Trick via swift-dev > wrote: > >> On Jan 8, 2017, at 11:15 PM, Slava Pestov > <mailto:spes...@apple.com>> wrote: >> >> Assertion failed: (hasVal), function getValue, file >> /Users/buildnode/jenkins/worksp

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

> On Jan 8, 2017, at 11:15 PM, Slava Pestov wrote: > > 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

Re: [swift-dev] Proposal: SIL Ownership Model + Verifier

> On Dec 7, 2016, at 11:25 PM, John McCall via swift-dev > wrote: > >> >> On Dec 7, 2016, at 2:13 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> This is a proposal for a new SIL Ownership Model and verifier. An online >> HTML version of the document is avai

Re: [swift-dev] Proposal: SILValue SSA Instructions

> On Dec 7, 2016, at 3:16 PM, Michael Gottesman wrote: > >> >> On Dec 7, 2016, at 2:52 PM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> >>> On Dec 6, 2016, at 2:23 PM, John McCall via swift-dev >> <mailto:

Re: [swift-dev] Proposal: SILValue SSA Instructions

> On Dec 6, 2016, at 2:23 PM, John McCall via swift-dev > wrote: > >> On Dec 6, 2016, at 11:35 AM, Joe Groff > > wrote: >>> On Dec 6, 2016, at 11:29 AM, John McCall >> > wrote: >>> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev >>>

Re: [swift-dev] -Onone @inline(__always)?

> On Dec 1, 2016, at 11:55 AM, Joe Groff wrote: > > >> On Dec 1, 2016, at 11:48 AM, Andrew Trick > > wrote: >> >> Responding on swift-dev to what turned into an interesting discussion… >> >>> On Dec 1, 2016, at 11:19 AM, Joe Groff >> > wrote:

Re: [swift-dev] -Onone @inline(__always)?

> On Dec 1, 2016, at 11:48 AM, Andrew Trick wrote: > > Responding on swift-dev to what turned into an interesting discussion… > >> On Dec 1, 2016, at 11:19 AM, Joe Groff > > wrote: >> >>> >>> On Dec 1, 2016, at 11:18 AM, Joe Groff >> > wrote:

Re: [swift-dev] -Onone @inline(__always)?

Responding on swift-dev to what turned into an interesting discussion… > On Dec 1, 2016, at 11:19 AM, Joe Groff wrote: > >> >> On Dec 1, 2016, at 11:18 AM, Joe Groff wrote: >> >>> >>> On Dec 1, 2016, at 11:16 AM, Andrew Trick wrote: >>> >>> On Dec 1, 2016, at 10:34 AM, Jordan Rose w

Re: [swift-dev] Casting shadow protocols

> 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, one is derived from the > other? If so, that would probably be an acceptable improvement. (the best we >

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

> On Oct 20, 2016, at 8:41 AM, Erik Eckstein wrote: > >> To clarify: I proposed an alternate approach in which the @sil_cow reference >> is only mutable during the Array’s @inout scope—to be automatically enforced >> by the compiler once @inout scopes are enforced. But the text in question is

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

> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev > wrote: > > > on Tue Oct 18 2016, Erik Eckstein > wrote: > >>> On Oct 17, 2016, at 10:21 AM, Dave Abrahams wrote: >>> >>> >>> on Mon Oct 17 2016, Erik Eckstein wrote: >>> >> On Oct 16, 201

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

This seems fine to me… at a high level! -Andy > On Oct 14, 2016, at 2:44 PM, Michael Gottesman via swift-dev > wrote: > > Attached below is a final version of the proposal. I am going to commit it to > the repo if there are no further questions/changes/etc. > >> https://gottesmm.github.io/pro

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

> On Oct 12, 2016, at 11:19 AM, Alexis via swift-dev > wrote: > > 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 le

Re: [swift-dev] [discussion notes] SIL address types and borrowing

cCall wrote: >>>>>>> >>>>>>>> On Oct 11, 2016, at 10:10 AM, Joe Groff via swift-dev >>>>>>>> wrote: >>>>>>>>> On Oct 10, 2016, at 6:58 PM, Andrew Trick wrote: >>>>>>>>> >>>>>&g

Re: [swift-dev] [discussion notes] SIL address types and borrowing

gt;>> >>>> >>>>> On Oct 10, 2016, at 6:23 PM, Joe Groff wrote: >>>>> >>>>> >>>>>> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev >>>>>> wrote: >>>>>> ** World

Re: [swift-dev] [discussion notes] SIL address types and borrowing

> On Oct 11, 2016, at 10:10 AM, Joe Groff wrote: > > >> On Oct 10, 2016, at 6:58 PM, Andrew Trick wrote: >> >> >>> On Oct 10, 2016, at 6:23 PM, Joe Groff wrote: >>> >>> >>>> On Oct 7, 2016, at 11:10 PM, An

Re: [swift-dev] [discussion notes] SIL address types and borrowing

> On Oct 10, 2016, at 6:23 PM, Joe Groff wrote: > > >> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev >> wrote: >> ** World 1: SSA @inout >> >> Projecting an element produces a new SILValue. Does this SILValue have >> it's own

Re: [swift-dev] [discussion notes] SIL address types and borrowing

> On Oct 8, 2016, at 12:39 AM, John McCall wrote: > >> %a = alloc_stack >> >> begin_exclusive %a >> apply foo(%a) // must be marked an initializer? >> end_exclusive %a >> >> begin_shared %a >> apply bar(%a) // immutable access >> end_shared %a >> >> dealloc_stack %a > > I think alloc_stack r

Re: [swift-dev] [discussion notes] SIL address types and borrowing

; Karl > > P.S. going to pick up that unowned optional stuff soon, once I have time to > read the docs about SILGen There are SILGen docs somewhere? -Andy > >> On 8 Oct 2016, at 08:10, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >&g

[swift-dev] [discussion notes] SIL address types and borrowing

On swift-dev, John already sent out a great writeup on SIL SSA: Representing "address-only" values in SIL. While talking to John I also picked up a lot of insight into how address types relate to SIL ownership and borrow checking. I finally organized the information into these notes. This is not a

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

> On Oct 7, 2016, at 10:36 PM, Michael Gottesman wrote: > >> >> On Oct 7, 2016, at 10:26 PM, Andrew Trick > > wrote: >> >> >>> On Oct 7, 2016, at 10:08 PM, Michael Gottesman >> > wrote: >>> On Oct 7, 2016, at 9:25 PM, Andrew Tr

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

> On Oct 7, 2016, at 10:08 PM, Michael Gottesman wrote: > >> >> On Oct 7, 2016, at 9:25 PM, Andrew Trick > > wrote: >> >> >>> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> I wonder whether it might make

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev > wrote: > >> I wonder whether it might make more sense for load [borrow] to be a >> different instruction. >> There's a couple reasons for that first. The first is that it's the only >> load which introduces >> a scope, which is

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

> On Oct 3, 2016, at 12:10 PM, Alexis via swift-dev wrote: > > 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

Re: [swift-dev] Rebinding UnsafePointer makes it mutable

> On Sep 19, 2016, at 1:24 AM, Martin R via swift-dev > wrote: > > I noticed that both UnsafePointer and UnsafeMutablePointer have the identical > method > >public func withMemoryRebound(to: T.Type, capacity count: Int, > _ body: (UnsafeMutablePointer) throws -> Result) rethrows -> Resul

Re: [swift-dev] What exactly does it mean for a Swift pointer to be initialized?

> On Aug 5, 2016, at 10:42 PM, Dave Abrahams via swift-dev > wrote: > > > on Fri Aug 05 2016, Andrew Trick > wrote: > >>> On Aug 5, 2016, at 12:43 PM, Jens Persson wrote: >>> >>> I'm trying to understand the new Swift 3 (4?) pointer API and Swift's >>> memo

Re: [swift-dev] What exactly does it mean for a Swift pointer to be initialized?

> On Aug 5, 2016, at 12:43 PM, Jens Persson wrote: > > I'm trying to understand the new Swift 3 (4?) pointer API and Swift's memory > model. > > More specifically, I'd like to know more about what exactly it means for a > pointer to be initialized or not. > > For example, I suppose the follo

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

I fixed this playground logger build error, but it looks like this run didn’t pickup the fix yet. -Andy > On Jul 29, 2016, at 3:03 AM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-osx [#5577] > > Build URL:https://ci.swift.org/job/oss-swift-incremen

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

I must be building differently from the CI bot, because I’m hitting these failures trying to build playground support. I tried to fix the CI just by looking at the build log... /s/sptr/swift-xcode-playground-support/PlaygroundLogger/PlaygroundLogger_TestDriver/main.swift:19:1: error: use of unr

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

This turned out to be a spurious system failure. I unnecessarily reverted and reapplied my patch. -Andy > On Jul 29, 2016, at 12:37 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6946] > > Build URL: > https://ci.swift.org/job/oss-swift-incrementa

[swift-dev] Anyone fixing TestNSJSONSerialization?

Is anyone looking at this failure that’s blocking CI? https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6576/ TestFoundation/TestNSJSONSerialization.swift:301: error: TestNSJSONSerialization.test_deserialize_unicodeEscapeSequence : XCTAssertEqual failed: ("Optional("✨")") i

  1   2   >