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

[Arnold via swift-dev]

Should be fixed by https://github.com/apple/swift/pull/12998


> On Nov 17, 2017, at 1:29 PM, no-reply--- via swift-dev  
> wrote:
> 
> [FAILURE] oss-swift-package-osx [#708]
> 
> Build URL:https://ci.swift.org/job/oss-swift-package-osx/708/
> Project:  oss-swift-package-osx
> Date of build:Fri, 17 Nov 2017 13:42:30 -0600
> Build duration:   1 hr 47 min
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1
> 
> Changes
> 
> Commit 1c2b2eb1add2abefa3387f88d033c4b018aa9c47 by samding:
> fixed test case KeyPath.swift for s390x
> 
> edit: stdlib/public/core/KeyPath.swift
> 
> Commit 18b0240f02937361c82b84033489e192c8336d73 by shajrawi:
> Outline copy_addr part 1 clean-up: Remove Enum's TIK < Loadable check -
> 
> edit: lib/IRGen/GenEnum.cpp
> 
> Commit 5aff0891b75f3880559a0d06447abb5e76318129 by shajrawi:
> Code size: copy_addr outline part 2 - Support Archetypes
> 
> edit: test/IRGen/existentials_opaque_boxed.sil
> edit: lib/IRGen/TypeInfo.h
> edit: test/IRGen/existentials.sil
> edit: test/IRGen/existentials_objc.sil
> edit: lib/IRGen/GenEnum.h
> edit: lib/IRGen/GenRecord.h
> edit: test/IRGen/partial_apply.sil
> edit: lib/Demangling/Remangler.cpp
> edit: lib/IRGen/GenMeta.h
> edit: lib/IRGen/GenDecl.cpp
> edit: test/IRGen/unowned_objc.sil
> edit: lib/IRGen/GenEnum.cpp
> edit: lib/IRGen/IRGenFunction.cpp
> edit: lib/IRGen/IRGenFunction.h
> edit: lib/IRGen/IRGenModule.h
> edit: lib/IRGen/GenType.cpp
> edit: lib/IRGen/GenValueWitness.cpp
> edit: docs/ABI/Mangling.rst
> edit: lib/Demangling/Demangler.cpp
> edit: test/IRGen/enum_value_semantics_special_cases.sil
> edit: lib/IRGen/IRGenMangler.h
> edit: lib/IRGen/IRGenSIL.cpp
> 
> Commit 62d823c56d47c3baaef420e2093811732b3faa7c by shajrawi:
> Code size: Do not use a global state for isOutlined
> 
> edit: lib/IRGen/GenDecl.cpp
> edit: lib/IRGen/GenTuple.cpp
> edit: lib/IRGen/GenCall.cpp
> edit: lib/IRGen/GenHeap.h
> edit: lib/IRGen/NativeConventionSchema.h
> edit: lib/IRGen/GenRecord.h
> edit: lib/IRGen/TypeInfo.h
> edit: lib/IRGen/ResilientTypeInfo.h
> edit: lib/IRGen/ScalarTypeInfo.h
> edit: lib/IRGen/GenExistential.h
> edit: lib/IRGen/GenFunc.h
> edit: lib/IRGen/IRGenFunction.h
> edit: lib/IRGen/GenEnum.cpp
> edit: lib/IRGen/IRGenSIL.cpp
> edit: lib/IRGen/GenValueWitness.cpp
> edit: lib/IRGen/GenHeap.cpp
> edit: lib/IRGen/GenType.cpp
> edit: lib/IRGen/GenStruct.cpp
> edit: lib/IRGen/IRGenFunction.cpp
> edit: lib/IRGen/GenObjC.cpp
> edit: lib/IRGen/GenFunc.cpp
> edit: lib/IRGen/IndirectTypeInfo.h
> edit: lib/IRGen/GenKeyPath.cpp
> edit: lib/IRGen/CallEmission.h
> edit: lib/IRGen/GenCall.h
> edit: lib/IRGen/LoadableTypeInfo.h
> edit: lib/IRGen/FixedTypeInfo.h
> edit: lib/IRGen/GenExistential.cpp
> edit: lib/IRGen/GenEnum.h
> 
> Commit 67f2852ef23d0ca327019d44e8acaed9eac2ef4f by shajrawi:
> Code Size: copy_addr cleanup - get rid of mightContainMetadata
> 
> edit: lib/IRGen/GenRecord.h
> edit: lib/IRGen/GenType.cpp
> edit: lib/IRGen/GenValueWitness.cpp
> edit: lib/IRGen/TypeInfo.h
> edit: lib/IRGen/GenEnum.cpp
> edit: lib/IRGen/GenEnum.h
> 
> Commit bd8764caaa141f10ecce77d2fe76c3e255f2b057 by anemet:
> Add opt remarks to Generic Specializer pass
> 
> edit: test/SILOptimizer/specialize.sil
> edit: lib/SIL/OptimizationRemark.cpp
> add: test/SILOptimizer/specialize_no_definition.sil
> edit: include/swift/SIL/OptimizationRemark.h
> edit: include/swift/SILOptimizer/Utils/Generics.h
> edit: lib/SILOptimizer/Utils/Generics.cpp
> edit: lib/SILOptimizer/Transforms/GenericSpecializer.cpp
> 
> Commit a8cd86f811670574f91cf99e83c692f282b6a07b by dgregor:
> Add no-longer-crashing test case from rdar://problem/35441779.
> 
> add: validation-test/compiler_crashers_2_fixed/rdar35441779.swift
> 
> Commit 5f70f68c0d7f24b9b6e836a8e163ea556c84d680 by dgregor:
> [AST] Store only interface types in NormalProtocolConformances.
> 
> edit: test/SILGen/witness_tables.swift
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: include/swift/AST/ProtocolConformance.h
> edit: test/Generics/conditional_conformances.swift
> edit: lib/Sema/TypeCheckProtocol.cpp
> edit: lib/IDE/IDETypeChecking.cpp
> edit: lib/IRGen/GenProto.cpp
> edit: lib/Sema/CodeSynthesis.cpp
> edit: lib/AST/ASTMangler.cpp
> edit: lib/Serialization/Deserialization.cpp
> edit: test/SILGen/nested_generics.swift
> edit: lib/AST/ProtocolConformance.cpp
> edit: lib/IRGen/GenReflection.cpp
> edit: lib/AST/ConformanceLookupTable.cpp
> 
> Commit 76f281510f11ce82cebd3767a45c73c7cfa98c8e by eeckstein:
> Remove @_semantics("optimize.sil.never")
> 
> edit: test/SILOptimizer/closure_specialize_fragile.sil
> edit: test/IRGen/fixlifetime.sil
> edit: test/IRGen/lazy_metadata.swift
> edit: test/SILOptimizer/eager_specialize.sil
> edit: test/Interpreter/protocol_resilience.swift
> edit: test/SILOptimizer/devirt_nested_class.swift
> edit: test/Sanitizers/tsan-norace-deinit-run-time.swift
> edit: test/SILOptimizer/specia

Re: [swift-dev] [Swift CI] Build Failure: 2. Swift Source Compatibility Suite (master) #756

[Douglas Gregor via swift-dev]

Fixed by

https://github.com/apple/swift/pull/12991#issuecomment-345338739

Sorry!

- Doug

> On Nov 17, 2017, at 10:15 AM, no-re...@swift.org wrote:
> 
> [FAILURE] swift-master-source-compat-suite [#756]
> 
> Build URL:https://ci.swift.org/job/swift-master-source-compat-suite/756/ 
> 
> Project:  swift-master-source-compat-suite
> Date of build:Fri, 17 Nov 2017 09:53:11 -0600
> Build duration:   2 hr 22 min
> 
> Changes
> 
> Commit a8cd86f811670574f91cf99e83c692f282b6a07b by dgregor:
> Add no-longer-crashing test case from rdar://problem/35441779 
> .
> 
> add: validation-test/compiler_crashers_2_fixed/rdar35441779.swift
> 
> Commit 5f70f68c0d7f24b9b6e836a8e163ea556c84d680 by dgregor:
> [AST] Store only interface types in NormalProtocolConformances.
> 
> edit: lib/IDE/IDETypeChecking.cpp
> edit: lib/Serialization/Deserialization.cpp
> edit: lib/AST/ASTMangler.cpp
> edit: lib/Sema/TypeCheckProtocol.cpp
> edit: test/SILGen/witness_tables.swift
> edit: include/swift/AST/ProtocolConformance.h
> edit: lib/ClangImporter/ImportDecl.cpp
> edit: lib/IRGen/GenProto.cpp
> edit: test/Generics/conditional_conformances.swift
> edit: lib/AST/ProtocolConformance.cpp
> edit: lib/AST/ConformanceLookupTable.cpp
> edit: lib/IRGen/GenReflection.cpp
> edit: test/SILGen/nested_generics.swift
> edit: lib/Sema/CodeSynthesis.cpp
> 
> Commit 8192b3c859159c87a396eb85d9ad670301814b80 by dgregor:
> [SIL Printer] Wire up generic environment when printing witness tables.
> 
> edit: test/SILGen/witness_tables.swift
> edit: lib/SIL/SILPrinter.cpp
> edit: test/SILGen/nested_generics.swift
> edit: test/SILGen/conditional_conformance.swift
> 
> Commit 9ff4d7b936321be1066c5a3643623ad8c888eb51 by dgregor:
> Cleanups for interface types in normal conformances.
> 
> edit: lib/Sema/TypeCheckProtocol.cpp
> edit: lib/AST/ASTMangler.cpp
> edit: lib/IDE/IDETypeChecking.cpp
> edit: lib/IRGen/GenProto.cpp

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[no-reply--- via swift-dev]

<<< text/html; charset=UTF-8: Unrecognized >>>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Ongoing work related to compilation performance

[Graydon Hoare via swift-dev]

>> Improving incremental mode
>> ==
>> 
>> Another area that could use work is the incremental compilation logic in the 
>> driver -- that is, reducing the number of times a file is rebuilt when it 
>> "doesn't need to be" -- and some of the documentation and driver-level 
>> counters mentioned above provide insight into that (eg.  
>> https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md#driver-diagnosis
>>  
>> ).
>>  Incremental compilation is based on approximating the "true" dependency 
>> graph and sometimes this approximation is too coarse; but changing this will 
>> be a large amount of work, and the nature of a substantial change to that is 
>> still subject to a lot of analysis and design. In the meantime there may 
>> also simpler bugs lurking in the dependency-analysis logic, within the 
>> current dependency approximation; I'd be happy to help anyone who wants to 
>> spend time bug-hunting in this area understand what they're looking at.
> 
> Has any thought been put into taking advantage of llbuild for dependency 
> graphs? Can some performance improvements come from that?

Long term I think there's general interest for leveraging it, in place of the 
miniature build system inside the swift driver; but the discovery/analysis or 
dependencies and the scheduling/executing of jobs are somewhat separate tasks, 
and llbuild only does the second. The mapping from a set of swift 
declarations-and-files into a dependency graph that is a safe (but tight) 
approximation of the "true" dependencies of the compiler is the hard part. That 
is, the material that goes into a .swiftdeps file is the hard part; and 
unfortunately that's a thing build systems delegate to compilers to figure out, 
since it involves tracing the compiler's internal activities, as it runs each 
job.

-Graydon

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Forums for swift.org workgroup: looking for volunteers

[Dimitri Racordon via swift-dev]

I’d be more than happy to help as well!

> On Nov 16, 2017, at 12:39 AM, Nicole Jacque via swift-dev 
>  wrote:
> 
> As Ted Kremenek has previously announced, we are in the process of moving the 
> Swift mailing lists to Discourse. Previously the discussion was mostly about 
> moving swift-evolution over to a forum, but the consensus from Ted and the 
> Core Team was that should look to move all the lists to Discourse for 
> consistency.
> 
> I will be shepherding the transition from the mailing lists to the forum. 
> Rather than simply move the existing lists and structure as-is, we’d like to 
> take this opportunity to explore new ways of organizing the forums to help 
> foster communication and collaboration. We also have a number of new options 
> that will be available with Discourse, that we’d like some input from the 
> community on. 
> 
> To help with this, I am looking for 3-4 volunteers from the Swift community 
> to create a workgroup to discuss and create a plan for the structure for the 
> Discourse-based forums. We will then present this plan back to the community. 
> We are also investigating the possibility of having a preview version of the 
> forums available for comment from the community. 
> 
> If you would like to be part of this workgroup, please reply back to me and 
> let me know!
> 
> Thanks!
> Nicole 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Ongoing work related to compilation performance

[David Hart via swift-dev]

> On 17 Nov 2017, at 01:27, Graydon Hoare via swift-dev  
> wrote:
> 
> Hi,
> 
> This is just an update on some work that's been ongoing in the past several 
> months related to tracking and improving Swift compilation performance. I've 
> been helping coordinate some of that work: documenting what's known about 
> compilation performance patterns and diagnostic machinery, increasing 
> visibility and process controls around compilation performance, and also 
> helping making some changes directly to the compiler.
> 
> I wanted to post here to make sure everyone's aware of what's currently going 
> on, as well as solicit feedback on priorities and ways to help others 
> interested in the topic.
> 
> Here's a bit of an overview of recent activities:
> 
> 
> Compilation-performance documentation
> =
> 
> There's a somewhat lengthy document I wrote up during the summer that 
> explains what's currently known about how compilation performance varies in 
> the Swift compiler, what the causes of that variation (and existing cost 
> centers) are, how things are known to sometimes go wrong, which compiler 
> options exist to help understand the compiler's behaviour, and which 
> auxiliary tools, scripts and processes can help diagnose and improve 
> compilation performance.
> 
> It's stored in the repository 
> (https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md) and 
> I'll be trying to keep it up to date as things change, but it's a good 
> initial orientation read when approaching the topic.
> 
> 
> Pull request (PR) compilation-performance testing
> =
> 
> More interactively: a new form of PR testing (documented in 
> https://github.com/apple/swift/blob/master/docs/ContinuousIntegration.md#testing-compiler-performance)
>  has been added in recent months that committers can trigger with:
> 
>  @swift-ci please smoke test compiler performance
> 
> or
> 
>  @swift-ci please test compiler performance
> 
> The latter takes quite a long time, and if you are just curious to see if a 
> change helps or hurts compilation performance, the former is usually totally 
> adequate.
> 
> Output from these commands looks like this:
> 
>  https://github.com/apple/swift/pull/12843#issuecomment-345042338
> 
> And it displays a summary of output binary-size and compile-time changes 
> between your pull request and the branch you're committing to, as well as 
> changes to a set of compiler statistics tracking interesting causes of work.
> 
> These CI-level reports are based on compiling and measuring the source 
> compatibility testsuite (kept at 
> https://github.com/apple/swift-source-compat-suite). The "smoke" CI test, 
> which is usually sufficiently representative to catch regressions, measures 
> counters and timers for 3 projects in the source compatibility suite 
> (currently Alamofire, Kingfisher and ReactiveCocoa); the "full" test measures 
> the whole suite.
> 
> 
> Measurements in general
> ===
> 
> The measurements taken by the CI tests above are emitted by the compiler 
> using a mode introduced earlier in the year: -stats-output-dir. Briefly: this 
> mode emits a collection of .json files summarizing all available statistics 
> and timers in a given compiler (the exact set changes depending on whether 
> the compiler is built with asserts). One .json file is written per frontend 
> or driver process in a compilation, so this permits post-execution analysis 
> by a variety of tools. One such tool (swift/utils/process-stats-dir.py, see 
> https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md#post-processing-tools-for-diagnostics)
>  is usable both for batch analysis (the CI job uses it) or manually for 
> interpreting the performance impact of a change on a developer's workstation. 
> It is also, of course, usable in regression tests; a handful of tests now 
> directly measure performance counters using it.
> 
> 
> Scale testing
> =
> 
> In addition to testing the absolute values of counters in the compiler, 
> there's a bit of test infrastructure that uses those counters in a more 
> abstract way, called "scale tests" (driven by utils/scale-test.py). This 
> approach measures the relationship between linear changes to the scale of a 
> synthetic input (say: increases to the number of classes in a project) and 
> changes to the amount of work different counters in the compiler do. This is 
> explained in more detail in 
> https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md#scale-test,
>  but briefly: this allows writing tests that are insensitive to the exact 
> values of counters, but that check that counters have certain desirable 
> relationships (eg. linear or sub-linear) to the scale of inputs, rather than 
> undesirable relationships (quadratic or worse).
> 
> 
> Reducing quadratic costs
> 
> 
> One area of work that t