date:20170629

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

2017-06-29 Thread Argyrios Kyrtzidis via swift-dev

Looking into..

> On Jun 29, 2017, at 4:51 PM, Douglas Gregor  wrote:
> 
> Argyrios, is this you? Index-while-building related.
> 
>   - Doug
> 
>> On Jun 29, 2017, at 4:51 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04-long-test [#1661]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04-long-test/1661/
>>  
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_04-long-test
>> Date of build:   Thu, 29 Jun 2017 16:19:00 -0700
>> Build duration:  32 min
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Changes
>> 
>> Commit 60b6faaae2ceaccebacfc9fe9f00a1e82e01897c by Itai Ferber:
>> Add new nil encoding methods to containers
>> 
>> edit: stdlib/public/core/Codable.swift
>> 
>> Commit f20d4425e5754684dc8b724bdc63753c97573130 by Itai Ferber:
>> Update JSONEncoder with proposed nil changes
>> 
>> edit: stdlib/public/SDK/Foundation/JSONEncoder.swift
>> 
>> Commit 0a0e6b739720eb6b7bdda9ba061b9b400ddbc4f4 by Itai Ferber:
>> Update PlistEncoder with proposed nil changes
>> 
>> edit: stdlib/public/SDK/Foundation/PlistEncoder.swift
>> 
>> Commit bf1d2a745e46ea46c764b607ba79078b02c8a442 by Itai Ferber:
>> Accessibility cleanup in {JSON,Plist}Encoder
>> 
>> edit: stdlib/public/SDK/Foundation/PlistEncoder.swift
>> edit: stdlib/public/SDK/Foundation/JSONEncoder.swift
>> 
>> Commit 692a893e16d121d698ba3637dccff67ddbc7598b by Itai Ferber:
>> Allow superDecoder to wrap null values
>> 
>> edit: stdlib/public/SDK/Foundation/PlistEncoder.swift
>> edit: stdlib/public/SDK/Foundation/JSONEncoder.swift
>> 
>> Commit baca8118209ff789162c138236365dc48ebf7007 by Itai Ferber:
>> Ensure values are decodable from nil
>> 
>> edit: test/stdlib/TestPlistEncoder.swift
>> edit: test/stdlib/TestJSONEncoder.swift
>> edit: stdlib/public/SDK/Foundation/PlistEncoder.swift
>> edit: stdlib/public/SDK/Foundation/JSONEncoder.swift
>> 
>> Commit 43f29399f38cf54eb5a1c5c43879362fdddff9f8 by Robert Widmann:
>> Remove an old diagnostic for 'var' in param position
>> 
>> edit: include/swift/AST/Decl.h
>> edit: lib/Sema/TypeCheckPattern.cpp
>> edit: lib/AST/Decl.cpp
>> edit: test/decl/var/usage.swift
>> edit: include/swift/AST/DiagnosticsSema.def
>> edit: test/decl/class/override.swift
>> edit: lib/Parse/ParsePattern.cpp
>> edit: include/swift/Parse/Parser.h
>> edit: test/Parse/invalid.swift
>> edit: test/Sema/immutability.swift
>> edit: include/swift/AST/DiagnosticsParse.def
>> 
>> Commit 75f3c99382211c23946a2ba15b5d540c7f317a1e by Doug Gregor:
>> [Clang importer] Compute requirement signature before setting
>> 
>> edit: lib/ClangImporter/ImportDecl.cpp
>> 
>> Commit b3207c832a87810f91aef22938056899341ab619 by Doug Gregor:
>> [Conformance access paths] Use protocol signature for building paths.
>> 
>> edit: lib/AST/GenericSignature.cpp
>> 
>> Commit 623d72db3c40edc7279e227027af406d859c41fb by Doug Gregor:
>> [AST] Make the "requirement signature" of a protocol a flat array.
>> 
>> edit: lib/AST/ASTDumper.cpp
>> edit: lib/Sema/TypeCheckProtocol.cpp
>> edit: include/swift/AST/Decl.h
>> edit: lib/ClangImporter/ImportDecl.cpp
>> edit: lib/AST/ASTPrinter.cpp
>> edit: include/swift/IRGen/Linking.h
>> edit: include/swift/SIL/SILWitnessVisitor.h
>> edit: lib/AST/GenericSignatureBuilder.cpp
>> edit: lib/AST/DeclContext.cpp
>> edit: lib/AST/GenericSignature.cpp
>> edit: lib/IRGen/GenDecl.cpp
>> edit: lib/AST/Decl.cpp
>> edit: lib/Sema/TypeCheckDecl.cpp
>> edit: lib/Serialization/Deserialization.cpp
>> edit: lib/AST/ProtocolConformance.cpp
>> edit: lib/AST/ASTVerifier.cpp
>> edit: lib/Parse/ParseSIL.cpp
>> edit: lib/Serialization/Serialization.cpp
>> 
>> Commit b76794ce2b516a9fbaae86369d4519fb79950e73 by Andrew Trick:
>> Benchmarks for memory exclusivity enforcement.
>> 
>> edit: benchmark/utils/main.swift
>> add: benchmark/single-source/Exclusivity.swift
>> edit: benchmark/CMakeLists.txt
>> 
>> Commit 5bacc08288348a655da36a1917518bbe2155b23a by Doug Gregor:
>> [AST] Represent requirement signature as a flat set of requirements.
>> 
>> edit: include/swift/AST/Decl.h
>> edit: lib/Serialization/Deserialization.cpp
>> edit: lib/AST/Decl.cpp
>> 
>> Commit 06c5ff026319c15db528628cebdd7506021df609 by Philippe Hausler:
>> Disable cases of uses of the -index-store-path argument
>> 
>> edit: XCTest.xcodeproj/project.pbxproj
>> 
>> Commit a5bdf9b6efa6e2c19f9dc437d92a8ec941850704 by David Farler:
>> [index/build] Upstream Clang index-while-building
>> 
>> add: include/indexstore/indexstore.h
>> add: tools/IndexStore/CMakeLists.txt
>> edit: lib/Index/IndexingContext.cpp
>> add:

Re: [swift-dev] Feature Proposal to improve Mixed Frameworks support

2017-06-29 Thread Jordan Rose via swift-dev


> On Jun 29, 2017, at 16:35, Daniel Dunbar  wrote:
> 
> 
>> On Jun 29, 2017, at 10:43 AM, Jordan Rose via swift-dev > > wrote:
>> 
>> Thanks for following through on this, Gonzalo! (The two of us talked about 
>> this briefly at WWDC.) My idea was a little less clever than yours: just 
>> always include the internal members in the main header unless you provide 
>> the name of a second header to put them in. (I called this flag 
>> -emit-objc-internal-header-path.) That's not quite as flexible, but does 
>> remove all the guesswork, at least for generated headers.
> 
> Doesn't that mean downstream Obj-C clients get bogus code completion results?

I’m not sure what you mean by this. Frameworks will always generate both 
headers, apps and unit tests will always generate one header. The only problem 
is if someone custom-builds a library target and is relying on that not 
including internal decls…which, admittedly, can happen. But the current logic 
is a patchwork of guesswork.


> 
>> I filed a bug to track this work: SR-5221 
>> .
> 
> Cool, this sounds like a nice feature to me, I have heard several complaints 
> about needing to mark things public unnecessarily.
> 
>  - Daniel
> 
>> 
>> Jordan
>> 
>> 
>>> On Jun 29, 2017, at 06:35, Gonzalo Larralde via swift-dev 
>>> > wrote:
>>> 
>>> I wanted to bring a few points into attention to discuss potential 
>>> improvements on Mixed Frameworks support. The current status for Mixed 
>>> Frameworks present some challenges, one specifically being how the Swift 
>>> compiler generates the ObjC Interface Header. 
>>> 
>>> At this moment, there's a detection procedure based on the presence of an 
>>> entry point definition (either using the main file argument, or 
>>> @UIApplicationMain). The ObjC Interface Header writer 
>>> (swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to 
>>> determine if the minimum accessibility level to be exported is either 
>>> `internal` (for app targets) or `public` (for framework targets). This can 
>>> be observed here: 
>>> https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657
>>>  
>>> 
>>> 
>>> The result of this is a difference on how default visibility is exposed to 
>>> ObjC code in the same compilation scope.
>>> 
>>> Having this initial piece of code:
>>> 
>>> ```
>>> public class Test: NSObject {
>>> public foo() {}
>>> func bar() {}
>>> }
>>> ```
>>> 
>>> results on the following Interface Header for Main App targets
>>> 
>>> -swift.h
>>> ```
>>> @interface Test : NSObject
>>> - (void)foo;
>>> - (void)bar;
>>> @end
>>> ```
>>> 
>>> and the following for Frameworks
>>> 
>>> -swift.h
>>> ```
>>> @interface Test : NSObject
>>> - (void)foo;
>>> @end
>>> ```
>>> 
>>> This is clearly correct for the publicly visible interface of the 
>>> framework, but not quite the expected result for the ObjC code compiled in 
>>> the same target. In that scenario it would make more sense to me that all 
>>> the `internal` methods are visible.
>>> 
>>> A potential solution for this problem is to generate two Interface Headers, 
>>> one that exports all the `public` and `open` entities and members, and an 
>>> additional header exposing internal entities and declaring categories to 
>>> public entities and exposing internal members.
>>> 
>>> Something like:
>>> 
>>> -swift-internal.h
>>> ```
>>> @interface Test (InternalMembers)
>>> - (void)bar;
>>> @end
>>> ```
>>> 
>>> After that it'll be Xcode's responsability to create both files, and mark 
>>> them as Public and Project in the Headers Build Phase.
>>> 
>>> An initial implementation that I think would make sense in case this 
>>> solution is accepted could be modifying the signature of 
>>> `swift::printAsObjC` to require the list of access levels to export as a 
>>> bitmask instead of just getting the minimum. That will enable the exporter 
>>> to create the following set of files:
>>> 
>>> * Internal, Public, Open > -swift.h for app targets
>>> * Public, Open > -swift.h for framework targets
>>> * Internal > -swift-internal.h for the internal entities and 
>>> members on framework targets.
>>> 
>>> To make this happen a new argument needs to be passed to the compiler call. 
>>> When it's not passed the default behaviour would remain the same, but when 
>>> it is the behaviour needs to be explicitly defined. One option is to just 
>>> get the explicit list of access levels to export (something like 
>>> `-export=internal,public,open`) or export levels to be defined (0 for app 
>>> targets, 1 for public framework targets and 2 for the internal header 
>>> framework targets for example)
>>> 
>>> I hope this feature proposal is complete enough to properly define the 
>>> scope and discuss

Re: [swift-dev] Feature Proposal to improve Mixed Frameworks support

2017-06-29 Thread Daniel Dunbar via swift-dev


> On Jun 29, 2017, at 10:43 AM, Jordan Rose via swift-dev  
> wrote:
> 
> Thanks for following through on this, Gonzalo! (The two of us talked about 
> this briefly at WWDC.) My idea was a little less clever than yours: just 
> always include the internal members in the main header unless you provide the 
> name of a second header to put them in. (I called this flag 
> -emit-objc-internal-header-path.) That's not quite as flexible, but does 
> remove all the guesswork, at least for generated headers.

Doesn't that mean downstream Obj-C clients get bogus code completion results?

> I filed a bug to track this work: SR-5221 
> .

Cool, this sounds like a nice feature to me, I have heard several complaints 
about needing to mark things public unnecessarily.

 - Daniel

> 
> Jordan
> 
> 
>> On Jun 29, 2017, at 06:35, Gonzalo Larralde via swift-dev 
>> > wrote:
>> 
>> I wanted to bring a few points into attention to discuss potential 
>> improvements on Mixed Frameworks support. The current status for Mixed 
>> Frameworks present some challenges, one specifically being how the Swift 
>> compiler generates the ObjC Interface Header. 
>> 
>> At this moment, there's a detection procedure based on the presence of an 
>> entry point definition (either using the main file argument, or 
>> @UIApplicationMain). The ObjC Interface Header writer 
>> (swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to determine 
>> if the minimum accessibility level to be exported is either `internal` (for 
>> app targets) or `public` (for framework targets). This can be observed here: 
>> https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657
>>  
>> 
>> 
>> The result of this is a difference on how default visibility is exposed to 
>> ObjC code in the same compilation scope.
>> 
>> Having this initial piece of code:
>> 
>> ```
>> public class Test: NSObject {
>>  public foo() {}
>>  func bar() {}
>> }
>> ```
>> 
>> results on the following Interface Header for Main App targets
>> 
>> -swift.h
>> ```
>> @interface Test : NSObject
>> - (void)foo;
>> - (void)bar;
>> @end
>> ```
>> 
>> and the following for Frameworks
>> 
>> -swift.h
>> ```
>> @interface Test : NSObject
>> - (void)foo;
>> @end
>> ```
>> 
>> This is clearly correct for the publicly visible interface of the framework, 
>> but not quite the expected result for the ObjC code compiled in the same 
>> target. In that scenario it would make more sense to me that all the 
>> `internal` methods are visible.
>> 
>> A potential solution for this problem is to generate two Interface Headers, 
>> one that exports all the `public` and `open` entities and members, and an 
>> additional header exposing internal entities and declaring categories to 
>> public entities and exposing internal members.
>> 
>> Something like:
>> 
>> -swift-internal.h
>> ```
>> @interface Test (InternalMembers)
>> - (void)bar;
>> @end
>> ```
>> 
>> After that it'll be Xcode's responsability to create both files, and mark 
>> them as Public and Project in the Headers Build Phase.
>> 
>> An initial implementation that I think would make sense in case this 
>> solution is accepted could be modifying the signature of 
>> `swift::printAsObjC` to require the list of access levels to export as a 
>> bitmask instead of just getting the minimum. That will enable the exporter 
>> to create the following set of files:
>> 
>> * Internal, Public, Open > -swift.h for app targets
>> * Public, Open > -swift.h for framework targets
>> * Internal > -swift-internal.h for the internal entities and 
>> members on framework targets.
>> 
>> To make this happen a new argument needs to be passed to the compiler call. 
>> When it's not passed the default behaviour would remain the same, but when 
>> it is the behaviour needs to be explicitly defined. One option is to just 
>> get the explicit list of access levels to export (something like 
>> `-export=internal,public,open`) or export levels to be defined (0 for app 
>> targets, 1 for public framework targets and 2 for the internal header 
>> framework targets for example)
>> 
>> I hope this feature proposal is complete enough to properly define the scope 
>> and discuss the viability of a possible solution. Otherwise please let me 
>> know.
>> 
>> Thanks.
>> 
>> --
>> Slds,
>> 
>> Gonzalo.
>> ___
>> 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

___
swift-dev mailing list
swift-dev@swift.org

Re: [swift-dev] External pass pipeline YAML format

2017-06-29 Thread Michael Gottesman via swift-dev


> On Jun 29, 2017, at 12:50 PM, Vasileios Kalintiris  wrote:
> 
> I plan on writing a patch for this. Based on which branch should I create the 
> pull request? Is the swift-3.1-branch frozen?

master.

> 
> On Thu, Jun 29, 2017 at 7:27 PM, Michael Gottesman  > wrote:
> 
>> On Jun 28, 2017, at 10:15 AM, Vasileios Kalintiris via swift-dev 
>> > wrote:
>> 
>> > Have you seen `utils/pass-pipeline/scripts/pipelines_build_script.py`, it 
>> > looks like it might give some hints?
>> 
>> I've tried generating a pass pipeline with 
>> utils/pass-pipeline/scripts/pipelines_generator.py and use it with the 
>> -external-pass-pipeline-filename. However, AFAICT the generated pipeline is 
>> not in the correct format that the compiler expects:
>> 
>> [
>> [
>> "HighLevel",
>> "run_n_times",
>> 2,
>> "SimplifyCFG",
>> ...
>> "GlobalARCOpts"
>> ],
>> [
>> "EarlyLoopOpt",
>> "run_n_times",
>> 1,
>> "LowerAggregateInstrs",
>> ...
>> "SwiftArrayOpts"
>> ],
>> ...
>> ]
>> 
>> Each generated pass pipeline contains the "run_n_times"|"run_to_fixed_point" 
>> field, followed by the number of iterations, which is not what the compiler 
>> expects.
>> 
>> I had no luck even when I tried to re-format the file containing the 
>> pipelines to something that I believe the compiler would expect based on the 
>> source code of SILPassPipelinePlan::getPassPipelineFromFile():
>> 
>> [
>> [
>> "HihLevel",
>> "SimplifyCFG",
>> ...
>> "GlobalARCOpts"
>> ],
>> ...
>> ]
>> 
>> or even:
>> 
>> [
>> [
>>"HighLevel",
>>[ "SimplifyCFG" ],
>>...
>>[ "GlobalARCOpts" ]
>> ],
>> ...
>> ]
>> 
>> I suspect that we don't use the pass pipeline python scripts in our 
>> buildbots anymore and the relevant bits, ie. the code in 
>> SILPassPipelinePlan::getPassPipelineFromFile and/or the python scripts, have 
>> not been kept up-to-date. 
> 
> Yes. I think that is true. Here is what I would suggest:
> 
> 1. It would be really trivial to change this to use yamltraits.
> 2. If you make this change, make sure that a test is added (maybe to sil-opt) 
> that makes sure that we can roundtrip from the dumper.
> 
> MIchael
> 
>> 
>> 
>> On Wed, Jun 28, 2017 at 6:18 PM, Daniel Dunbar > > wrote:
>> Have you seen `utils/pass-pipeline/scripts/pipelines_build_script.py`, it 
>> looks like it might give some hints?
>> --
>> $ sgit grep external-pass-pipeline-filename
>> include/swift/Option/FrontendOptions.td:def external_pass_pipeline_filename 
>> : Separate<["-"], "external-pass-pipeline-filename">,
>> utils/pass-pipeline/scripts/pipelines_build_script.py:
>> '-external-pass-pipeline-filename\;-Xfrontend\;%s' % data_file]
>> --
>> 
>>  - Daniel
>> 
>> > On Jun 28, 2017, at 5:27 AM, Vasileios Kalintiris via swift-dev 
>> > > wrote:
>> >
>> > Hi all,
>> >
>> > Please, let me know if I should post this to another list.
>> >
>> > I'm trying to figure out what is the expected YAML format of the 
>> > -external-pass-pipeline-filename option.
>> >
>> > Dumping the pass pipeline under -O and feeding it back to the compiler 
>> > with this option doesn't work (from swift-3.1-branch).
>> >
>> > I thought to ask here because I'm not entirely sure that the relevant YAML 
>> > parsing code from SILPassPipelinePlan::getPassPipelineFromFile() accepts 
>> > valid YAML input.
>> >
>> > Thanks,
>> > Vasileios
>> > ___
>> > 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 
>> 
> 
> 

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

Re: [swift-corelibs-dev] NSRegularExpression performance

2017-06-29 Thread Philippe Hausler via swift-corelibs-dev

From a performance standpoint there are a few things going on here.

1) I would highly suggest to have a compiled NSRegularExpression stored once 
per pattern. From what I can tell this is true for the code listed? Regexes in 
general are not always best to re-create all the time since it has to have a 
“compiled" engine from ICU to be made each time.

2) Last time I looked at this specific sample the cost is bridging strings back 
and forth between NSString and String. In swift 4 we have made some 
improvements for bridging but I am not certain if any specifically apply to 
this context (when run on Darwin). For linux builds we are missing the 
referencing string variants so this can cause some severe performance hits when 
copying large strings. 

3) I would avoid utf8.count in this case for measuring perf (it is probably 
going to be slow for large files)

4) per your commentary on parallelized cases, I am not certain on why that is 
slower. Presuming the source data is large (order of megabytes) it should not 
contend on the access to the regular expression. So I find this odd that it is 
not better to utilize all cores of your machine.

Now I think with some tuning we could probably get swift-corelibs-foundation to 
have some faster paths here. As well as fixing some missteps in the code listed 
for the two tests.

I have some branches that I have been working on for swift-corelibs-foundation 
that might reduce some allocation times and improve string conversions back and 
forth from reference types to structural types but those are not fully baked 
yet. Partially you have to realize that swift-corelibs-foundation is still 
quite new in comparison to the Foundation on Darwin. So we have been focusing 
on getting API coverage to a closer point than per-se performance work. Granted 
however pull requests are welcomed in both cases ;)

> On Jun 29, 2017, at 10:15 AM, Francois Green via swift-corelibs-dev 
>  wrote:
> 
> I’m uncertain if I’m using the correct forum, but I asked this question on 
> the user list a few months back and no one responded.  The 
> NSRegularExpression library seems to perform poorly and I’m wondering if this 
> is a performance bug or is it being used improperly?  I’ve added links to two 
> algorithms from the Benchmark Game project that seem quite slow when compared 
> to other languages.  While I understand that direct comparisons are not 
> possible, this one benchmark really stands out. 
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux=swift=2
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux=swift=1
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-dev] Feature Proposal to improve Mixed Frameworks support

2017-06-29 Thread Jordan Rose via swift-dev

Thanks for following through on this, Gonzalo! (The two of us talked about this 
briefly at WWDC.) My idea was a little less clever than yours: just always 
include the internal members in the main header unless you provide the name of 
a second header to put them in. (I called this flag 
-emit-objc-internal-header-path.) That's not quite as flexible, but does remove 
all the guesswork, at least for generated headers.

I filed a bug to track this work: SR-5221 
.

Jordan


> On Jun 29, 2017, at 06:35, Gonzalo Larralde via swift-dev 
>  wrote:
> 
> I wanted to bring a few points into attention to discuss potential 
> improvements on Mixed Frameworks support. The current status for Mixed 
> Frameworks present some challenges, one specifically being how the Swift 
> compiler generates the ObjC Interface Header. 
> 
> At this moment, there's a detection procedure based on the presence of an 
> entry point definition (either using the main file argument, or 
> @UIApplicationMain). The ObjC Interface Header writer 
> (swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to determine 
> if the minimum accessibility level to be exported is either `internal` (for 
> app targets) or `public` (for framework targets). This can be observed here: 
> https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657
>  
> 
> 
> The result of this is a difference on how default visibility is exposed to 
> ObjC code in the same compilation scope.
> 
> Having this initial piece of code:
> 
> ```
> public class Test: NSObject {
>   public foo() {}
>   func bar() {}
> }
> ```
> 
> results on the following Interface Header for Main App targets
> 
> -swift.h
> ```
> @interface Test : NSObject
> - (void)foo;
> - (void)bar;
> @end
> ```
> 
> and the following for Frameworks
> 
> -swift.h
> ```
> @interface Test : NSObject
> - (void)foo;
> @end
> ```
> 
> This is clearly correct for the publicly visible interface of the framework, 
> but not quite the expected result for the ObjC code compiled in the same 
> target. In that scenario it would make more sense to me that all the 
> `internal` methods are visible.
> 
> A potential solution for this problem is to generate two Interface Headers, 
> one that exports all the `public` and `open` entities and members, and an 
> additional header exposing internal entities and declaring categories to 
> public entities and exposing internal members.
> 
> Something like:
> 
> -swift-internal.h
> ```
> @interface Test (InternalMembers)
> - (void)bar;
> @end
> ```
> 
> After that it'll be Xcode's responsability to create both files, and mark 
> them as Public and Project in the Headers Build Phase.
> 
> An initial implementation that I think would make sense in case this solution 
> is accepted could be modifying the signature of `swift::printAsObjC` to 
> require the list of access levels to export as a bitmask instead of just 
> getting the minimum. That will enable the exporter to create the following 
> set of files:
> 
> * Internal, Public, Open > -swift.h for app targets
> * Public, Open > -swift.h for framework targets
> * Internal > -swift-internal.h for the internal entities and 
> members on framework targets.
> 
> To make this happen a new argument needs to be passed to the compiler call. 
> When it's not passed the default behaviour would remain the same, but when it 
> is the behaviour needs to be explicitly defined. One option is to just get 
> the explicit list of access levels to export (something like 
> `-export=internal,public,open`) or export levels to be defined (0 for app 
> targets, 1 for public framework targets and 2 for the internal header 
> framework targets for example)
> 
> I hope this feature proposal is complete enough to properly define the scope 
> and discuss the viability of a possible solution. Otherwise please let me 
> know.
> 
> Thanks.
> 
> --
> Slds,
> 
> Gonzalo.
> ___
> 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

[swift-corelibs-dev] NSRegularExpression performance

2017-06-29 Thread Francois Green via swift-corelibs-dev

I’m uncertain if I’m using the correct forum, but I asked this question on the 
user list a few months back and no one responded.  The NSRegularExpression 
library seems to perform poorly and I’m wondering if this is a performance bug 
or is it being used improperly?  I’ve added links to two algorithms from the 
Benchmark Game project that seem quite slow when compared to other languages.  
While I understand that direct comparisons are not possible, this one benchmark 
really stands out. 

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux=swift=2

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux=swift=1
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-dev] External pass pipeline YAML format

2017-06-29 Thread Michael Gottesman via swift-dev


> On Jun 28, 2017, at 10:15 AM, Vasileios Kalintiris via swift-dev 
>  wrote:
> 
> > Have you seen `utils/pass-pipeline/scripts/pipelines_build_script.py`, it 
> > looks like it might give some hints?
> 
> I've tried generating a pass pipeline with 
> utils/pass-pipeline/scripts/pipelines_generator.py and use it with the 
> -external-pass-pipeline-filename. However, AFAICT the generated pipeline is 
> not in the correct format that the compiler expects:
> 
> [
> [
> "HighLevel",
> "run_n_times",
> 2,
> "SimplifyCFG",
> ...
> "GlobalARCOpts"
> ],
> [
> "EarlyLoopOpt",
> "run_n_times",
> 1,
> "LowerAggregateInstrs",
> ...
> "SwiftArrayOpts"
> ],
> ...
> ]
> 
> Each generated pass pipeline contains the "run_n_times"|"run_to_fixed_point" 
> field, followed by the number of iterations, which is not what the compiler 
> expects.
> 
> I had no luck even when I tried to re-format the file containing the 
> pipelines to something that I believe the compiler would expect based on the 
> source code of SILPassPipelinePlan::getPassPipelineFromFile():
> 
> [
> [
> "HihLevel",
> "SimplifyCFG",
> ...
> "GlobalARCOpts"
> ],
> ...
> ]
> 
> or even:
> 
> [
> [
>"HighLevel",
>[ "SimplifyCFG" ],
>...
>[ "GlobalARCOpts" ]
> ],
> ...
> ]
> 
> I suspect that we don't use the pass pipeline python scripts in our buildbots 
> anymore and the relevant bits, ie. the code in 
> SILPassPipelinePlan::getPassPipelineFromFile and/or the python scripts, have 
> not been kept up-to-date. 

Yes. I think that is true. Here is what I would suggest:

1. It would be really trivial to change this to use yamltraits.
2. If you make this change, make sure that a test is added (maybe to sil-opt) 
that makes sure that we can roundtrip from the dumper.

MIchael

> 
> 
> On Wed, Jun 28, 2017 at 6:18 PM, Daniel Dunbar  > wrote:
> Have you seen `utils/pass-pipeline/scripts/pipelines_build_script.py`, it 
> looks like it might give some hints?
> --
> $ sgit grep external-pass-pipeline-filename
> include/swift/Option/FrontendOptions.td:def external_pass_pipeline_filename : 
> Separate<["-"], "external-pass-pipeline-filename">,
> utils/pass-pipeline/scripts/pipelines_build_script.py:
> '-external-pass-pipeline-filename\;-Xfrontend\;%s' % data_file]
> --
> 
>  - Daniel
> 
> > On Jun 28, 2017, at 5:27 AM, Vasileios Kalintiris via swift-dev 
> > > wrote:
> >
> > Hi all,
> >
> > Please, let me know if I should post this to another list.
> >
> > I'm trying to figure out what is the expected YAML format of the 
> > -external-pass-pipeline-filename option.
> >
> > Dumping the pass pipeline under -O and feeding it back to the compiler with 
> > this option doesn't work (from swift-3.1-branch).
> >
> > I thought to ask here because I'm not entirely sure that the relevant YAML 
> > parsing code from SILPassPipelinePlan::getPassPipelineFromFile() accepts 
> > valid YAML input.
> >
> > Thanks,
> > Vasileios
> > ___
> > 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

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

[swift-dev] Feature Proposal to improve Mixed Frameworks support

2017-06-29 Thread Gonzalo Larralde via swift-dev

I wanted to bring a few points into attention to discuss potential
improvements on Mixed Frameworks support. The current status for Mixed
Frameworks present some challenges, one specifically being how the Swift
compiler generates the ObjC Interface Header.

At this moment, there's a detection procedure based on the presence of an
entry point definition (either using the main file argument, or
@UIApplicationMain). The ObjC Interface Header writer
(swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to
determine if the minimum accessibility level to be exported is either
`internal` (for app targets) or `public` (for framework targets). This can
be observed here:
https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657

The result of this is a difference on how default visibility is exposed to
ObjC code in the same compilation scope.

Having this initial piece of code:

```
public class Test: NSObject {
public foo() {}
func bar() {}
}
```

results on the following Interface Header for Main App targets

-swift.h
```
@interface Test : NSObject
- (void)foo;
- (void)bar;
@end
```

and the following for Frameworks

-swift.h
```
@interface Test : NSObject
- (void)foo;
@end
```

This is clearly correct for the publicly visible interface of the
framework, but not quite the expected result for the ObjC code compiled in
the same target. In that scenario it would make more sense to me that all
the `internal` methods are visible.

A potential solution for this problem is to generate two Interface Headers,
one that exports all the `public` and `open` entities and members, and an
additional header exposing internal entities and declaring categories to
public entities and exposing internal members.

Something like:

-swift-internal.h
```
@interface Test (InternalMembers)
- (void)bar;
@end
```

After that it'll be Xcode's responsability to create both files, and mark
them as Public and Project in the Headers Build Phase.

An initial implementation that I think would make sense in case this
solution is accepted could be modifying the signature of
`swift::printAsObjC` to require the list of access levels to export as a
bitmask instead of just getting the minimum. That will enable the exporter
to create the following set of files:

* Internal, Public, Open > -swift.h for app targets
* Public, Open > -swift.h for framework targets
* Internal > -swift-internal.h for the internal entities and
members on framework targets.

To make this happen a new argument needs to be passed to the compiler call.
When it's not passed the default behaviour would remain the same, but when
it is the behaviour needs to be explicitly defined. One option is to just
get the explicit list of access levels to export (something like
`-export=internal,public,open`) or export levels to be defined (0 for app
targets, 1 for public framework targets and 2 for the internal header
framework targets for example)

I hope this feature proposal is complete enough to properly define the
scope and discuss the viability of a possible solution. Otherwise please
let me know.

Thanks.

--
Slds,

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

Re: [swift-dev] External pass pipeline YAML format

2017-06-29 Thread Vasileios Kalintiris via swift-dev

> I suspect that we don't use the pass pipeline python scripts in our
buildbots anymore and the relevant bits, ie. the code in
SILPassPipelinePlan::getPassPipelineFromFile and/or the python scripts,
have not been kept up-to-date.

It seems that the following format works for the time being:

[
  [ "Pipeline1", [ "PassName1" ],
[ "Pipeline2", [ "PassName2" ],
  [ "Pipeline3", [ "PassName3" ],
[ ...
]
  ]
]
  ]
]

However, it works only when LLVM's assertions are disabled. I'll try to
come-up with a patch that will accept a saner format with multiple passes
per pipeline entry. Against which branch should I perform a pull request?

- Vasileios



On Wed, Jun 28, 2017 at 7:15 PM, Vasileios Kalintiris  wrote:

> > Have you seen `utils/pass-pipeline/scripts/pipelines_build_script.py`,
> it looks like it might give some hints?
>
> I've tried generating a pass pipeline with 
> utils/pass-pipeline/scripts/pipelines_generator.py
> and use it with the -external-pass-pipeline-filename. However, AFAICT the
> generated pipeline is not in the correct format that the compiler expects:
>
> [
> [
> "HighLevel",
> "run_n_times",
> 2,
> "SimplifyCFG",
> ...
> "GlobalARCOpts"
> ],
> [
> "EarlyLoopOpt",
> "run_n_times",
> 1,
> "LowerAggregateInstrs",
> ...
> "SwiftArrayOpts"
> ],
> ...
> ]
>
> Each generated pass pipeline contains the "run_n_times"|"run_to_fixed_point"
> field, followed by the number of iterations, which is not what the compiler
> expects.
>
> I had no luck even when I tried to re-format the file containing the
> pipelines to something that I believe the compiler would expect based on
> the source code of SILPassPipelinePlan::getPassPipelineFromFile():
>
> [
> [
> "HihLevel",
> "SimplifyCFG",
> ...
> "GlobalARCOpts"
> ],
> ...
> ]
>
> or even:
>
> [
> [
>"HighLevel",
>[ "SimplifyCFG" ],
>...
>[ "GlobalARCOpts" ]
> ],
> ...
> ]
>
> I suspect that we don't use the pass pipeline python scripts in our
> buildbots anymore and the relevant bits, ie. the code in
> SILPassPipelinePlan::getPassPipelineFromFile and/or the python scripts,
> have not been kept up-to-date.
>
>
> On Wed, Jun 28, 2017 at 6:18 PM, Daniel Dunbar 
> wrote:
>
>> Have you seen `utils/pass-pipeline/scripts/pipelines_build_script.py`,
>> it looks like it might give some hints?
>> --
>> $ sgit grep external-pass-pipeline-filename
>> include/swift/Option/FrontendOptions.td:def
>> external_pass_pipeline_filename : Separate<["-"],
>> "external-pass-pipeline-filename">,
>> utils/pass-pipeline/scripts/pipelines_build_script.py:
>> '-external-pass-pipeline-filename\;-Xfrontend\;%s' % data_file]
>> --
>>
>>  - Daniel
>>
>> > On Jun 28, 2017, at 5:27 AM, Vasileios Kalintiris via swift-dev <
>> swift-dev@swift.org> wrote:
>> >
>> > Hi all,
>> >
>> > Please, let me know if I should post this to another list.
>> >
>> > I'm trying to figure out what is the expected YAML format of the
>> -external-pass-pipeline-filename option.
>> >
>> > Dumping the pass pipeline under -O and feeding it back to the compiler
>> with this option doesn't work (from swift-3.1-branch).
>> >
>> > I thought to ask here because I'm not entirely sure that the relevant
>> YAML parsing code from SILPassPipelinePlan::getPassPipelineFromFile()
>> accepts valid YAML input.
>> >
>> > Thanks,
>> > Vasileios
>> > ___
>> > 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.04 - Long Test (master) #1661

Re: [swift-dev] Feature Proposal to improve Mixed Frameworks support

Re: [swift-dev] Feature Proposal to improve Mixed Frameworks support

Re: [swift-dev] External pass pipeline YAML format

Re: [swift-corelibs-dev] NSRegularExpression performance

Re: [swift-dev] Feature Proposal to improve Mixed Frameworks support

[swift-corelibs-dev] NSRegularExpression performance

Re: [swift-dev] External pass pipeline YAML format

[swift-dev] Feature Proposal to improve Mixed Frameworks support

Re: [swift-dev] External pass pipeline YAML format

10 matches

Site Navigation

Mail list logo

Footer information