[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

Re: [swift-dev] Faster debug builds?

> On Aug 6, 2017, at 16:16, Michael Gottesman wrote: > > >> On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev >> wrote: >> >> Hello, >> >> Unless I’m missing a build-script flag, it seems to me that compiling the >> Swift std

Re: [swift-dev] Faster debug builds?

Aug 6, 2017, at 1:50 PM, David Zarzycki wrote: >> >> >>> On Aug 6, 2017, at 16:16, Michael Gottesman wrote: >>> >>> >>>> On Aug 6, 2017, at 11:11 AM, David Zarzycki via swift-dev >>>> wrote: >>>> >>>> Hell

Re: [swift-dev] Faster debug builds?

ed an additional flag for the stdlib. —debug-swift-stdlib >>> >>> Sent from my iPhone >>> >>>> On Aug 6, 2017, at 1:50 PM, David Zarzycki wrote: >>>> >>>> >>>>> On Aug 6, 2017, at 16:16, Michael Gottesman wrote: >

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

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

>> wrote: >> >> >>> On Aug 8, 2017, at 3:34 PM, David Zarzycki via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> >>> In ConstraintSystem::performMemberLookup(), constructors with “simple” >>> names have a dedicated lookup

[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 internal bots. > > import

Re: [swift-dev] Debugging performance regressions?

ing > integer operations for the arithmetic and stopping there, we exponentially > attempt all combinations of all overloads of those operators. It would be > very interesting to understand why that is since based on the description I > would not expect your PR to have an impact on that. >

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

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

ing 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-dev >> wrote: &

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

> On Aug 11, 2017, at 19:21, John McCall wrote: > >> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev >> wrote: >> Hi Slava, >> >> Thanks. I’m not planning on seeking them out. I just want to minimize future >> merge conflicts with an exper

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

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

access to do that > for you. > > Slava > >> On Aug 14, 2017, at 1:14 PM, David Zarzycki via swift-dev >> wrote: >> >> On the swift.org/contributing/ web page, under “Commit Access”, the section >> talks about commit access in a way that suggests that it w

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

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

me 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-dev >> wrote: >

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

> On Aug 17, 2017, at 15:28, Mark Lacey wrote: > > > >> On Aug 17, 2017, at 10:28 AM, David Zarzycki via swift-dev >> wrote: >> >> >>> On Aug 17, 2017, at 13:03, Robert Widmann wrote: >>> >>> It’s an unfortunate naming s

[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. :-) I

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 co

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 (at least >> enough to get started and s

[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] RFC: Better diagnostics through simplification

> On Aug 24, 2017, at 00:08, John McCall wrote: > >> >> What do people think? The meat of the change is tiny and below. The vast >> majority of the work is the long and painful fallout in the test suite, >> which I’m cautiously (and perhaps foolishly) stepping up to doing. > > I think that’s

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 impleme

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

Hi David, You’re arguably deep in the weeds. Try starting by adding new nodes to ExprNodes.def and DeclNodes.def and watch what blows up. Once you do that, crib code similar nodes to get your new Expr/Decl nodes to start compiling. Please also keep in mind that LLVM and derived projects like Sw

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 com

[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? s

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

lly 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, at 13:30, David Za

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 prog

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

> On Sep 5, 2017, at 18:14, Slava Pestov wrote: > > >> On Sep 5, 2017, at 1:01 PM, David Zarzycki via swift-dev >> wrote: >> >> Hi Jordan, >> >> Thanks for thinking about this. For whatever it may be worth, I’m concerned >> about 1) the

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 f

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 tha

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 elem

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 l

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

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

> On Sep 13, 2017, at 13:53, David Sweeris wrote: > > >> On Sep 13, 2017, at 09:54, David Zarzycki via swift-dev >> wrote: >> >> Hello, >> >> As a part of a research project that I’m working on, I’ve started bumping >> into the nee

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

> On Sep 13, 2017, at 15:23, Matthew Johnson via swift-dev > wrote: > > > > Sent from my iPhone > >> On Sep 13, 2017, at 11:56 AM, David Zarzycki via swift-dev >> wrote: >> >> >> >>> On Sep 13, 2017, at 13:53, David Swe

[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 a/i

[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? Tha

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

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

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

> On Sep 19, 2017, at 12:31, Joe Groff via swift-dev > wrote: > > > >> On Sep 19, 2017, at 5:19 AM, David Zarzycki via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >> >>> On Sep 18, 2017, at 17:54, Be

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

rg>> wrote: >>> >>> >>> >>>> On Sep 19, 2017, at 5:19 AM, David Zarzycki via swift-dev >>>> mailto:swift-dev@swift.org>> wrote: >>>> >>>> >>>> >>>>> On Sep 18, 2017, at 17:

[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] A constraint system / type variable question

“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 > wrote: > > >> On Sep 23, 2017, at 3:39 PM, David Zarzycki via swift-dev >> wrote: >>

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

>> >> Hence the desire to have the closure’s type be a disjunction between two >> FunctionTypes, one where 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 >>

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 wrote: > >> On Sep 24, 2017, at 1:13 AM, David Zarzycki via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> Hi Robert, >> >&g

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 argument type, or a convention bit on >>

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 swift-dev wrote: Why is the arrow carr

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

> On Sep 25, 2017, at 21:59, Joe Groff via swift-dev > wrote: > > > > On Sep 25, 2017, at 3:41 PM, David Zarzycki > wrote: > >> >> >>> On Sep 25, 2017, at 18:23, Joe Groff >> > wrote: >>> >>> >>> On Sep 25, 2017, at 1:04 PM, David Zarz

[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: …/swift-macosx-x86_64/lib/swift/clang/lib/darw

Re: [swift-dev] Fuzzer tests failing?

ing, 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 > > >> On Oct 5, 2017, at 7:51 AM,

Re: [swift-dev] Fuzzer tests failing?

te: >>> >>> Are you building with Xcode 9.0? >>> >>> Did you try reconfiguring, e.g. >>> build-script all-your-options -- --reconfigure >>> ? >>> >>> If those do not resolve the issue, I would suggest removing the >>> s

Re: [swift-dev] Fuzzer tests failing?

> On Oct 5, 2017, at 14:19, David Zarzycki via swift-dev > wrote: > > > >> On Oct 5, 2017, at 14:06, Mark Lacey wrote: >> >> >> >>> On Oct 5, 2017, at 10:48 AM, David Zarzycki wrote: >>> >>> Hi Mark, >>> >

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

Re: [swift-dev] Exclusivity checker hacking?

> On Oct 5, 2017, at 16:50, Michael Gottesman via swift-dev > wrote: > > >> On Oct 5, 2017, at 1:42 PM, David Zarzycki via swift-dev >> wrote: >> >> Hello, >> >> As an experiment, I’d like to force the exclusivity checking logic to always

Re: [swift-dev] Exclusivity checker hacking?

> On Oct 5, 2017, at 18:08, Jordan Rose wrote: > > > >> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Hello, >> >> As an experiment, I’d like to force the exclusivity checking logic

Re: [swift-dev] Exclusivity checker hacking?

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

Re: [swift-dev] Exclusivity checker hacking?

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

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,

[swift-dev] Strange Linux smoke test failures?

Hello, I’m trying to get pull request 12496 to pass the smoke test, but it seems to be repeatedly failing the Linux smoke test in bizarre, unrelated, and unexpected ways. Does anybody have some theories about what might be going on? Or recommendations on how to workaround the smoke test failing

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 probably a more appropriate discussion for ev

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, making generic use of

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 > > wrote: >> >> There really is no way to square this circle

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 person was motivated t

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

> On Oct 25, 2017, at 08:29, David Zarzycki via swift-dev > wrote: > > > >> On Oct 25, 2017, at 02:34, Xiaodi Wu via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Please see earlier replies summarizing core team members' persua

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

> On Oct 25, 2017, at 12:01, David Sweeris wrote: > > >> On Oct 25, 2017, at 5:29 AM, David Zarzycki via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >> >>> On Oct 25, 2017, at 02:34, Xiaodi Wu via swift-dev >> <

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 allows it to > deal with

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

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

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 > wrote: > > Hi all,

[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 // // expe

Re: [swift-dev] Simple question about ParameterTypeFlags

K. > 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 1:15 PM, David Zarzycki v

Re: [swift-dev] Simple question about ParameterTypeFlags

gt;>> 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 >>&

[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: oss-swift-package-osx > Date of build:

[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] 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] 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: '-mtvos-simulator-version-min=9.0.0’

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 that way if you want, al

[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] Weird dyn_cast code gen / performance problem

tesman wrote: > > Do you have the llvm-ir handy? > >> On Jan 1, 2018, at 11:30 AM, David Zarzycki via swift-dev >> wrote: >> >> Hello, >> >> I noticed recently that the code gen of >> CanType::getClassOrBoundGenericClass() could be better and alo

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

t; On Jan 1, 2018, at 13:10, David Zarzycki via swift-dev > 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. > > Decl *my_test

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

> On Jan 1, 2018, at 18:20, John McCall wrote: > >> >> On Jan 1, 2018, at 5:51 PM, David Zarzycki via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Hi Michael, >> >> I reduced it down to a simple test case. I was wrong about t

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

20:11, Adrian Prantl wrote: > > > >>> On Dec 16, 2017, at 10:31 AM, John McCall via swift-dev >>> wrote: >>> >>> >>> On Dec 16, 2017, at 9:08 AM, David Zarzycki via swift-dev >>> wrote: >>> >>> Hel

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

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

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

> On Jan 17, 2018, at 16:06, Michael Gottesman wrote: > > > >> On Jan 17, 2018, at 8:23 AM, David Zarzycki via swift-dev >> wrote: >> >> Hello, >> >> In docs/Testing.md, “long test” is acknowledged but never defined. When >> should