Re: [swift-dev] Testing, validation, and many-core machines

> On Jan 17, 2018, at 16:06, Michael Gottesman <mgottes...@apple.com> wrote: > > > >> On Jan 17, 2018, at 8:23 AM, David Zarzycki via swift-dev >> <swift-dev@swift.org> wrote: >> >> Hello, >> >> In docs/Testing.md, “long te

[swift-dev] Testing, validation, and many-core machines

Hello, In docs/Testing.md, “long test” is acknowledged but never defined. When should tests be marked “long_test”? I’m asking because there are arguably a number of latent long_test tests that are exposed on many-core machines. Speaking of many-core machines, there really isn’t a practical

[swift-dev] Clean build test failures?

Hello, I’m seeing three recent test failures that don’t go away after a clean build, including deleting the module cache beforehand: Failing Tests (3): Swift(macosx-x86_64) :: Serialization/Recovery/typedefs.swift Swift(macosx-x86_64) :: Serialization/extension-of-typealias.swift

Re: [swift-dev] SILNode versus C++

20:11, Adrian Prantl <apra...@apple.com> wrote: > > > >>> On Dec 16, 2017, at 10:31 AM, John McCall via swift-dev >>> <swift-dev@swift.org> wrote: >>> >>> >>> On Dec 16, 2017, at 9:08 AM, David Zarzycki via swift-dev

Re: [swift-dev] Weird dyn_cast code gen / performance problem

> On Jan 1, 2018, at 18:20, John McCall <rjmcc...@apple.com> wrote: > >> >> On Jan 1, 2018, at 5:51 PM, David Zarzycki via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >> Hi Michael, >> >> I reduc

Re: [swift-dev] Weird dyn_cast code gen / performance problem

t; On Jan 1, 2018, at 13:10, David Zarzycki via swift-dev <swift-dev@swift.org> > wrote: > > I don’t have the IR handy. You can easily generate it for yourself though. > Just drop the following into any file (I use swift/lib/AST/Type.cpp) and > recompile swift. &g

Re: [swift-dev] Weird dyn_cast code gen / performance problem

tesman <mgottes...@apple.com> wrote: > > Do you have the llvm-ir handy? > >> On Jan 1, 2018, at 11:30 AM, David Zarzycki via swift-dev >> <swift-dev@swift.org> wrote: >> >> Hello, >> >> I noticed recently that the code gen of >> CanTy

[swift-dev] Weird dyn_cast code gen / performance problem

Hello, I noticed recently that the code gen of CanType::getClassOrBoundGenericClass() could be better and along the way I found a clang/LLVM bug. Where exactly, I do not know, although my bet is the LLVM optimizer. When more than one dyn_cast() happens in a row, LLVM/clang emits redundant and

Re: [swift-dev] [swift-lldb-dev] Switching swift to C++14

> On Dec 19, 2017, at 17:44, Adrian Prantl via swift-dev > wrote: > > I am still hoping that one day we could retire build-script and just throw > swift into llvm/tools, so it can be built in parallel with llvm and clang by > the same ninja invocation. You can build

[swift-dev] Swift CI "auto retry"?

Is there any way to get Swift CI to automatically retry a “[smoke] test and merge” after master starts building/testing successfully again? Failing that, is anybody looking into the ":0: error: unexpected warning produced: argument unused during compilation:

[swift-dev] SIL's TrailingOperandsList versus llvm::TrailingObjects

Hello SIL exports, Why do some SILNodes use a custom TrailingOperandsList class and other SILNodes use LLVM’s TrailingObjects class? Is this just historical? It seems like the LLVM design is more flushed out and less error prone. What am I missing? Thanks, Dave

[swift-dev] SILNode versus C++

Hello, I’m trying to improve SILNode memory layout density by adopting the AST bitfield macros. Unfortunately, multiple inheritance doesn’t seem to get along with anonymous/unnamed unions. Here is a distillation of the problem: class B { protected: int i; union { int j; }; }; class X

[swift-dev] Disk full ---> Re: [Swift CI] Build Failure: OSS - Swift Package - OS X (master) #840

> On Dec 13, 2017, at 11:34, swift-ci--- via swift-dev > wrote: > > [FAILURE] oss-swift-package-osx [#840] > > Build URL:https://ci.swift.org/job/oss-swift-package-osx/840/ > > Project:

Re: [swift-dev] Simple question about ParameterTypeFlags

think perhaps __shared @escaping and __shared @autoclosure should be OK. >>> You’re just passing the context as a +0 value instead of +1. Also __shared >>> varargs make sense for the same reason. But it’s not important to get that >>> working right now. >>> &g

Re: [swift-dev] Simple question about ParameterTypeFlags

hared @autoclosure should be OK. > You’re just passing the context as a +0 value instead of +1. Also __shared > varargs make sense for the same reason. But it’s not important to get that > working right now. > > The others look OK. > > Slava > >> On Dec 11, 2017, at

[swift-dev] Simple question about ParameterTypeFlags

Hello! I’m trying to test which ParameterTypeFlags flag combinations are valid. I wrote the following test case. Are the results “as expected”, or are some of the failures incorrect? // RUN: %target-typecheck-verify-swift // // isVariadic is NOT compatible with any flag combinations // //

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

Can somebody please also speak up to why Windows needs to remove the "-Wl,-z,defs” from CXX_FLAGS? At the very least, I’d like to see the project-wide removal of this useful flag limited to just the Windows builds. > On Dec 8, 2017, at 20:36, Thomas Roughton via swift-dev

[swift-dev] FYI – Linux CI outage

Caused by: hudson.plugins.git.GitException: Command "git config remote.origin.url g...@github.com:apple/swift.git" returned status code 4: stdout: stderr: error: failed to write new configuration file /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/.git/config.lock

[swift-dev] Temporary build failures while reading the Swift module?

Despite deleting my module cache and doing a clean build, I’m seeing spurious and temporary build failures like what follows. Doing an incremental build after the failure weirdly results in a successful build. Any ideas? Is this a missing build dependency? Note: I’m using the Xcode 9B55 on

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

> On Oct 25, 2017, at 19:25, Xiaodi Wu wrote: > > I was proposing something different where Float and Int are both Equatable > and Substitutable, but neither Equatable nor Substitutable inherit from the > other. The former is mathematical and the latter is not (which

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

> On Oct 25, 2017, at 12:01, David Sweeris <daveswee...@mac.com> wrote: > > >> On Oct 25, 2017, at 5:29 AM, David Zarzycki via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >> >> >>> On Oc

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

> On Oct 25, 2017, at 08:29, David Zarzycki via swift-dev <swift-dev@swift.org> > wrote: > > > >> On Oct 25, 2017, at 02:34, Xiaodi Wu via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> Please see

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

> On Oct 25, 2017, at 02:34, Xiaodi Wu via swift-dev > wrote: > > Please see earlier replies summarizing core team members' persuasive > arguments as to why not multiple protocol hierarchies like this. Hi Xiaodi, The above line is does it help your argument. Even if a

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

> On Oct 24, 2017, at 22:04, Xiaodi Wu via swift-dev > wrote: > > On Tue, Oct 24, 2017 at 4:28 PM, David Zarzycki > wrote: > > >> On Oct 24, 2017, at 14:55, Ben Cohen via swift-dev >

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

> On Oct 24, 2017, at 14:55, Ben Cohen via swift-dev > wrote: > > There really is no way to square this circle. Every option is going to have > downsides. We have to balance correctness, least surprise/most expected > behavior for most people, and consistency. For me,

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

> On Oct 20, 2017, at 07:51, Xiaodi Wu via swift-dev > wrote: > > On Fri, Oct 20, 2017 at 1:22 AM, Jonathan Hull > wrote: > +1 for trapping unless using &==. In the case of ‘Float?’ we could also map > to nil. > > This is

Re: [swift-dev] What can you change in a non-exhaustive enum?

Hi Jordan, Bertrand (ex-Apple) would sometimes say during API design that “easy things things should be easy, and hard things should be possible”. I don’t think you guys need to go out of your way to make the autogenerated 1000-case enum scenario “easy". If people are clever enough to do that,

Re: [swift-dev] Exclusivity checker hacking?

5:23, David Zarzycki <d...@znu.io <mailto:d...@znu.io>> >>> wrote: >>> >>> >>> >>>> On Oct 5, 2017, at 18:08, Jordan Rose <jordan_r...@apple.com >>>> <mailto:jordan_r...@apple.com>> wrote: >>>

Re: [swift-dev] Exclusivity checker hacking?

ose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>> >>> >>>> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev >>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>&g

Re: [swift-dev] Exclusivity checker hacking?

> On Oct 5, 2017, at 18:08, Jordan Rose <jordan_r...@apple.com> wrote: > > > >> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> Hello, >> >>

Re: [swift-dev] Exclusivity checker hacking?

> On Oct 5, 2017, at 16:50, Michael Gottesman via swift-dev > <swift-dev@swift.org> wrote: > > >> On Oct 5, 2017, at 1:42 PM, David Zarzycki via swift-dev >> <swift-dev@swift.org> wrote: >> >> Hello, >> >> As an experiment

[swift-dev] Exclusivity checker hacking?

Hello, As an experiment, I’d like to force the exclusivity checking logic to always error at compile time, rather than a mix of compile time and run time. Near as I can tell, there is no built in debugging logic to do this (not even to warn when dynamic checks are added). Am I missing

Re: [swift-dev] Fuzzer tests failing?

> On Oct 5, 2017, at 14:19, David Zarzycki via swift-dev <swift-dev@swift.org> > wrote: > > > >> On Oct 5, 2017, at 14:06, Mark Lacey <mark.la...@apple.com> wrote: >> >> >> >>> On Oct 5, 2017, at 10:48 AM, David Zarzycki &l

Re: [swift-dev] Fuzzer tests failing?

se do not resolve the issue, I would suggest removing the >>> swift-macosx-x86_64 directory in your build destination, and see if that >>> helps. >>> >>> Mark >>> >>> >>>> On Oct 5, 2017, at 7:51 AM, David Zarzyck

Re: [swift-dev] Fuzzer tests failing?

? > > Did you try reconfiguring, e.g. > build-script all-your-options -- --reconfigure > ? > > If those do not resolve the issue, I would suggest removing the > swift-macosx-x86_64 directory in your build destination, and see if that > helps. > > Mark > > >&

[swift-dev] Fuzzer tests failing?

So the following tests have been failing for a long time now on my macOS 10.13 system: Failing Tests (2): Swift(macosx-x86_64) :: Fuzzing/fuzzer_test.swift Swift(macosx-x86_64) :: Fuzzing/fuzzer_test_simpler.swift Due to a missing file:

Re: [swift-dev] A constraint system / type variable question

> On Sep 25, 2017, at 18:23, Joe Groff wrote: > > > >> On Sep 25, 2017, at 1:04 PM, David Zarzycki wrote: >> >> >> >>> On Sep 25, 2017, at 14:37, Joe Groff wrote: >>> >>> >>> On Sep 23, 2017, at 10:36 PM, Robert Widmann via

Re: [swift-dev] A constraint system / type variable question

> On Sep 25, 2017, at 14:37, Joe Groff wrote: > > > >> On Sep 23, 2017, at 10:36 PM, Robert Widmann via swift-dev >> wrote: >> >> Why is the arrow carrying the “Has Value Semantics Bit” rather than it being >> part of a protocol composition on an

Re: [swift-dev] A constraint system / type variable question

Thanks John! I’ll find a workaround or just punt on this QoI work for now. Dave > On Sep 24, 2017, at 23:06, John McCall <rjmcc...@apple.com> wrote: > >> On Sep 24, 2017, at 1:13 AM, David Zarzycki via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@s

Re: [swift-dev] A constraint system / type variable question

, I’m open. :-) >> >> Thanks, >> Dave >> >> >>> On Sep 23, 2017, at 20:11, Robert Widmann via swift-dev >>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>> >>> >>>> On Sep 23, 2017, at 3:39 PM

Re: [swift-dev] A constraint system / type variable question

the “hasValueSemantics” bit is set, and one where it is not. If there is a better way to do this, I’m open. :-) Thanks, Dave > On Sep 23, 2017, at 20:11, Robert Widmann via swift-dev <swift-dev@swift.org> > wrote: > > >> On Sep 23, 2017, at 3:39 PM, David Zarzycki via

[swift-dev] A constraint system / type variable question

Hello, I’m trying to replace the explicit FunctionType returned by visitClosureExpr() in CSGen.cpp with a type variable; and ultimately a disjunction of two FunctionTypes with different ExtInfo flags set (one favored, one not). After reviewing the code and making a few attempts, I haven’t been

Re: [swift-dev] Value-type bound protocols?

ift-dev <swift-dev@swift.org >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> >>> >>>> On Sep 19, 2017, at 5:19 AM, David Zarzycki via swift-dev >>>> <swift-dev@swift.org <mailto:swift-dev@swift.org&

Re: [swift-dev] Value-type bound protocols?

> On Sep 19, 2017, at 12:31, Joe Groff via swift-dev <swift-dev@swift.org> > wrote: > > > >> On Sep 19, 2017, at 5:19 AM, David Zarzycki via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >> >> &g

Re: [swift-dev] Value-type bound protocols?

> On Sep 18, 2017, at 17:54, Ben Cohen via swift-dev <swift-dev@swift.org> > wrote: > > > >> On Sep 13, 2017, at 1:06 PM, David Zarzycki via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >> >>

[swift-dev] build-script has newfound interest in ninja source?

So after updating my sources, build-script fails to work with the following error: ./utils/build-script: fatal error: can't find source directory for ninja (tried /Volumes/data/wt/swift/master/ninja) Why does it care about where my ninja source is? Why does "--build-ninja false" not work?

[swift-dev] Patch RFC: value-type bound protocols

I’d still like some feedback from the core team about whether value-type bound protocols are worth formally proposing (and if so, what is the process like these days). Thanks! Dave https://github.com/davezarzycki/swift/commit/32f32ce009f649772df57c94e2958bed4ef142ab Or inline: diff --git

Re: [swift-dev] Value-type bound protocols?

> On Sep 13, 2017, at 15:23, Matthew Johnson via swift-dev > <swift-dev@swift.org> wrote: > > > > Sent from my iPhone > >> On Sep 13, 2017, at 11:56 AM, David Zarzycki via swift-dev >> <swift-dev@swift.org> wrote: >> >> &

[swift-dev] Value-type bound protocols?

Hello, As a part of a research project that I’m working on, I’ve started bumping into the need for value-type bound protocols (as opposed to the existing class bound protocols). Is this something that would be worth proposing formally? Or should I just keep the patch I have on my research

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

Hi Jordan, Okay, I just read the Library Evolution section about @fixedContents. Ya, the name of this attribute is difficult due to the collection of goals and subtle implications. I worry that others will find it difficult too, no matter what the name. :-/ I skimmed the rest of the document

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

I see. Would “@fixedSize” or “@abi(size)” be better names? In other words, the developer promises that whatever size the struct is now, it will be that way forever? Also, wouldn’t the Pair example below require that ‘A’ also be @fixedContents? Otherwise what does @fixedContents mean if the

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

Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the “hard” user-experience model I brought up feels wrong for CGPoint, etc. (For non-Apple people, CGPoint is a struct of two doubles on 64-bit machines add two floats on 32-bit machines.) It wasn’t obvious to me from context

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

Hi Jordan, I really doubt that “belt and suspenders” ABI attributes would drive people to C, but reasonable people can certainly disagree on that. Bertrand, when he was at Apple, used to say that “easy things should be easy, and hard things should be possible”. I think ABI related attributes

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

> On Sep 5, 2017, at 18:14, Slava Pestov <spes...@apple.com> wrote: > > >> On Sep 5, 2017, at 1:01 PM, David Zarzycki via swift-dev >> <swift-dev@swift.org> wrote: >> >> Hi Jordan, >> >> Thanks for thinking about this. For whateve

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

Hi Jordan, Thanks for thinking about this. For whatever it may be worth, I’m concerned about 1) the ability to reorder declarations and 2) the “either/or” nature of this proposal. First, reordering: The ability to reorder declarations is deeply ingrained into the subconsciousness of Swift

Re: [swift-dev] ToT failing to build?

s in clang::ASTReader usually mean "clear your module cache". That does > mean there's a bug, though, that we're not putting the revision numbers into > the module hash. Mind filing an SR to track that, since I thought we were? > > Jordan > > >> On Aug 30, 2017

[swift-dev] ToT failing to build?

Anybody else seeing top-of-tree (af34e394e7) fail to build? I’m on macOS 17A358a with Xcode 9M214v (beta 6) and building like so: ./utils/build-script --build-subdir="$(dirname $PWD)/t" --llvm-targets-to-build X86 --skip-ios --skip-tvos --skip-watchos -r The build crash is below. Any ideas?

Re: [swift-dev] Advice for implementing "literal values as generic types"

Hi David, To add to what I wrote earlier, the design of the Swift is such that adding new features isn’t “hard”, but it does require time and patience because most new features have ripple effects on other parts of the compiler that need to be thought through. Fortunately, the design of the

Re: [swift-dev] Strange DispatchTime bug

Hi Guillaume, Without going into details, it looks like the Swift wrappers for dispatch_time_t are very, very broken. In short, dispatch_time_t (in the C world) is intentionally documented as an opaque type, but the Swift wrappers assume otherwise and jump to wrong conclusions about the

[swift-dev] RFC: Better diagnostics through simplification

Hello, I’d like to propose improving the quality, consistency, and future preparedness of diagnostics through simplification. Right now, a lot of diagnostics output tends to look like this (for example): type ‘Foo’ cannot subclass type ‘Bar’ Instead of hard coding the word “type” into

Re: [swift-dev] How do I start implementing a feature?

> On Aug 22, 2017, at 01:24, Daryle Walker wrote: > >> On Aug 21, 2017, at 3:55 PM, David Zarzycki wrote: >> >> The easiest way to start adding new features to an existing project is by >> cribbing from existing features that are sufficiently similar

Re: [swift-dev] How do I start implementing a feature?

Hi Daryle, The easiest way to start adding new features to an existing project is by cribbing from existing features that are sufficiently similar (at least enough to get started and see what fails to compile after some changes). For example, if you wanted to implement a new and awesome loop

[swift-dev] RFC: internal language versioning

Hi Ewa! In commit 93786d8e264d095256169a6a2552970ea785036f, you wrote: “Removing isSwiftVersion4, isSwiftVersion5. We’ll need to come up with a better way to conditionalize code based on language version.” This is certainly true! I wondered what would happen as new versions came along. :-)

Re: [swift-dev] Typos while hacking on the constraint system

of them look easy to fix via some judicious use of ‘const’ and a few new local variables (instead of reassignment). It would make reasoning about the code easier for both newbies and experts alike. Dave > > ~Robert Widmann > >> On Aug 17, 2017, at 9:55 AM, David Zarzycki via swift-d

[swift-dev] Typos while hacking on the constraint system

Hello, More than once, I’ve made typos while hacking on the constraint system because the key variables are often named “type1” and “type2”. Beyond sharing 4 out of 5 characters, the ‘1’ and the ‘2’ are right next to each other on the keyboard, and typing the other by accident results in code

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

ave 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 >> <swift-dev@swift.org> wrote: >> >> On the swift.org/contributing/ web page, under “Commit Access”, the section >> ta

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

On the swift.org/contributing/ web page, under “Commit Access”, the section talks about commit access in a way that suggests that it was written before mandatory continuous integration testing was added. Is this true? Can somebody update the page? If CI is not required, then is there something

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

> On Aug 11, 2017, at 19:21, John McCall <rjmcc...@apple.com> wrote: > >> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev >> <swift-dev@swift.org> wrote: >> Hi Slava, >> >> Thanks. I’m not planning on seeking them out. I

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

u want to refactor while > working on something else, I probably wouldn’t spend time actively seeking > them out and changing them. I don’t think switching over the kind is > considered a code smell in itself. > > Slava > >> On Aug 11, 2017, at 2:48 PM, David Zarzycki via swift-d

[swift-dev] switches versus the visitor pattern?

Hello, Before I spend time creating patches, are there arguments against converting exhaustive switch statements to the visitor pattern in the Swift source base? In particular, I’m curious about switches that reason about the TypeKind enum. Thanks, – Dave

[swift-dev] Debugging performance regressions?

Any tips on how to debug performance regressions? And as aside, if this test is critical enough to cause a revert, why isn’t it in the public repo? > On Aug 9, 2017, at 14:04, Arnold Schwaighofer > wrote: > > Hi Dave, > I have reverted this commit because it broke

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

...@apple.com >> <mailto:spes...@apple.com>> wrote: >> >> >>> On Aug 8, 2017, at 3:34 PM, David Zarzycki via swift-dev >>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>> >>> In ConstraintSystem::perf

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

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 the normal lookup path handle both simple and compound named constructors, I

Re: [swift-dev] Faster debug builds?

> On Aug 6, 2017, at 16:16, Michael Gottesman <mgottes...@apple.com> wrote: > > >> On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev >> <swift-dev@swift.org> wrote: >> >> Hello, >> >> Unless I’m missing a build-script

[swift-dev] Faster debug builds?

Hello, Unless I’m missing a build-script flag, it seems to me that compiling the Swift stdlib with the unoptimized debug swift compiler takes about 15 minutes on a fast machine. Other than forcing the type checker to be optimized, what if any tricks can I use to building the stdlib faster with