[swift-dev] heads-up: some temporary build failures

[Erik Eckstein via swift-dev]

I just merged a mangling change into the swift repo. This will cause some build 
failures on linux until my foundation PR gets merged. Should be resolved in the 
next hours.

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

Re: [swift-dev] "available externally" vs build time

[Erik Eckstein via swift-dev]

> On Jan 4, 2018, at 4:57 PM, Chris Lattner  wrote:
> 
>> On Jan 4, 2018, at 1:08 PM, Erik Eckstein > > wrote:
 1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: 
 it deserializes the referenced function (MandatoryInlining.cpp:384) and 
 *then* checks to see if the callee is @_transparent.  Would it make sense 
 to change this to check for @_transparent first (which might require a SIL 
 change?), and only deserialize if so?
>>> 
>>> This seems like a clear win.
>> 
>> +1
>> 
>> It should be a trivial change and I’m wondering why we haven’t done this yet.
>> I filed https://bugs.swift.org/browse/SR-6697 
>> 
> 
> Thanks!
> 
 2. The performance inliner will have the same issue after this, and 
 deserializing the bodies of all inlinable referenced functions is 
 unavoidable for it.  However, we don’t have to copy the SIL into the 
 current module and burn compile time by subjecting it to all of the 
 standard optimizations again.  Would it make sense to put deserialized 
 function bodies into a separate SIL module, and teach the (few) IPA/IPO 
 optimizations about this fact?  This should be very straight-forward to do 
 for all of the optimizations I’m aware of.
>>> 
>>> What if we deserialized function bodies lazily instead of deserializing the 
>>> transitive closure of all serialized functions referenced from a function?
>> 
>> Well, with our pass pipeline architecture I suspect it will not make a 
>> difference. We process functions bottom-up. For example, the performance 
>> inliner optimizes the callee first before trying to inline it (because it 
>> influences the inlining decision). So the performance inliner actually 
>> visits the whole call tree.
>> 
 Would it make sense to put deserialized function bodies into a separate 
 SIL module
>> 
>> We serialize early in the pipeline, i.e. serialized functions are not 
>> (fully) optimized.
> 
> Really?  The serialized functions in the standard library aren’t optimized?  
> That itself seems like a significant issue: you’re pushing optimized compile 
> time cost onto every user’s source file that uses an unoptimized stdlib 
> symbol.

First of all, serialized functions are optimized, but not with the full 
optimization pipeline. We serialize in the middle of the pass pipeline.
The reason for this is that we solve two problems with that:
1) We cannot serialize fragile functions which inlined resilient functions, 
because this would expose resilient code to the client. On the other hand we 
want to enable this kind of inlining for code generated in the module itself. 
In other words: we need a different optimization pipeline for code generation 
and serialization anyway.
2) The optimization pipeline is split into “high level” and “low level” 
regarding @_semantics functions. In the high-level part @_semantic functions 
are not inlined. If we serialize after such functions are inlined then we would 
de-serialize “low-level” sil into “high level” sil.

I’m not worried about the compile time impact of early serialization. When we 
did that change we measured compile time and didn’t see a significant 
difference.

> 
>> And at least the performance inliner needs functions to be optimized to make 
>> good inlining decisions. So it makes sense to also optimize deserialized 
>> functions.
>> 
>> That said, I’m sure there is still potential for improvements. For example, 
>> we could exclude deserialized generic functions from optimizations, because 
>> we only inline specialized functions.
> 
> If the serialized functions are in fact optimized, you have a lot of ways to 
> avoid deserializing in practice.  There just aren’t that many IPO/IPA passes 
> in the compiler, so you can build in summaries that they need into the 
> serialized sil code.  If they aren’t optimized, then there are bigger 
> problems.

Inlining decisions also depend on the caller context, like function argument 
values, e.g. if a function argument is constant and that argument controls a 
condition in the callee, this is considered.
It’s possible to model this in a summary information, but it’s not trivial.
But, as I said, there are definitely many possibilities for improvements.

> 
> -Chris
> 

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

Re: [swift-dev] "available externally" vs build time

[Erik Eckstein via swift-dev]

> On Jan 4, 2018, at 1:14 PM, Slava Pestov  wrote:
> 
> 
> 
>> On Jan 4, 2018, at 1:08 PM, Erik Eckstein > > wrote:
>> 
>> 
>> 
>>> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev >> > wrote:
>>> 
>>> 
>>> 
 On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev 
 mailto:swift-dev@swift.org>> wrote:
 
 Folks working on the SIL optimizer, particularly those interested in 
 faster builds:
 
 If I understand the SIL optimizer correctly, it seems that when the 
 current program references an external symbol declared as @_inlinable, 
 that SILModule::linkFunction eagerly deserializes the @_inlinable body and 
 splat it into the current module.  That SIL function exists in the current 
 module, gets optimized, inlined, etc along with existing functions, then 
 gets dropped on the floor at IRGen time if it still exists.
>>> 
>>> I’ve noticed this too, but haven’t had time to look at it yet.
>>> 
 If this is true, this seems like an incredibly wasteful approach, 
 particularly given how many @_inlinable functions exist in the standard 
 library, and particularly for programs that have lots of small files.  Try 
 this:
>>> 
>>> I agree!
>>> 
 1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: 
 it deserializes the referenced function (MandatoryInlining.cpp:384) and 
 *then* checks to see if the callee is @_transparent.  Would it make sense 
 to change this to check for @_transparent first (which might require a SIL 
 change?), and only deserialize if so?
>>> 
>>> This seems like a clear win.
>> 
>> +1
>> 
>> It should be a trivial change and I’m wondering why we haven’t done this yet.
>> I filed https://bugs.swift.org/browse/SR-6697 
>> 
>> 
>>> 
 2. The performance inliner will have the same issue after this, and 
 deserializing the bodies of all inlinable referenced functions is 
 unavoidable for it.  However, we don’t have to copy the SIL into the 
 current module and burn compile time by subjecting it to all of the 
 standard optimizations again.  Would it make sense to put deserialized 
 function bodies into a separate SIL module, and teach the (few) IPA/IPO 
 optimizations about this fact?  This should be very straight-forward to do 
 for all of the optimizations I’m aware of.
>>> 
>>> What if we deserialized function bodies lazily instead of deserializing the 
>>> transitive closure of all serialized functions referenced from a function?
>> 
>> Well, with our pass pipeline architecture I suspect it will not make a 
>> difference. We process functions bottom-up. For example, the performance 
>> inliner optimizes the callee first before trying to inline it (because it 
>> influences the inlining decision). So the performance inliner actually 
>> visits the whole call tree.
> 
> However, imagine if f() calls g() which calls h() which calls i(). If all 
> four of f, g, h, and i are serialized, then we will deserialize them all as 
> soon as anything references f(). But the performance inliner might choose to 
> inline f(), and not g(), therefore the deserialization of h() and i() is 
> unnecessary.
> 
> Or am I misunderstanding the issue here?

To make the inlining decision for g() into f() the optimizer looks at h() and 
i() as well.

But the question is if the additional compile time this is worth the improved 
accuracy.
We could definitely do something more intelligent and/or compile time favorable 
here.

> 
>> 
 Would it make sense to put deserialized function bodies into a separate 
 SIL module
>> 
>> We serialize early in the pipeline, i.e. serialized functions are not 
>> (fully) optimized. And at least the performance inliner needs functions to 
>> be optimized to make good inlining decisions. So it makes sense to also 
>> optimize deserialized functions.
>> 
>> That said, I’m sure there is still potential for improvements. For example, 
>> we could exclude deserialized generic functions from optimizations, because 
>> we only inline specialized functions.
>> 
>>> 
>>> Slava
>>> 
 
 I haven’t done any measurements, but this seems like it could be a big 
 speedup, particularly for programs containing a bunch of relatively small 
 files and not using WMO.
 
 -Chris
 
 ___
 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
sw

Re: [swift-dev] "available externally" vs build time

[Erik Eckstein via swift-dev]

> On Jan 2, 2018, at 1:08 PM, Slava Pestov via swift-dev  
> wrote:
> 
> 
> 
>> On Dec 28, 2017, at 4:32 PM, Chris Lattner via swift-dev 
>>  wrote:
>> 
>> Folks working on the SIL optimizer, particularly those interested in faster 
>> builds:
>> 
>> If I understand the SIL optimizer correctly, it seems that when the current 
>> program references an external symbol declared as @_inlinable, that 
>> SILModule::linkFunction eagerly deserializes the @_inlinable body and splat 
>> it into the current module.  That SIL function exists in the current module, 
>> gets optimized, inlined, etc along with existing functions, then gets 
>> dropped on the floor at IRGen time if it still exists.
> 
> I’ve noticed this too, but haven’t had time to look at it yet.
> 
>> If this is true, this seems like an incredibly wasteful approach, 
>> particularly given how many @_inlinable functions exist in the standard 
>> library, and particularly for programs that have lots of small files.  Try 
>> this:
> 
> I agree!
> 
>> 1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: it 
>> deserializes the referenced function (MandatoryInlining.cpp:384) and *then* 
>> checks to see if the callee is @_transparent.  Would it make sense to change 
>> this to check for @_transparent first (which might require a SIL change?), 
>> and only deserialize if so?
> 
> This seems like a clear win.

+1

It should be a trivial change and I’m wondering why we haven’t done this yet.
I filed https://bugs.swift.org/browse/SR-6697

> 
>> 2. The performance inliner will have the same issue after this, and 
>> deserializing the bodies of all inlinable referenced functions is 
>> unavoidable for it.  However, we don’t have to copy the SIL into the current 
>> module and burn compile time by subjecting it to all of the standard 
>> optimizations again.  Would it make sense to put deserialized function 
>> bodies into a separate SIL module, and teach the (few) IPA/IPO optimizations 
>> about this fact?  This should be very straight-forward to do for all of the 
>> optimizations I’m aware of.
> 
> What if we deserialized function bodies lazily instead of deserializing the 
> transitive closure of all serialized functions referenced from a function?

Well, with our pass pipeline architecture I suspect it will not make a 
difference. We process functions bottom-up. For example, the performance 
inliner optimizes the callee first before trying to inline it (because it 
influences the inlining decision). So the performance inliner actually visits 
the whole call tree.

>>  Would it make sense to put deserialized function bodies into a separate SIL 
>> module

We serialize early in the pipeline, i.e. serialized functions are not (fully) 
optimized. And at least the performance inliner needs functions to be optimized 
to make good inlining decisions. So it makes sense to also optimize 
deserialized functions.

That said, I’m sure there is still potential for improvements. For example, we 
could exclude deserialized generic functions from optimizations, because we 
only inline specialized functions.

> 
> Slava
> 
>> 
>> I haven’t done any measurements, but this seems like it could be a big 
>> speedup, particularly for programs containing a bunch of relatively small 
>> files and not using WMO.
>> 
>> -Chris
>> 
>> ___
>> 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-dev] Zero-cost 'Service Provider Interface'/Signature Packages

[Erik Eckstein via swift-dev]

> On Nov 10, 2017, at 3:05 PM, Joe Groff  wrote:
> 
> 
> 
>> On Nov 8, 2017, at 9:59 PM, Erik Eckstein via swift-dev 
>>  wrote:
>> 
>> 
>> 
>>> On Nov 8, 2017, at 5:27 PM, Johannes Weiß via swift-dev 
>>>  wrote:
>>> 
>>> Hi Daniel,
>>> 
>>>> On 2 Nov 2017, at 8:15 pm, Daniel Dunbar  wrote:
>>>> 
>>>> My personal preference is to:
>>>> 1. Do nothing for now, but encourage publishing standardized protocols to 
>>>> solve this need.
>>>> 2. Hope for a future with WMO+LTO magic which recovers the performance, 
>>>> for the case where the entire application ends up using one implementation.
>>> 
>>> Hmm, but that'll only work if we get 'whole product optimisation', right?
>> 
>> yes.
>> 
>> Even when we have cross-module optimizations (which would be comparable to 
>> thin-lto) we could not do that optimization.
>> 
>>> If we still compile one module at the time I don't think the compiler will 
>>> be able to figure out that there's just one implementation of that protocol 
>>> in the whole program.
>> 
>> exactly
> 
> If you know you're building for an executable target, then it should be 
> theoretically possible to look at the whole system and see that there's a 
> single conformance to a protocol. For the situation Johannes is talking 
> about, maybe this could be information that the build system feeds the 
> compiler, so in a configuration file somewhere you'd say "I want to 
> specialize all uses of the Logger.Logger protocol for the 
> FancyLogger.FancyLogger implementation" instead of relying on 
> the compiler magically deriving it.

Actually, speculative-devirtualization of protocol methods + cross-module 
optimization should be able to handle this. The only drawback is code size, 
which is fortunately not so important for that project.


> 
> -Joe

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

Re: [swift-dev] Zero-cost 'Service Provider Interface'/Signature Packages

[Erik Eckstein via swift-dev]

> On Nov 8, 2017, at 5:27 PM, Johannes Weiß via swift-dev  
> wrote:
> 
> Hi Daniel,
> 
>> On 2 Nov 2017, at 8:15 pm, Daniel Dunbar  wrote:
>> 
>> My personal preference is to:
>> 1. Do nothing for now, but encourage publishing standardized protocols to 
>> solve this need.
>> 2. Hope for a future with WMO+LTO magic which recovers the performance, for 
>> the case where the entire application ends up using one implementation.
> 
> Hmm, but that'll only work if we get 'whole product optimisation', right?

yes.

Even when we have cross-module optimizations (which would be comparable to 
thin-lto) we could not do that optimization.

> If we still compile one module at the time I don't think the compiler will be 
> able to figure out that there's just one implementation of that protocol in 
> the whole program.

exactly

> In fact it can't as that module might be linked into different programs and 
> one of those programs might have a second implementation of that protocol. 
> This is extremely likely as the 'test program' might have a mock/fake or some 
> special implementation. Did I misunderstand you here?
> 
> 
>> You can manage some of the “dependency injection” part by making the package 
>> which exports the common protocol also export a global variable for the 
>> concrete implementation in use (with setters). That could just be a 
>> “pattern” people follow. This wouldn’t be particularly pretty, but it would 
>> mean that intermediate packages could avoid declaring a concrete dependency 
>> on any one implementation, and leave it up to clients to pick.
> 
> hmm, two questions:
> - what would the type of that global variable be? All libraries in the 
> program will need to know and agree on that type
> - sounds like ThreadSanitizer would trap here unless we synchronise it which 
> would make it slow again
> 
> 
> -- Johannes
> 
>> - Daniel
>> 
>>> On Nov 2, 2017, at 5:57 PM, Johannes Weiß via swift-dev 
>>>  wrote:
>>> 
>>> Hi swift-dev,
>>> 
>>> I talked to a few people about this problem and we agreed that it is a 
>>> problem and that it needs to be discussed. I didn't quite know where it 
>>> would fit best but let's go with swift-dev, please feel free to tell to 
>>> post it elsewhere if necessary. And apologies for the long mail, couldn't 
>>> come up with a sensible tl;dr...
>>> 
>>> Let me briefly introduce the problem what for the lack of a better name I 
>>> call 'signature package' or 'Service Provider Interface' (SPI) as some 
>>> people from the Java community seem to be calling it 
>>> (https://en.wikipedia.org/wiki/Service_provider_interface). For the rest of 
>>> this email I'll use the term SPI.
>>> 
>>> In a large ecosystem there is a few pieces that many libraries will depend 
>>> on and yet it seems pretty much impossible to standardise exactly one 
>>> implementation. Logging is a very good example as many people have 
>>> different ideas about how logging should and should not work. At the moment 
>>> I guess your best bet is to use your preferred logging API and hope that 
>>> all your other dependencies use the same one. If not you'll likely run into 
>>> annoying problems (different sub-systems logging to different places or 
>>> worse).
>>> 
>>> Also, in a world where some dependencies might be closed source this is an 
>>> even bigger problem as clearly no open-source framework will depend on 
>>> something that's not open-source.
>>> 
>>> 
>>> In Java the way seems to be to standardise on some logging interface (read 
>>> `protocol`) with different implementations. For logging that'd probably be 
>>> SLF4J [4]. In Swift:
>>> 
>>>  let logger: LoggerProtocol = MyFavouriteLoggingFramework(configuration)
>>> 
>>> where `LoggerProtocol` comes from some SPI package and 
>>> `MyFavouriteLoggingFramework` is basically what the name says. And as a 
>>> general practise, everybody would only use `LoggerProtocol`. Then tomorrow 
>>> when I'll change my mind replacing `MyFavouriteLoggingFramework` by 
>>> `BetterFasterLoggingFramework` does the job. With 'dependency injection' 
>>> this 'logger' is handed through the whole program and there's a good chance 
>>> of it all working out. The benefits are that everybody just needs to agree 
>>> on a `protocol` instead of an implementation. 👍
>>> 
>>> In Swift the downside is that this means we're now getting a virtual 
>>> dispatch and the existential everywhere (which in Java will be optimised 
>>> away by the JIT). That might not be a huge problem but it might undermine 
>>> 'CrazyFastLoggingFramework's adoption as we always pay overhead.
>>> 
>>> I don't think this problem can be elegantly solved today. What I could make 
>>> work today (and maybe we could add language/SwiftPM support to facilitate 
>>> it) is this (⚠️, it's ugly)
>>> 
>>> - one SwiftPM package defines the SPI only, the only thing it exports is a 
>>> `public protocol` called say `_spi_Logger`, no implementation
>>> - every implementation of that SPI defines a `public 

Re: [swift-dev] deprecating -Ounchecked

[Erik Eckstein via swift-dev]

> On Nov 5, 2017, at 4:05 PM, Andrew Trick  wrote:
> 
> 
> 
>> On Nov 3, 2017, at 12:45 PM, Slava Pestov via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> 
>>> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> So if we replace Ounchecked with an option -unsafe-remove-checks (similar 
>>> to -assume-single-threaded), as Johannes suggested, this is more like a “at 
>>> your own risk” thing (regarding performance). For example, it might happen 
>>> that users see perf regressions from one release to another, using this 
>>> option.
>> 
>> I would suggest going further and removing the code for 
>> -unsafe-remove-checks altogether. Even untested code has a cost in terms of 
>> maintainability.
>> 
>> Slava
> 
> If we have an -unsafe-remove-checks option, then it will be tested. In this 
> particular case, maintaining the functionality is insignificant, but the 
> feature is fairly useful for evaluating the cost of checks in small 
> benchmarks without rewriting the source.
> 
> Supporting a few unit tests is completely different from constantly tracking 
> performance of this mode and investigating regressions. I agree with Erik 
> that it’s not worth continuing to do this.
> 
> The spelling of the option does matter. -Oxxx carries some QoI expectations 
> and implies that we are evaluating performance of that mode in every release 
> cycle. We don’t want to do that.
> 
> I do not agree that -Ounchecked should be mapped to -O. Lying to the user is 
> never the right answer. It could be mapped to some internal option name with 
> a deprecation warning.

You are right, this is better.

> 
> -Andy
> 
> 
> 

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

Re: [swift-dev] deprecating -Ounchecked

[Erik Eckstein via swift-dev]

> On Nov 3, 2017, at 10:51 PM, Chris Lattner via swift-dev 
>  wrote:
> 
> 
>> On Nov 3, 2017, at 10:23 PM, Slava Pestov via swift-dev > > wrote:
>> 
>> 
>> 
>>> On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Random question: when did you introduce -Osize, and why didn’t it go 
>>> through the evolution process?  If this is a major flag that you expect 
>>> users to interact with (not some obscure debugging feature) then it is part 
>>> of the “UI" of Swift and seems subject to swift-evolution’s process.
>> 
>> Are compiler flags within the scope of the evolution process? -Osize has no 
>> effect on source compatibility or any other user-visible aspect of the 
>> language itself.
> 
> I don’t think there is an official policy, but IMO, all major new user 
> visible features are in scope for evolution.

swift evolution is for the "Swift language and the public interface of the 
Swift standard library” (which makes sense IMO).
So command line options don’t need to go through the evolution process. For 
example, there could be another swift compiler, which is 100% swift compatible 
but provides a different option set.

But of course, we should discuss Ounchecked on swift-dev and that’s what we are 
doing now.

So far I got the feedback that some people still want to disable runtime checks 
and that’s perfectly fine.
There is no problem in keeping that code generation option in the compiler (and 
in fact it’s only a very small check in the optimizer) and we will test that it 
is functional correct. But we - the swift perf team - probably won’t have 
capacity to maintain performance tracking of this mode (e.g. checking and 
investigation of perf regressions). But hey, swift is an open source project 
and everyone who is interested can invest effort in this.

About the naming convention: removing runtime checks is not really an 
optimization mode. It’s really more comparable to -assume-single-threaded 
(which is maybe as important as removed runtime checks for some users). So I 
think it makes sense to “rename” Ounchecked.


> Random question: when did you introduce -Osize, and why didn’t it go through 
> the evolution process?  If this is a major flag that you expect users to 
> interact with (not some obscure debugging feature) then it is part of the 
> “UI" of Swift and seems subject to swift-evolution’s process.

I don’t agree. Command line options are the “UI” of a swift compiler but not of 
the swift language.


> 
> -Chris
> 
> 
> ___
> 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] deprecating -Ounchecked

[Erik Eckstein via swift-dev]

> On Nov 2, 2017, at 8:50 PM, Chris Lattner  wrote:
> 
> 
>> On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I’d like to propose to deprecate the -Ounchecked swift optimization mode.
>> 
>> The -Ounchecked mode actually contradicts one of the main goals of swift: to 
>> be a safe language.
>> In the past we didn’t see lot of significant performance differences 
>> compared to -O (there were some improvements but also some regressions).
>> Also, we want to reduce the effort of maintaining too many different 
>> optimization modes, especially because we recently added -Osize.
>> 
>> Deprecating would mean that we map -Ounchecked to -O.
>> 
>> If you have any comments or concerns, please let me know
> 
> What’s the motivation for this?  What problem does it solve?

There are several issues:
First, Ounchecked does not come for free. To really support this mode we would 
have to constantly track performance metrics for this, investigate 
performance/codesize regressions, etc. This is a lot of effort.

So if we replace Ounchecked with an option -unsafe-remove-checks (similar to 
-assume-single-threaded), as Johannes suggested, this is more like a “at your 
own risk” thing (regarding performance). For example, it might happen that 
users see perf regressions from one release to another, using this option.

The second thing is, IMO, that -Ounchecked suggests that it’s just another 
choice like -O. But I think we should encourage people to not use Ounchecked. I 
think it’s fine if experienced developers, who know what they are doing, use 
-unsafe-remove-checks, but we should not promote this mode in a prominent place 
like in the -O namespace. This is just my personal opinion and I’m sure some 
people have other opinions on this.

The third issue is that we now have -Osize. The -unsafe-remove-checks would be 
orthogonal to -O and -Osize.
BTW, we should rename -O to -Ospeed for consistency (keeping -O as an alias for 
-Ospeed).


> 
> Swift isn’t a "strict safety at all costs” language.  It is a pragmatic 
> language which aims to give people tools to solve problems.  One of the nice 
> things about -Ounchecked is that it provides an easy way to get a data point 
> about the cost of runtime checks.
> 
> -Chris
> 

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

Re: [swift-dev] deprecating -Ounchecked

[Erik Eckstein via swift-dev]

> On Nov 2, 2017, at 1:56 PM, Thomas Roughton via swift-dev 
>  wrote:
> 
> A -1 from me to deprecating the mode. I’ve been using Swift in 
> high-performance situations such as in a game engine, where in particular 
> thing like integer overflow checks become a measurable cost in tight inner 
> loops. Currently I can’t use Array in many places due to ownership issues and 
> retain/release costs, but once that hopefully becomes feasible I’d also 
> definitely want the option to elide e.g. range checks. 
> 
> I’m aware there are alternatives to e.g. add without overflow checking with 
> &+ (which I use in some cases to make debug mode usable), but in general it’s 
> very useful to be able to test with these checks in debug mode and then have 
> them stripped in a release build once you’re reasonably confident they’re 
> safe. 
> 
> As a side note, if you’re only discussing renaming, I think it’s already 
> exposed as two separate options in Xcode: you have optimisation level 
> (mapping to -Onone, -O, -O,-wmo) and a separate ‘Disable Safety Checks’ 
> option. Mapping the compiler flags to match would I think make sense.

As I said, I like the idea from Johannes to add -unsafe-remove-checks, similar 
to -assume-single-threaded. I hope that’s ok with you.

> 
> I’m curious as to when you see performance regressions with -Ounchecked. Does 
> it limit the ability of the compiler to make some optimisations?

We didn’t actually investigate those regressions. But whenever the optimizer 
runs a different path it can happen that performance also regresses, even when 
it’s unexpected. For example, inlining decisions may change, which can have a 
big impact in both directions.

> 
> Thomas
> 
> On 3/11/2017, at 9:35 AM, Johannes Weiß via swift-dev  <mailto:swift-dev@swift.org>> wrote:
> 
>> 
>> 
>>> On 2 Nov 2017, at 1:33 pm, Erik Eckstein >> <mailto:eeckst...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Nov 2, 2017, at 10:51 AM, Johannes Weiß >>> <mailto:johanneswe...@apple.com>> wrote:
>>>> 
>>>> Definitely a +1 from me, a haven't recently seen much of a difference 
>>>> either.
>>>> 
>>>> Said that I do sometimes use it in a micro-benchmark just to convince 
>>>> myself we don't lose much performance on the checks. Usually it turns out 
>>>> fine, I'm happy and move on. But I guess there's some value in being able 
>>>> to elide a lot of checks just to see how much of a difference it does. And 
>>>> if there's a big difference then I'd try to optimise the program and elide 
>>>> unnecessary checks myself. Clearly -Ounchecked should never be used in any 
>>>> real code but I find having a baseline when optimising performance very 
>>>> helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline 
>>>> for some code ;).
>>>> 
>>>> And lastly I always thought having it as an 'optimisation' is a misnomer, 
>>>> it's not an optimisation as it clearly changes the semantics of the 
>>>> program quite a bit. I thought '-unsafe-remove-checks' or something 
>>>> describes it better, a bit like '-assume-single-threaded’.
>>> 
>>> I like that idea. We could add such an option.
>> 
>> awesome, that's be a +💯 from me then 🙂
>> 
>> 
>>> 
>>> Daniel, I think that’s also what you were asking for.
>>> 
>>> 
>>>> But probably the 'no checks' mode adds too much complexity to just keep it 
>>>> around for a questionable way to do performance baselines.
>>>> 
>>>>> On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev 
>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I’d like to propose to deprecate the -Ounchecked swift optimization mode.
>>>>> 
>>>>> The -Ounchecked mode actually contradicts one of the main goals of swift: 
>>>>> to be a safe language.
>>>>> In the past we didn’t see lot of significant performance differences 
>>>>> compared to -O (there were some improvements but also some regressions).
>>>>> Also, we want to reduce the effort of maintaining too many different 
>>>>> optimization modes, especially because we recently added -Osize.
>>>>> 
>>>>> Deprecating would mean that we map -Ounchecked to -O.
>>>>> 
>>>>> If you have any comments o

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

[Erik Eckstein via swift-dev]

Thanks!

> On Nov 2, 2017, at 3:26 PM, Xi Ge  wrote:
> 
> It seems my tentative fix doesn't fix this issue. As Erik suggested, I've 
> reverted the commit on master.
> 
> 
> --
> Xi
> 
> 
> 
>> On Nov 2, 2017, at 1:28 PM, Erik Eckstein > > wrote:
>> 
>> Any update on this?
>> 
>> Can you revert in the meantime if you’re not able to fix it within the next 
>> hour?
>> 
>>> On Nov 2, 2017, at 9:26 AM, Xi Ge >> > wrote:
>>> 
>>> Ack, will take a look soon.
>>> 
>>> Xi
>>> 
 On Nov 2, 2017, at 9:13 AM, Douglas Gregor >>> > wrote:
 
 Xi, this is failing in
 

 swift::syntax::SyntaxParsingContext::ContextInfo::createFromBack(swift::syntax::SyntaxKind,
  unsigned int) 
 
 which might be related to your recent changes.
 
- Doug
 
> On Nov 2, 2017, at 1:45 AM, no-re...@swift.org 
>  wrote:
> 
> [FAILURE] oss-swift-incremental-ASAN-RA-osx [#526]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/526/ 
> 
> Project:  oss-swift-incremental-ASAN-RA-osx
> Date of build:Wed, 01 Nov 2017 23:53:36 -0500
> Build duration:   3 hr 52 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 
> 
> 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 4a54f51e052df35f10c372cc72fb7f422fb2dece by daniel_dunbar:
> [Xcode] Add GTEST_NO_LLVM_RAW_OSTREAM declarations for Xcode project.
> 
> edit: llbuild.xcodeproj/project.pbxproj
> 
> Commit 26f6a751c4dc97383f35bc2d913317df15b54c15 by dgregor:
> Remove extensions on ImplicitlyUnwrappedOptional from the stdlib.
> 
> edit: stdlib/public/core/ImplicitlyUnwrappedOptional.swift
> 
> Commit 2e2c7e8dd6e3e352e51d96a89df4895da85a6bec by dgregor:
> Update tests for removal of ImplicitlyUnwrappedOptional extensions.
> 
> edit: test/IDE/complete_dynamic_lookup.swift
> edit: test/Interpreter/SDK/objc_dynamic_lookup.swift
> edit: test/IDE/print_stdlib.swift
> edit: test/Interpreter/SDK/objc_keypath.swift
> 
> Commit 094395b940fc088102fc017c9c5b02baa84e8119 by github:
> [test] Remove -whole-module-optimization from test IRGen/asmname.swift
> 
> edit: test/IRGen/asmname.swift
> 
> Commit 0d98c4c5df5ce4d50498355d2218815597c70d2d by github:
> libSyntax: Ensure round-trip printing when we build syntax tree from
> 
> edit: test/Syntax/Outputs/round_trip_parse_gen.swift.withkinds
> edit: lib/Syntax/SyntaxParsingContext.cpp
> edit: lib/Parse/Parser.cpp
> edit: include/swift/AST/Module.h
> edit: lib/Parse/ParseExpr.cpp
> edit: include/swift/Parse/Lexer.h
> edit: include/swift/Parse/Parser.h
> edit: lib/Parse/Lexer.cpp
> edit: include/swift/Syntax/SyntaxParsingContext.h
> edit: lib/Parse/ParseDecl.cpp
> edit: test/Syntax/round_trip_parse_gen.swift
 
>>> 
>> 
> 

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

Re: [swift-dev] deprecating -Ounchecked

[Erik Eckstein via swift-dev]

> On Nov 2, 2017, at 10:51 AM, Johannes Weiß  wrote:
> 
> Definitely a +1 from me, a haven't recently seen much of a difference either.
> 
> Said that I do sometimes use it in a micro-benchmark just to convince myself 
> we don't lose much performance on the checks. Usually it turns out fine, I'm 
> happy and move on. But I guess there's some value in being able to elide a 
> lot of checks just to see how much of a difference it does. And if there's a 
> big difference then I'd try to optimise the program and elide unnecessary 
> checks myself. Clearly -Ounchecked should never be used in any real code but 
> I find having a baseline when optimising performance very helpful and 
> -Ounchecked sometimes seemed like a cheap, automatic baseline for some code 
> ;).
> 
> And lastly I always thought having it as an 'optimisation' is a misnomer, 
> it's not an optimisation as it clearly changes the semantics of the program 
> quite a bit. I thought '-unsafe-remove-checks' or something describes it 
> better, a bit like '-assume-single-threaded’.

I like that idea. We could add such an option.

Daniel, I think that’s also what you were asking for.


> But probably the 'no checks' mode adds too much complexity to just keep it 
> around for a questionable way to do performance baselines.
> 
>> On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev  
>> wrote:
>> 
>> Hi,
>> 
>> I’d like to propose to deprecate the -Ounchecked swift optimization mode.
>> 
>> The -Ounchecked mode actually contradicts one of the main goals of swift: to 
>> be a safe language.
>> In the past we didn’t see lot of significant performance differences 
>> compared to -O (there were some improvements but also some regressions).
>> Also, we want to reduce the effort of maintaining too many different 
>> optimization modes, especially because we recently added -Osize.
>> 
>> Deprecating would mean that we map -Ounchecked to -O.
>> 
>> If you have any comments or concerns, please let me know
>> 
>> Thanks,
>> Erik
>> 
>> 
>> 
>> ___
>> 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: 1. OSS - Swift ASAN - OS X (master) #526

[Erik Eckstein via swift-dev]

Any update on this?

Can you revert in the meantime if you’re not able to fix it within the next 
hour?

> On Nov 2, 2017, at 9:26 AM, Xi Ge  wrote:
> 
> Ack, will take a look soon.
> 
> Xi
> 
>> On Nov 2, 2017, at 9:13 AM, Douglas Gregor > > wrote:
>> 
>> Xi, this is failing in
>> 
>>  
>> swift::syntax::SyntaxParsingContext::ContextInfo::createFromBack(swift::syntax::SyntaxKind,
>>  unsigned int) 
>> 
>> which might be related to your recent changes.
>> 
>>  - Doug
>> 
>>> On Nov 2, 2017, at 1:45 AM, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-ASAN-RA-osx [#526]
>>> 
>>> Build URL:  https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/526/ 
>>> 
>>> Project:oss-swift-incremental-ASAN-RA-osx
>>> Date of build:  Wed, 01 Nov 2017 23:53:36 -0500
>>> Build duration: 3 hr 52 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 
>>> 
>>> 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 4a54f51e052df35f10c372cc72fb7f422fb2dece by daniel_dunbar:
>>> [Xcode] Add GTEST_NO_LLVM_RAW_OSTREAM declarations for Xcode project.
>>> 
>>> edit: llbuild.xcodeproj/project.pbxproj
>>> 
>>> Commit 26f6a751c4dc97383f35bc2d913317df15b54c15 by dgregor:
>>> Remove extensions on ImplicitlyUnwrappedOptional from the stdlib.
>>> 
>>> edit: stdlib/public/core/ImplicitlyUnwrappedOptional.swift
>>> 
>>> Commit 2e2c7e8dd6e3e352e51d96a89df4895da85a6bec by dgregor:
>>> Update tests for removal of ImplicitlyUnwrappedOptional extensions.
>>> 
>>> edit: test/IDE/complete_dynamic_lookup.swift
>>> edit: test/Interpreter/SDK/objc_dynamic_lookup.swift
>>> edit: test/IDE/print_stdlib.swift
>>> edit: test/Interpreter/SDK/objc_keypath.swift
>>> 
>>> Commit 094395b940fc088102fc017c9c5b02baa84e8119 by github:
>>> [test] Remove -whole-module-optimization from test IRGen/asmname.swift
>>> 
>>> edit: test/IRGen/asmname.swift
>>> 
>>> Commit 0d98c4c5df5ce4d50498355d2218815597c70d2d by github:
>>> libSyntax: Ensure round-trip printing when we build syntax tree from
>>> 
>>> edit: test/Syntax/Outputs/round_trip_parse_gen.swift.withkinds
>>> edit: lib/Syntax/SyntaxParsingContext.cpp
>>> edit: lib/Parse/Parser.cpp
>>> edit: include/swift/AST/Module.h
>>> edit: lib/Parse/ParseExpr.cpp
>>> edit: include/swift/Parse/Lexer.h
>>> edit: include/swift/Parse/Parser.h
>>> edit: lib/Parse/Lexer.cpp
>>> edit: include/swift/Syntax/SyntaxParsingContext.h
>>> edit: lib/Parse/ParseDecl.cpp
>>> edit: test/Syntax/round_trip_parse_gen.swift
>> 
> 

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

[swift-dev] deprecating -Ounchecked

[Erik Eckstein via swift-dev]

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be 
a safe language.
In the past we didn’t see lot of significant performance differences compared 
to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different 
optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik



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

Re: [swift-dev] sharing tips and tricks and scripts

[Erik Eckstein via swift-dev]

I agree that fixing build-script is the better approach than to introduce 
another wrapper around it.

But there are many other needs for scripts, for example the (already existing) 
cmpcodesize script for comparing code size.

And I think it makes sense to create a new directory rather than putting all 
scripts into utils.


> On Oct 22, 2017, at 2:58 PM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> I agree with Jordan (and Chris) on this.  I think that we should try to 
> simplify the build process that we have rather than encouraging more build 
> script wrappers.  The current build process is pretty cumbersome which is why 
> I think that many people have wrapper scripts.  In fact, it seems that it is 
> complicated enough that we need a wrapper script officially (aka 
> build-script).  I think that we should aim to break down the pieces a bit 
> further and encourage it to be more like LLVM where even though there are 
> multiple projects, there is no need for a wrapper script, instead everything 
> works out of the box with minimal tweaks.
> 
> That said, something like Chris' idea of a bisection script seems quite 
> valuable, especially given the interdependencies between LLVM, clang, and 
> swift.
> 
> On Sat, Oct 21, 2017 at 9:10 AM, Chris Lattner via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> Any scripts should be subject to the same code review and design policies as 
> the rest of the compiler.  A bisection script or build-script seem fine, but 
> a four line script to automate something is probably not the right thing to 
> include.
> 
> -Chris
> 
> > On Oct 17, 2017, at 6:05 PM, Jordan Rose via swift-dev  > <mailto:swift-dev@swift.org>> wrote:
> >
> > I always dislike wrapper scripts because it means that people are working 
> > around undesirable behavior in a tool rather than fixing it. But that 
> > doesn't seem to be a practical answer, because people are already using 
> > wrapper scripts. (I've lost this argument several times before.)
> >
> > Jordan
> >
> >
> >> On Oct 17, 2017, at 17:25, Erik Eckstein via swift-dev 
> >> mailto:swift-dev@swift.org>> wrote:
> >>
> >> I recently had some discussions about how to share those little tips and 
> >> tricks which everyone has to make building, debugging, etc. the swift 
> >> compiler easier.
> >>
> >> And actually we already have a central place for this: it’s the docs 
> >> folder in the swift repo. Especially the DebuggingTheCompiler.rst document 
> >> contains many useful little things which might help debugging the compiler.
> >>
> >> So with this email I want to “announce” this, because I found that many 
> >> people didn’t know that.
> >> And also I’d like to encourage everyone to contribute to 
> >> DebuggingTheCompiler.rst and other documents.
> >>
> >> Another thing is that many people have implemented their own little helper 
> >> scripts for various purposes, which they share by email with others and 
> >> those emails get lost, and nobody knows what’s the latest version of a 
> >> script, etc.
> >> We have many of such scripts already in utils. But utils got already very 
> >> convoluted. So I propose to create a sub-folder, e.g. ‘dev-scripts’ to 
> >> place such scripts (just for new scripts, I’m not proposing moving 
> >> existing scripts). The intention is to keep the bar low to contribute to 
> >> dev-scripts. So scripts may be not super-polished and it’s also ok to have 
> >> multiple scripts which do similar things.
> >> Some scripts might get attention and turn out to be useful for many people 
> >> and thus get improved over time. We can eventually move such scripts out 
> >> of dev-scripts into the “production” folder utils.
> >>
> >> Please let me know if you have any comments.
> >>
> >> Thanks,
> >> Erik
> >>
> >> ___
> >> swift-dev mailing list
> >> swift-dev@swift.org <mailto:swift-dev@swift.org>
> >> https://lists.swift.org/mailman/listinfo/swift-dev 
> >> <https://lists.swift.org/mailman/listinfo/swift-dev>
> >
> > ___
> > swift-dev mailing list
> > swift-dev@swift.org <mailto:swift-dev@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-dev 
> > <https://lists.swift.org/mailman/listinfo/swift-dev>
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org <mailto:swift-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev 
> <https://lists.swift.org/mailman/listinfo/swift-dev>
> 
> 
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> ___
> 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] sharing tips and tricks and scripts

[Erik Eckstein via swift-dev]

I recently had some discussions about how to share those little tips and tricks 
which everyone has to make building, debugging, etc. the swift compiler easier.

And actually we already have a central place for this: it’s the docs folder in 
the swift repo. Especially the DebuggingTheCompiler.rst document contains many 
useful little things which might help debugging the compiler.

So with this email I want to “announce” this, because I found that many people 
didn’t know that.
And also I’d like to encourage everyone to contribute to 
DebuggingTheCompiler.rst and other documents. 

Another thing is that many people have implemented their own little helper 
scripts for various purposes, which they share by email with others and those 
emails get lost, and nobody knows what’s the latest version of a script, etc.
We have many of such scripts already in utils. But utils got already very 
convoluted. So I propose to create a sub-folder, e.g. ‘dev-scripts’ to place 
such scripts (just for new scripts, I’m not proposing moving existing scripts). 
The intention is to keep the bar low to contribute to dev-scripts. So scripts 
may be not super-polished and it’s also ok to have multiple scripts which do 
similar things.
Some scripts might get attention and turn out to be useful for many people and 
thus get improved over time. We can eventually move such scripts out of 
dev-scripts into the “production” folder utils.

Please let me know if you have any comments.

Thanks,
Erik

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

Re: [swift-dev] Reducing array abstraction

[Erik Eckstein via swift-dev]

> On Oct 9, 2017, at 9:46 PM, Chris Lattner  wrote:
> 
> On Oct 8, 2017, at 3:30 PM, Erik Eckstein  > wrote:
 We definitely already have a heap->stack for classes in the guise of the 
 StackPromotion optimization is that what you are talking about with the 
 "array outlining" optimization? (outlining to me is referring to 
 specifically code outlining). IIRC Erik (+CC) do special work to make it 
 work for fixed size array. I would ask why that optimization is not 
 kicking in for varargs. Perhaps, we could add a special recognition that 
 the given array will not escape through a varargs? Or provide some way of 
 saying, trust me this doesn't escape.
>> 
>> We already do heap->stack promotion for array buffers. This is done in the 
>> StackPromotion pass. It uses interprocedural escape analysis to check if it 
>> can be done. So if the callee is known it should work with the varargs 
>> array. BTW it also works in your example, in testAPI():
>> 
>> %1 = alloc_ref [stack] [tail_elems $Int * %0 : $Builtin.Word] 
>> $_ContiguousArrayStorage
>> 
>> But it’s not zero cost, because we initialize the metadata pointer + 
>> refcount in a runtime function. Also we do ref-count operations on the array 
>> in the callee (this will improve as soon as we have a ref count 
>> representation for immortal objects).
> 
> This is fantastic, I didn’t notice the [stack] marker there!  I’m thrilled 
> you’re on top of this.  It looks like you have a well-developed framework 
> here, which I haven’t fully ingested.  As such, I have a few questions for 
> you:
> 
> 1) With a debug build of the stdlib, the “isNative” and other sanity checks 
> in the stdlib create a lot of bridge_object_to_word -> zext to i64 -> 
> and-with-magic-arch-specific-constant checks to validate that the array is 
> properly in a native state.  Have you considered introducing a 
> “bridge_object_classify” SIL instruction which translates a bridge object 
> value into a tuple of bits (isNative, isObjC, etc)  + unbitmangled value?  It 
> seems super weird to me that there are a bunch of architecture-specific magic 
> constants in stdlib/public/core/Builtin.swift.  It seems that these should be 
> encapsulated into a SIL instruction, which would then allow the SIL optimizer 
> to eliminate these checks.  
> 
> Particularly with a debug stdlib, it is super common to see an 
> “array.uninitialized” call which then gets bitwise queried through a 
> super-verbose series of SIL instructions that are opaque to the SIL optimizer 
> (because they are arch specific).  Encapsulating this into SIL seems like a 
> good call both from putting the arch-specific bits into the SIL layer which 
> can expand it in IRGen (if it survives that long) and also optimize it away 
> in the common case when it is knowable if these bits are 0 or 1 (as when 
> coming from an array literal or other common known-native construct). 
> 
> 
> 2) You have an apparently great infra for escape analysis of arrays.  Have 
> you considered adding one more check?  If the only uses of the reference 
> counted object is a single release in the current function (common when 
> passing array literals to C functions) then you can eliminating the heap 
> allocation AND all the refcounting instructions and use a simple alloc_stack 
> (of an array of tuples?) and put the dealloc stack where the single release 
> is.  This seems like it would be a particularly bit win for the simple case 
> of things like:
> 
>   memcpy(dest, [1,2,3,4], sizeof(Int)*4) 
> 
> among others.  Because the array literal would turn into the C-equivalent 
> construct with zero overhead.
> 

Sounds like the ReleaseDevirtualizer

> 
> 3) There are other optimizations like ArrayElementValuePropagation, which 
> don’t handle the BridgeObjectToWordInst or AddressToPointer or 
> UncheckedRefCastInst, and thus give up.  This causes a number of limitations 
> (though I have no idea if they are important in practice or not): since 
> conversions to UnsafePointer cannot mutate the array, they should not prevent 
> element optimizations, count propagation optimizations, etc.

1) and 3) 
There are some discussions ongoing regarding array bridging. So things may 
change anyway.

> 
> In any case, I’m super-thrilled you and your team have been pushing this 
> forward, since arrays are really fundamental to all swift programs.

Thanks :-)

>   I’m very much looking forward to the time when we can pass borrowed array 
> slices down the stack with zero overhead.

Me, too!

> 
> -Chris
> 
> 

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

Re: [swift-dev] Reducing array abstraction

[Erik Eckstein via swift-dev]

> On Oct 8, 2017, at 3:14 PM, Chris Lattner  wrote:
> 
>> 
>> On Oct 8, 2017, at 11:57 AM, Michael Gottesman via swift-dev 
>>  wrote:
>> 
>> 
>>> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev 
>>>  wrote:
>>> 
>>> This question is somewhere between swift-dev and swift-users, not sure 
>>> where best to post this.  
>>> 
>>> I’m working on a project that wants to get very low-abstraction penalty 
>>> array operations, particularly with varargs.  Given the currently language 
>>> limitations (no fixed size arrays), the best I’ve been able to come up with 
>>> is something like this, where “lowlevelAPI” contains the heavy lifting (and 
>>> is assumed to be opaque), and the “safeAPI” wrappers exist merely to 
>>> provide a convenient safe wrapper for clients:
>>> 
>>> 
>>> 
>>> Given whole module optimization of the program, we should in principle, be 
>>> able to optimize this down to the equivalent of an LLVM array alloca in the 
>>> clients, a few stores to it, then passing the pointers to the LLVM alloca 
>>> into lowlevelAPI.  However, Swift is not doing this, not even with:
>>> 
>>> $ swiftc array_abstraction.swift -emit-sil -o - -O 
>>> 
>>> In this trivial case (with constant initializers) it does do the “array 
>>> outlining” optimization,
>> 
>> What do you mean by the array outlining optimization specifically?
> 
> I mean the "Outline global variable” thing that IPO/GlobalOpt.cpp does.  I 
> have no idea why it is called that.
> 
>> We definitely already have a heap->stack for classes in the guise of the 
>> StackPromotion optimization is that what you are talking about with the 
>> "array outlining" optimization? (outlining to me is referring to 
>> specifically code outlining). IIRC Erik (+CC) do special work to make it 
>> work for fixed size array. I would ask why that optimization is not kicking 
>> in for varargs. Perhaps, we could add a special recognition that the given 
>> array will not escape through a varargs? Or provide some way of saying, 
>> trust me this doesn't escape.

We already do heap->stack promotion for array buffers. This is done in the 
StackPromotion pass. It uses interprocedural escape analysis to check if it can 
be done. So if the callee is known it should work with the varargs array. BTW 
it also works in your example, in testAPI():

%1 = alloc_ref [stack] [tail_elems $Int * %0 : $Builtin.Word] 
$_ContiguousArrayStorage

But it’s not zero cost, because we initialize the metadata pointer + refcount 
in a runtime function. Also we do ref-count operations on the array in the 
callee (this will improve as soon as we have a ref count representation for 
immortal objects).

> 
> This is actually pretty straight-forward to fit into the existing optimizer, 
> and I’m working on a proto patch for it in my spare time this weekend.  The 
> problem is that it will only work on non-Apple systems because of the way 
> that BridgeSupport model’s the ObjC interop goop. IMO, SIL and the stdlib 
> have the wrong division of labor here.  I’ll follow up with something more 
> concrete when I have a chance.
> 
>> In terms of what Slava was talking about with copy-on-escape. That can be 
>> implemented (assuming a sane runtime ; p) by initializing any COW data 
>> structure with a count of 2. Then you are guaranteed to know that any write 
>> use or escape from the COW data structure will cause a copy. Once we have 
>> guaranteed, this comes for free since any guaranteed parameter must be 
>> copied before a mutable use.
>> 
>> I do think that you will run into issues with escaping around C APIs though.
> 
> C APIs cannot escape an array unless they have access to the refcount.  
> Beyond the SIL representational problem with bridging, what I’m getting at 
> seems like a straight-forward extension to ArrayElementValuePropagation.cpp.
> 
> -Chris

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

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

[Erik Eckstein via swift-dev]

Would it be possible that whenever a specialized class is instantiated and the 
metadata already exists with a generic vtable, it just overwrites the vtable 
pointer in the metadata with the specialized version?
I didn’t think that through, but maybe the same could be done for witness 
tables?

> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev  
> wrote:
> 
> The Swift runtime currently maintains globally unique pointer identities for 
> type metadata and protocol conformances. This makes checking type equivalence 
> a trivial pointer equality comparison, but most operations on generic values 
> do not really care about exact type identity and only need to invoke value or 
> protocol witness methods or consult other data in the type metadata 
> structure. I think it's worth reevaluating whether having globally unique 
> type metadata objects is the correct design choice. Maintaining global 
> uniqueness of metadata instances carries a number of costs. Any code that 
> wants type metadata for an instance of a generic type, even a fully concrete 
> one, must make a potentially expensive runtime call to get the canonical 
> metadata instance. This also greatly complicates our ability to emit 
> specializations of type metadata, value witness tables, or protocol witness 
> tables for concrete instances of generic types, since specializations would 
> need to be registered with the runtime as canonical metadata objects, and it 
> would be difficult to do this lazily and still reliably favor specializations 
> over more generic witnesses. The lack of witness table specializations leaves 
> an obnoxious performance cliff for instances of generic types that end up 
> inside existential containers or cross into unspecialized code. The runtime 
> also obligates binaries to provide the canonical metadata for all of their 
> public types, along with all the dependent value witnesses, class methods, 
> and protocol witness tables, meaning a type abstraction can never be 
> completely "zero-cost" across modules.
> 
> On the other hand, if type metadata did not need to be unique, then the 
> compiler would be free to emit specialized type metadata and protocol witness 
> tables for fully concrete non-concrete value types without consulting the 
> runtime. This would let us avoid runtime calls to fetch metadata in 
> specialized code, and would make it much easier for us to implement witness 
> specialization. It would also give us the ability to potentially extend the 
> "inlinable" concept to public fragile types, making it a client's 
> responsibility to emit metadata for the type when needed and keeping the type 
> from affecting its home module's ABI. This could significantly reduce the 
> size and ABI surface area of the standard library, since the standard library 
> contains a lot of generic lightweight adapter types for collections and other 
> abstractions that are intended to be optimized away in most use cases.
> 
> There are of course benefits to globally unique metadata objects that we 
> would lose if we gave up uniqueness. Operations that do check type identity, 
> such as comparison, hashing, and dynamic casting, would have to perform more 
> expensive checks, and nonunique metadata objects would need to carry 
> additional information to enable those checks. It is likely that class 
> objects would have to remain globally unique, if for no other reason than 
> that the Objective-C runtime requires it on Apple platforms. Having multiple 
> equivalent copies of type metadata has the potential to increase the working 
> set of an app in some situations, although it's likely that redundant 
> compiler-emitted copies of value type metadata would at least be able to live 
> in constant pages mapped from disk instead of getting dynamically 
> instantiated by the runtime like everything is today. There could also be 
> subtle source-breaking behavior for code that bitcasts metatype values to 
> integers or pointers and expects bit-level equality to indicate type 
> equality. It's unlikely to me that giving up uniqueness would buy us any 
> simplification to the runtime, since the runtime would still need to be able 
> to instantiate metadata for unspecialized code, and we would still want to 
> unique runtime-instantiated metadata objects as an optimization.
> 
> Overall, my intuition is that the tradeoffs come out in favor for nonunique 
> metadata objects, but what do you all think? Is there anything I'm missing?
> 
> -Joe
> ___
> 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] Question about demangling

[Erik Eckstein via swift-dev]

> On Jul 25, 2017, at 4:44 PM, Ethan Arbuckle via swift-dev 
>  wrote:
> 
> The Swift runtime exports a function to demangle Swift symbols, 
> swift_demangle. See source: 
> https://github.com/apple/swift/blob/32d15d8539c43ff26b599f7c4a08a79a10d4bf98/stdlib/public/runtime/Reflection.mm#L1200
>  
> .
> This function uses the default mangling options, as defined by 
> `Demangle::DemangleOptions()`.
> I also see there is an argument called `flags`, which I believe eventually 
> will allow demangling options to be changed. However, this is not yet 
> implemented. 
> The format for the demangled symbols with I would like it, ideally, 
> “Module.Class.Method”. The default options include a variety of other things, 
> including argument count and types. What is my best approach for getting 
> these desired demangling options? 

I think the best way is to define and implement the flags for swift_demangle.

> 
> ___
> 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] SR-5403 / Memory Optimization Opportunity (Load/Store forwarding)

[Erik Eckstein via swift-dev]

As John said, this is out of scope for swift 4.
I think it’s find to just have it in master.

Thanks again for your work!

> On Jul 25, 2017, at 10:00 AM, John McCall via swift-dev  
> wrote:
> 
> 
>> On Jul 25, 2017, at 12:55 PM, Johannes Weiß via swift-dev 
>>  wrote:
>> 
>> Thanks very much Eric & Michael for your help! And thanks for merging it. 
>> Will this automatically be part of Swift 4 or do I need to make another PR 
>> against a swift 4  branch?
> 
> It's very hard to imagine we would take any optimizer work this late for 
> Swift 4.
> 
> John.
> 
>> 
>> Thanks,
>> Johannes
>> 
>>> On 18 Jul 2017, at 9:21 pm, Johannes Weiß via swift-dev 
>>>  wrote:
>>> 
>>> great, thank you. I think I have worked all the suggestions in, let's do 
>>> the rest in this PR: https://github.com/apple/swift/pull/11040
>>> 
>>> It's getting late here so I'll probably to the test tomorrow (but marked 
>>> the patch as 'do not merge' & added that a test is still missing).
>>> 
 On 18 Jul 2017, at 7:29 pm, Erik Eckstein  wrote:
 
> 
> On Jul 18, 2017, at 10:40 AM, Johannes Weiß  
> wrote:
> 
> Thanks, both suggestions look great. Will work them in tomorrow and will 
> also try to add a test for the whole thing.
> 
>> On 18 Jul 2017, at 5:53 pm, Michael Gottesman  
>> wrote:
>> 
>>> 
>>> On Jul 18, 2017, at 8:39 AM, Johannes Weiß  
>>> wrote:
>>> 
>>> Hi Erik,
>>> 
 On 17 Jul 2017, at 10:26 pm, Erik Eckstein  wrote:
 
 Hi Johannes,
 
 great that you want to work on this!
>>> 
>>> Thanks for your help, without Michael's and your help I wouldn't have 
>>> been able to do anything here really!
>>> 
>>> 
 Some ideas:
 SideEffectAnalysis currently does not have a notion of “this argument 
 is not modified by the callee” if the callee is unknown or does 
 anything non-trivial.
 Therefore I think it’s best to put the in_guarantee check directly 
 into MemoryBehaviorVisitor::visitApplyInst():
 If the parameter convention is in_guaranteed and the parameter is V, 
 then the behavior can be MemBehavior::MayRead
>>> 
>>> 
>>> Thanks, that actually makes a lot of sense. Here's my diff right now
>>> 
>>> diff --git a/lib/SILOptimizer/Analysis/MemoryBehavior.cpp 
>>> b/lib/SILOptimizer/Analysis/MemoryBehavior.cpp
>>> index b1fe7fa665..c44cc64f94 100644
>>> --- a/lib/SILOptimizer/Analysis/MemoryBehavior.cpp
>>> +++ b/lib/SILOptimizer/Analysis/MemoryBehavior.cpp
>>> @@ -245,6 +245,23 @@ MemBehavior 
>>> MemoryBehaviorVisitor::visitApplyInst(ApplyInst *AI) {
>>>  (InspectionMode == RetainObserveKind::ObserveRetains &&
>>>   ApplyEffects.mayAllocObjects())) {
>>> Behavior = MemBehavior::MayHaveSideEffects;
 
 You should move your new code out of the if (ApplyEffects.mayReadRC() ...
 Otherwise it will not be executed if the called function does not read a 
 reference count.
 
 Beside that it looks good to me.
 
>>> +
>>> +unsigned Idx = 0;
>>> +bool AllReadOnly = false;
>>> +for (Operand &operand : AI->getArgumentOperands()) {
>>> +if (operand.get() == V && 
>>> AI->getOrigCalleeType()->getParameters()[Idx].isIndirectInGuaranteed()) 
>>> {
>>> +AllReadOnly = true;
>>> +} else {
>>> +AllReadOnly = false;
>>> +break;
>>> +}
>>> +
>>> +Idx++;
>>> +}
>>> +
>>> +if (AllReadOnly) {
>>> +Behavior = MemBehavior::MayRead;
>>> +}
>> 
>> Suggestion:
>> 
>> if (all_of(enumerate(AI->getArgumentOperands()),
>>  [&](std::pair pair) -> bool {
>> return pair.second.get() == V && 
>> AI->getOrigCalleeType()->getParameters()[Idx].isIndirectInGuaranteed()
>>  })) {
>> Behavior = MemBehavior::MayRead;
>> }
>> 
>> I may have gotten the order of the pair templates wrong. But something 
>> like this is a little cleaner.
>> 
>> Michael
>> 
>>> } else {
>>> auto &GlobalEffects = ApplyEffects.getGlobalEffects();
>>> Behavior = GlobalEffects.getMemBehavior(InspectionMode);
>>> 
>>> which indeed turns
>>> 
>>> --- SNIP ---
>>> sil @bar : $@convention(thin) (@in Int) -> () {
>>> bb0(%0 : $*Int):
>>> %value_raw = integer_literal $Builtin.Int64, 42
>>> %value = struct $Int (%value_raw : $Builtin.Int64)
>>> store %value to %0 : $*Int
>>> 
>>> %f_buz = function_ref @buz : $@convention(thin) (@in_guaranteed Int) -> 
>>> ()
>>> %r1 = apply %f_buz(%0) : $@convention(thin) (@in_guaranteed Int) -> ()
>>> 
>>> %value_again = load %0 : $*Int
>>> %f_test = function_ref @test : $@convention(thin) (Int) -> ()
>>> %r2 = apply %f_test(%value_again) : $@convention(thin) 

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.04 (master) #1393

[Erik Eckstein via swift-dev]

This is a “no space left on device” issue

> On Jul 21, 2017, at 5:18 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-16_04 [#1393]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_04/1393/ 
> 
> Project:  oss-swift-package-linux-ubuntu-16_04
> Date of build:Fri, 21 Jul 2017 15:36:19 -0700
> Build duration:   1 hr 42 min
> 
> Changes
> 
> Commit 1504c2ede77bd14a81f41e09f6cb283e82890eba by David Zarzycki:
> [QoI] Ignore implicit conversions during mutation diagnostics
> 
> edit: test/Parse/pointer_conversion.swift.gyb
> edit: test/Parse/pointer_conversion_objc.swift.gyb
> edit: lib/Sema/CSDiag.cpp
> 
> Commit f88287399611f23e276f37dbab605dbe6fbf6fb4 by David Zarzycki:
> [Sema] NFC: Remove dead code
> 
> edit: lib/Sema/CSGen.cpp
> 
> Commit 3b54966ff27c0e61e8deabf03f2b676b7fef3c7e by Erik Eckstein:
> SILOptimizer: Add a utility to find dead-end blocks.
> 
> edit: include/swift/SILOptimizer/Utils/Local.h
> edit: lib/SILOptimizer/Utils/Local.cpp
> 
> Commit a0e6082d25a34b3b85d31f0de2fad9e4b4538288 by Erik Eckstein:
> SILOptimizer: change the way how ValueLifetimeAnalysis handles dead-end
> 
> edit: include/swift/SILOptimizer/Utils/Local.h
> edit: lib/SILOptimizer/Utils/Local.cpp
> edit: lib/SILOptimizer/Transforms/DeadObjectElimination.cpp
> 
> Commit f561176f145f49c3d959f06ffc9bb2d6c5c4f8f1 by Erik Eckstein:
> EsacpeAnalysis: add a utility to get the list of use-points of a node
> 
> edit: include/swift/SILOptimizer/Analysis/EscapeAnalysis.h
> edit: lib/SILOptimizer/Analysis/EscapeAnalysis.cpp
> 
> Commit 580332b06246a1a59c41ec93ac0b4710f0ab277e by Itai Ferber:
> Rename encodeWeak to encodeConditional
> 
> edit: stdlib/public/core/Codable.swift
> 
> Commit ec5a92fd04f99d163fcfe860a7cc481d8af677cc by Michael Gottesman:
> Disable some tests this time for real.
> 
> edit: 
> validation-test/stdlib/Array/Array_RangeReplaceableRandomAccessCollectionVal.swift
> edit: test/lit.site.cfg.in
> edit: 
> validation-test/stdlib/Array/ArraySlice_RangeReplaceableRandomAccessCollectionRef.swift
> edit: 
> validation-test/stdlib/Array/Array_MutableRandomAccessCollectionVal.swift
> edit: stdlib/private/StdlibUnittest/CMakeLists.txt
> edit: 
> validation-test/stdlib/Array/ArraySliceWithNonZeroStartIndex_MutableRandomAccessCollectionVal.swift
> edit: 
> validation-test/stdlib/Array/Array_MutableRandomAccessCollectionRef.swift
> edit: 
> validation-test/stdlib/Array/ArraySliceWithNonZeroStartIndex_RangeReplaceableRandomAccessCollectionVal.swift
> edit: 
> validation-test/stdlib/Array/ContiguousArray_MutableRandomAccessCollectionRef.swift
> edit: 
> validation-test/stdlib/Array/ArraySliceWithNonZeroStartIndex_RangeReplaceableRandomAccessCollectionRef.swift
> edit: 
> validation-test/stdlib/Array/ContiguousArray_RangeReplaceableRandomAccessCollectionVal.swift
> edit: 
> validation-test/stdlib/Array/ArraySliceWithNonZeroStartIndex_MutableRandomAccessCollectionRef.swift
> edit: 
> validation-test/stdlib/Array/ContiguousArray_RangeReplaceableRandomAccessCollectionRef.swift
> edit: 
> validation-test/stdlib/Array/ArraySlice_RangeReplaceableRandomAccessCollectionVal.swift
> edit: validation-test/stdlib/Array/Inputs/ArrayConformanceTests.swift.gyb
> edit: 
> validation-test/stdlib/Array/ArraySlice_MutableRandomAccessCollectionVal.swift
> edit: 
> validation-test/stdlib/Array/Array_RangeReplaceableRandomAccessCollectionRef.swift
> edit: 
> validation-test/stdlib/Array/ArraySlice_MutableRandomAccessCollectionRef.swift
> edit: 
> validation-test/stdlib/Array/ContiguousArray_MutableRandomAccessCollectionVal.swift
> 
> Commit f59c1e4438fbbacd54c2da14b4f25ca52f3d8024 by Erik Eckstein:
> StackPromotion: a big simplification of the algorithm
> 
> edit: test/SILOptimizer/stack_promotion.sil
> edit: test/SILOptimizer/opened_archetype_operands_tracking.sil
> edit: lib/SILOptimizer/Transforms/StackPromotion.cpp
> edit: test/SILOptimizer/devirt_covariant_return.swift
> 
> Commit 37f88e73722c3949f9c13274d365be105d13728a by github:
> Add frontend flag to serialize Syntax tree (#11095)
> 
> edit: include/swift/Option/FrontendOptions.td
> edit: lib/Frontend/FrontendOptions.cpp
> add: test/Frontend/emit-syntax.swift
> edit: include/swift/Frontend/FrontendOptions.h
> edit: lib/Driver/Driver.cpp
> edit: lib/Frontend/CompilerInvocation.cpp
> edit: lib/FrontendTool/FrontendTool.cpp
> 
> Commit 001ca41731bd882e921cb47499edad0bb821c103 by Slava Pestov:
> [Swift] Add a comment
> 
> edit: 
> packages/Python/lldbsuite/test/lang/swift/variables/inout/TestInOutVariables.py
> 
> Commit f308040d78e1e2c9503948a4d8c67a718e38cd63 by Slava Pestov:
> [Swift] Fix regression from previous patch
> 
> edit: source/Target/SwiftLanguageRuntime.cpp
> 
> Commit b628679fb089d2568707db55cea2983adda7df4f by Slava Pestov:
> [Swift] Add missing 'case' to switch
> 
> edit: source/Symbol/SwiftASTContext.cpp
> 
> Commit 2c04609dfb9cfaed97a7ce2571

Re: [swift-dev] SR-5403 / Memory Optimization Opportunity (Load/Store forwarding)

[Erik Eckstein via swift-dev]

> On Jul 18, 2017, at 10:40 AM, Johannes Weiß  wrote:
> 
> Thanks, both suggestions look great. Will work them in tomorrow and will also 
> try to add a test for the whole thing.
> 
>> On 18 Jul 2017, at 5:53 pm, Michael Gottesman  wrote:
>> 
>>> 
>>> On Jul 18, 2017, at 8:39 AM, Johannes Weiß  wrote:
>>> 
>>> Hi Erik,
>>> 
 On 17 Jul 2017, at 10:26 pm, Erik Eckstein  wrote:
 
 Hi Johannes,
 
 great that you want to work on this!
>>> 
>>> Thanks for your help, without Michael's and your help I wouldn't have been 
>>> able to do anything here really!
>>> 
>>> 
 Some ideas:
 SideEffectAnalysis currently does not have a notion of “this argument is 
 not modified by the callee” if the callee is unknown or does anything 
 non-trivial.
 Therefore I think it’s best to put the in_guarantee check directly into 
 MemoryBehaviorVisitor::visitApplyInst():
 If the parameter convention is in_guaranteed and the parameter is V, then 
 the behavior can be MemBehavior::MayRead
>>> 
>>> 
>>> Thanks, that actually makes a lot of sense. Here's my diff right now
>>> 
>>> diff --git a/lib/SILOptimizer/Analysis/MemoryBehavior.cpp 
>>> b/lib/SILOptimizer/Analysis/MemoryBehavior.cpp
>>> index b1fe7fa665..c44cc64f94 100644
>>> --- a/lib/SILOptimizer/Analysis/MemoryBehavior.cpp
>>> +++ b/lib/SILOptimizer/Analysis/MemoryBehavior.cpp
>>> @@ -245,6 +245,23 @@ MemBehavior 
>>> MemoryBehaviorVisitor::visitApplyInst(ApplyInst *AI) {
>>> (InspectionMode == RetainObserveKind::ObserveRetains &&
>>>  ApplyEffects.mayAllocObjects())) {
>>>   Behavior = MemBehavior::MayHaveSideEffects;

You should move your new code out of the if (ApplyEffects.mayReadRC() ...
Otherwise it will not be executed if the called function does not read a 
reference count.

Beside that it looks good to me.

>>> +
>>> +unsigned Idx = 0;
>>> +bool AllReadOnly = false;
>>> +for (Operand &operand : AI->getArgumentOperands()) {
>>> +if (operand.get() == V && 
>>> AI->getOrigCalleeType()->getParameters()[Idx].isIndirectInGuaranteed()) {
>>> +AllReadOnly = true;
>>> +} else {
>>> +AllReadOnly = false;
>>> +break;
>>> +}
>>> +
>>> +Idx++;
>>> +}
>>> +
>>> +if (AllReadOnly) {
>>> +Behavior = MemBehavior::MayRead;
>>> +}
>> 
>> Suggestion:
>> 
>> if (all_of(enumerate(AI->getArgumentOperands()),
>> [&](std::pair pair) -> bool {
>>return pair.second.get() == V && 
>> AI->getOrigCalleeType()->getParameters()[Idx].isIndirectInGuaranteed()
>> })) {
>>  Behavior = MemBehavior::MayRead;
>> }
>> 
>> I may have gotten the order of the pair templates wrong. But something like 
>> this is a little cleaner.
>> 
>> Michael
>> 
>>> } else {
>>>   auto &GlobalEffects = ApplyEffects.getGlobalEffects();
>>>   Behavior = GlobalEffects.getMemBehavior(InspectionMode);
>>> 
>>> which indeed turns
>>> 
>>> --- SNIP ---
>>> sil @bar : $@convention(thin) (@in Int) -> () {
>>> bb0(%0 : $*Int):
>>> %value_raw = integer_literal $Builtin.Int64, 42
>>> %value = struct $Int (%value_raw : $Builtin.Int64)
>>> store %value to %0 : $*Int
>>> 
>>> %f_buz = function_ref @buz : $@convention(thin) (@in_guaranteed Int) -> ()
>>> %r1 = apply %f_buz(%0) : $@convention(thin) (@in_guaranteed Int) -> ()
>>> 
>>> %value_again = load %0 : $*Int
>>> %f_test = function_ref @test : $@convention(thin) (Int) -> ()
>>> %r2 = apply %f_test(%value_again) : $@convention(thin) (Int) -> ()
>>> 
>>> /*
>>> %f_bad = function_ref @bad : $@convention(thin) (@in_guaranteed Int) -> ()
>>> %r3 = apply %f_bad(%0) : $@convention(thin) (@in_guaranteed Int) -> ()
>>> 
>>> %value_again2 = load %0 : $*Int
>>> %r4 = apply %f_test(%value_again2) : $@convention(thin) (Int) -> ()
>>> */
>>> 
>>> % = tuple()
>>> return % : $()
>>> }
>>> --- SNAP ---
>>> 
>>> into
>>> 
>>> --- SNIP ---
>>> bb0(%0 : $*Int):
>>> %1 = integer_literal $Builtin.Int64, 42 // user: %2
>>> %2 = struct $Int (%1 : $Builtin.Int64)  // users: %7, %3
>>> store %2 to %0 : $*Int  // id: %3
>>> // function_ref buz
>>> %4 = function_ref @buz : $@convention(thin) (@in_guaranteed Int) -> () // 
>>> user: %5
>>> %5 = apply %4(%0) : $@convention(thin) (@in_guaranteed Int) -> ()
>>> // function_ref test
>>> %6 = function_ref @test : $@convention(thin) (Int) -> () // user: %7
>>> %7 = apply %6(%2) : $@convention(thin) (Int) -> ()
>>> %8 = tuple ()   // user: %9
>>> return %8 : $() // id: %9
>>> } // end sil function 'bar'
>>> --- SNAP ---
>>> 
>>> so the load has successfully been eliminated. Also taking my initial repro 
>>> [1], the retain, the load, and the release are now gone 😃.
>>> 
>>> Is that roughly what you were thinking of?
>>> 
>>> Many thanks,
>>> Johannes
>>> 
>>> [1]: https://bugs.swift.org/secure/attachment/12378/test.swift
>>> 
 
 Erik
 
> On Jul 17, 201

Re: [swift-dev] SR-5403 / Memory Optimization Opportunity (Load/Store forwarding)

[Erik Eckstein via swift-dev]

Hi Johannes,

great that you want to work on this!

Some ideas:
SideEffectAnalysis currently does not have a notion of “this argument is not 
modified by the callee” if the callee is unknown or does anything non-trivial.
Therefore I think it’s best to put the in_guarantee check directly into 
MemoryBehaviorVisitor::visitApplyInst():
If the parameter convention is in_guaranteed and the parameter is V, then the 
behavior can be MemBehavior::MayRead

Erik

> On Jul 17, 2017, at 9:23 AM, Johannes Weiß  wrote:
> 
> Thanks Michael!
> 
> Erik, I hope what I wrote makes some sense. Any questions or suggestions, 
> please let me know.
> 
>> On 14 Jul 2017, at 7:30 pm, Michael Gottesman  wrote:
>> 
>>> 
>>> On Jul 12, 2017, at 9:53 AM, Johannes Weiß  wrote:
>>> 
>>> Hi Michael,
>>> 
>>> 
 [...]
> Long story short, I think the RLE actually works for the test case I 
> created. It's even clever enough to see through my invalid function bad() 
> which modified the storage despite its claim that it doesn't. I might 
> also be misunderstanding something.
 
 When something is marked as in_guaranteed, it should be immutable. If the 
 callee violates that, then the SIL is malformed. Perhaps, we can add some 
 sort of verification check.
>>> 
>>> Right, yes I was aware that that'd be illegal but I added it as a way to 
>>> check whether this optimisation is 'looking into' the called function.
>>> 
>>> 
 That being said, I have a good feeling that there is some sort of analysis 
 occuring here since you provided enough information to the optimizer. The 
 optimization here is regardless of whether or not we can see the body of a 
 function, we know that it is safe to optimize this just based off the 
 @in_guaranteed. This implies using a declaration, not a definition of the 
 bad function.
>>> 
>>> makes sense, didn't think about just only declaring it...
>>> 
>>> 
 When I said write the SIL by hand, what I meant was writing the whole 
 program by hand. In general, we prefer SIL programs that do not have 
 extraneous stuff that is added by the compiler (for instance debug_value). 
 Additionally, it is important for SIL files to not have dependencies on 
 the stdlib unless absolutely necessary (i.e. your usage of Int). This 
 prevents the stdlib maintainers from having to update these tests given 
 chances to the stdlib. Below is a cleaned up version that shows the 
 problem. Look at how small it is and how it tests /exactly/ what we are 
 trying to test and via the use of declarations and the like we are able to 
 exclude other optimizations:
>>> 
>>> That makes a lot of sense, thank you. I wasn't yet that familiar with SIL 
>>> so I thought I start from a program generated by the compiler and then 
>>> replace the guts with handwritten SIL. But your version is clearly a lot 
>>> easier to understand and shows what precisely we want to see!
>>> 
>>> Today, I looked into why this is happening more precisely.
>>> 
>>> So we don't get the RLE because in this code
>>> 
>>> if (isComputeAvailValue(Kind) || isPerformingRLE(Kind)) {
>>>  for (unsigned i = 0; i < Locs.size(); ++i) {
>>>if (isTrackingLocation(ForwardSetIn, Ctx.getLocationBit(Locs[i])))
>>>  continue;
>>>updateForwardSetAndValForRead(Ctx, Ctx.getLocationBit(Locs[i]),
>>>  Ctx.getValueBit(Vals[i]));
>>>// We can not perform the forwarding as we are at least missing
>>>// some pieces of the read location.
>>>CanForward = false;
>>> 
>>> (https://github.com/apple/swift/blob/86620aaa7ebd32d33f4cdf61add5c63a72d3f02a/lib/SILOptimizer/Transforms/RedundantLoadElimination.cpp#L917)
>>> 
>>> we're not taking the `continue` for the call to `buz()`. The reason why is 
>>> that here
>>> 
>>>  if (!AA->mayWriteToMemory(I, R.getBase()))
>>>continue;
>>>  // MayAlias.
>>>  stopTrackingLocation(ForwardSetIn, i);
>>>  stopTrackingValue(ForwardValIn, i);
>>> 
>>> (https://github.com/apple/swift/blob/86620aaa7ebd32d33f4cdf61add5c63a72d3f02a/lib/SILOptimizer/Transforms/RedundantLoadElimination.cpp#L972)
>>> 
>>> we're not taking the `continue`, ie. `AA->mayWriteToMemory(I, R.getBase())` 
>>> is true. The reason for that is that the `SILFunction` for `buz` has
>>> 
>>> EffectsKindAttr = Unspecified
>>> 
>>> which equates to `MayHaveSideEffects`, that's also what 
>>> `-debug-only=sil-redundant-load-elim,sil-membehavior` outputs:
>>> 
>>> GET MEMORY BEHAVIOR FOR:
>>>%5 = apply %4(%0) : $@convention(thin) (@in_guaranteed Int) -> ()
>>>%0 = argument of bb0 : $*Int// users: %6, %5, %3
>>> Found apply, returning MayHaveSideEffects
>>> 
>>> 
>>> So where I'm stuck today is that I'm not sure how `EffectsKindAttr` is 
>>> actually defined. Sure, `$@convention(thin) (@in_guaranteed Int) -> ()` 
>>> doesn't actually write to the `@in_guaranteed Int` (as that'd be illegal) 
>>> but it may have other side effects. So I

Re: [swift-dev] Name mangling of subscripts

[Erik Eckstein via swift-dev]

> On Jul 14, 2017, at 12:02 PM, John McCall  wrote:
> 
>> On Jul 14, 2017, at 6:41 AM, Alex Hoppen via swift-dev > > wrote:
>> Hi all,
>> 
>> With a recent change of mine (#9989 
>> ) subscripts are no longer 
>> represented internally by the identifier "subscript" but by a DeclBaseName 
>> with a special flag. In name mangling, however, the string "subscript" still 
>> surfaces (e.g. _T04test3FooC9subscriptyycfg). I think that we should use a 
>> special flag here instead, similar to "fC" for constructors or "fD" for 
>> destructors.

Yes, for example ‘fS’ would work.

>> I don't know much about the mangling and which considerations need to be 
>> taken here though, so: Would this be a change that is worth doing, even 
>> though it gives no immediate benefit? If yes, could someone assist me with 
>> the design work of choosing the right mangling scheme or take over the 
>> issue? Or should I just file a JIRA for it, assign it the label "AffectsABI" 
>> and wait for someone to pick it up as the ABI gets stabilised?
> 
> Filing a bug seems appropriate.  If you'd like to also volunteer to fix that 
> bug, that would be great. :)  I agree that we should use a special name in 
> the mangling here, and I disagree that it gives no immediate benefit: if 
> nothing else, it reduces the symbol size by a few bytes.

If you like to implement it yourself, I’m happy to assist you.

> 
> The only consideration is making sure that the mangling doesn't collide with 
> some other identifier.  Erik (CC'ed) probably has thoughts about that, 
> although he's on vacation until Monday.
> 
> John.

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

Re: [swift-dev] statically initialized arrays

[Erik Eckstein via swift-dev]

> On Jun 19, 2017, at 8:53 AM, Joe Groff  wrote:
> 
>> 
>> On Jun 14, 2017, at 11:24 AM, Erik Eckstein via swift-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I’m about implementing statically initialized arrays. It’s about allocating 
>> storage for arrays in the data section rather than on the heap.
>> 
>> Info: the array storage is a heap object. So in the following I’m using the 
>> general term “object” but the optimization will (probably) only handle array 
>> buffers.
>> 
>> This optimization can be done for array literals containing only other 
>> literals as elements.
>> Example:
>> 
>> func createArray() -> [Int] {
>>  return [1, 2, 3]
>> }
>> 
>> The compiler can allocate the whole array buffer as a statically initialized 
>> global llvm-variable with a reference count of 2 to make it immortal.
>> It avoids heap allocations for array literals in cases stack-promotion can’t 
>> kick in. It also saves code size.
>> 
>> What’s needed for this optimization?
>> 
>> 1) An optimization pass (GlobalOpt) which detects such array literal 
>> initialization patterns and “outlines” those into a statically initialized 
>> global variable
>> 2) A representation of statically initialized global variables in SIL
>> 3) IRGen to create statically initialized objects as global llvm-variables
>> 
>> ad 2) Changes in SIL:
>> 
>> Currently a static initialized sil_global is represented by having a 
>> reference to a globalinit function which has to match a very specific 
>> pattern (e.g. must contain a single store to the global).
>> This is somehow quirky and would get even more complicated for statically 
>> initialized objects.
>> 
>> I’d like to change that so that the sil_global itself contains the 
>> initialization value.
>> This part is not yet related to statically initialized objects. It just 
>> improves the representation of statically initialized global in general.
>> 
>> @@ -1210,7 +1210,9 @@ Global Variables
>> ::
>> 
>>   decl ::= sil-global-variable
>> +  static-initializer ::= '{' sil-instruction-def* '}'
>>   sil-global-variable ::= 'sil_global' sil-linkage identifier ':' sil-type
>> + (static-initializer)?
>> 
>> SIL representation of a global variable.
>> 
>> @@ -1221,6 +1223,19 @@ SIL instructions. Prior to performing any access on 
>> the global, the
>> Once a global's storage has been initialized, ``global_addr`` is used to
>> project the value.
>> 
>> +A global can also have a static initializer if it's initial value can be
>> +composed of literals. The static initializer is represented as a list of
>> +literal and aggregate instructions where the last instruction is the 
>> top-level
>> +value of the static initializer::
>> +
>> +  sil_global hidden @_T04test3varSiv : $Int {
>> +%0 = integer_literal $Builtin.Int64, 27
>> +%1 = struct $Int (%0 : $Builtin.Int64)
>> +  }
>> +
>> +In case a global has a static initializer, no ``alloc_global`` is needed 
>> before
>> +it can be accessed.
>> +
>> 
>> Now to represent a statically initialized object, we need a new instruction. 
>> Note that this “instruction" can only appear in the initializer of a 
>> sil_global.
>> 
>> +object
>> +``
>> +::
>> +
>> +  sil-instruction ::= 'object' sil-type '(' (sil-operand (',' 
>> sil-operand)*)? ')'
>> +
>> +  object $T (%a : $A, %b : $B, ...)
>> +  // $T must be a non-generic or bound generic reference type
>> +  // The first operands must match the stored properties of T
>> +  // Optionally there may be more elements, which are tail-allocated to T
>> +
>> +Constructs a statically initialized object. This instruction can only appear
>> +as final instruction in a global variable static initializer list.
>> 
>> Finally we need an instruction to use such a statically initialized global 
>> object.
>> 
>> +global_object
>> +`
>> +::
>> +
>> +  sil-instruction ::= 'global_object' sil-global-name ':' sil-type
>> +
>> +  %1 = global_object @v : $T
>> +  // @v must be a global variable with a static initialized object
>> +  // $T must be a reference type
>> +
>> +Creates a reference to the address of a global variable which has a static
>> +initializer which is an object, i.e. the last inst

Re: [swift-dev] statically initialized arrays

[Erik Eckstein via swift-dev]

> On Jun 14, 2017, at 4:04 PM, Michael Gottesman  wrote:
> 
>> 
>> On Jun 14, 2017, at 11:24 AM, Erik Eckstein via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Hi,
>> 
>> I’m about implementing statically initialized arrays. It’s about allocating 
>> storage for arrays in the data section rather than on the heap.
>> 
>> Info: the array storage is a heap object. So in the following I’m using the 
>> general term “object” but the optimization will (probably) only handle array 
>> buffers.
>> 
>> This optimization can be done for array literals containing only other 
>> literals as elements.
>> Example:
>> 
>> func createArray() -> [Int] {
>>   return [1, 2, 3]
>> }
>> 
>> The compiler can allocate the whole array buffer as a statically initialized 
>> global llvm-variable with a reference count of 2 to make it immortal.
> 
> I was thinking about this a little bit. IMO, we probably actually want a bit 
> in the header. The reason why is that even though setting the ref count to be 
> unbalanced makes an object immortal, retain/release will still modify the 
> reference count meaning that the statically initialized constant can not be 
> in read only memory. On the other hand, if we had a bit in the header, we 
> could use read only memory.

Except that we currently have no way to initialize the object header other than 
through a runtime call.

> 
> Michael
> 
>> It avoids heap allocations for array literals in cases stack-promotion can’t 
>> kick in. It also saves code size.
>> 
>> What’s needed for this optimization?
>> 
>> 1) An optimization pass (GlobalOpt) which detects such array literal 
>> initialization patterns and “outlines” those into a statically initialized 
>> global variable
>> 2) A representation of statically initialized global variables in SIL
>> 3) IRGen to create statically initialized objects as global llvm-variables
>> 
>> ad 2) Changes in SIL:
>> 
>> Currently a static initialized sil_global is represented by having a 
>> reference to a globalinit function which has to match a very specific 
>> pattern (e.g. must contain a single store to the global).
>> This is somehow quirky and would get even more complicated for statically 
>> initialized objects.
>> 
>> I’d like to change that so that the sil_global itself contains the 
>> initialization value.
>> This part is not yet related to statically initialized objects. It just 
>> improves the representation of statically initialized global in general.
>> 
>> @@ -1210,7 +1210,9 @@ Global Variables
>>  ::
>>  
>>decl ::= sil-global-variable
>> +  static-initializer ::= '{' sil-instruction-def* '}'
>>sil-global-variable ::= 'sil_global' sil-linkage identifier ':' sil-type
>> + (static-initializer)?
>>  
>>  SIL representation of a global variable.
>>  
>> @@ -1221,6 +1223,19 @@ SIL instructions. Prior to performing any access on 
>> the global, the
>>  Once a global's storage has been initialized, ``global_addr`` is used to
>>  project the value.
>>  
>> +A global can also have a static initializer if it's initial value can be
>> +composed of literals. The static initializer is represented as a list of
>> +literal and aggregate instructions where the last instruction is the 
>> top-level
>> +value of the static initializer::
>> +
>> +  sil_global hidden @_T04test3varSiv : $Int {
>> +%0 = integer_literal $Builtin.Int64, 27
>> +%1 = struct $Int (%0 : $Builtin.Int64)
>> +  }
>> +
>> +In case a global has a static initializer, no ``alloc_global`` is needed 
>> before
>> +it can be accessed.
>> +
>> 
>> Now to represent a statically initialized object, we need a new instruction. 
>> Note that this “instruction" can only appear in the initializer of a 
>> sil_global.
>> 
>> +object
>> +``
>> +::
>> +
>> +  sil-instruction ::= 'object' sil-type '(' (sil-operand (',' 
>> sil-operand)*)? ')'
>> +
>> +  object $T (%a : $A, %b : $B, ...)
>> +  // $T must be a non-generic or bound generic reference type
>> +  // The first operands must match the stored properties of T
>> +  // Optionally there may be more elements, which are tail-allocated to T
>> +
>> +Constructs a statically initialized object. This instruction can only appear
>> +as final instruction in a global variable static initia

Re: [swift-dev] statically initialized arrays

[Erik Eckstein via swift-dev]

> On Jun 14, 2017, at 12:03 PM, Jordan Rose  wrote:
> 
> 
> 
>> On Jun 14, 2017, at 11:24, Erik Eckstein via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> Hi,
>> 
>> I’m about implementing statically initialized arrays. It’s about allocating 
>> storage for arrays in the data section rather than on the heap.
>> 
>> Info: the array storage is a heap object. So in the following I’m using the 
>> general term “object” but the optimization will (probably) only handle array 
>> buffers.
>> 
>> This optimization can be done for array literals containing only other 
>> literals as elements.
>> Example:
>> 
>> func createArray() -> [Int] {
>>   return [1, 2, 3]
>> }
>> 
>> The compiler can allocate the whole array buffer as a statically initialized 
>> global llvm-variable with a reference count of 2 to make it immortal.
>> It avoids heap allocations for array literals in cases stack-promotion can’t 
>> kick in. It also saves code size.
>> 
>> What’s needed for this optimization?
>> 
>> 1) An optimization pass (GlobalOpt) which detects such array literal 
>> initialization patterns and “outlines” those into a statically initialized 
>> global variable
>> 2) A representation of statically initialized global variables in SIL
>> 3) IRGen to create statically initialized objects as global llvm-variables
>> 
>> ad 2) Changes in SIL:
>> 
>> Currently a static initialized sil_global is represented by having a 
>> reference to a globalinit function which has to match a very specific 
>> pattern (e.g. must contain a single store to the global).
>> This is somehow quirky and would get even more complicated for statically 
>> initialized objects.
>> 
>> I’d like to change that so that the sil_global itself contains the 
>> initialization value.
>> This part is not yet related to statically initialized objects. It just 
>> improves the representation of statically initialized global in general.
>> 
>> @@ -1210,7 +1210,9 @@ Global Variables
>>  ::
>>  
>>decl ::= sil-global-variable
>> +  static-initializer ::= '{' sil-instruction-def* '}'
>>sil-global-variable ::= 'sil_global' sil-linkage identifier ':' sil-type
>> + (static-initializer)?
>>  
>>  SIL representation of a global variable.
>>  
>> @@ -1221,6 +1223,19 @@ SIL instructions. Prior to performing any access on 
>> the global, the
>>  Once a global's storage has been initialized, ``global_addr`` is used to
>>  project the value.
>>  
>> +A global can also have a static initializer if it's initial value can be
>> +composed of literals. The static initializer is represented as a list of
>> +literal and aggregate instructions where the last instruction is the 
>> top-level
>> +value of the static initializer::
>> +
>> +  sil_global hidden @_T04test3varSiv : $Int {
>> +%0 = integer_literal $Builtin.Int64, 27
>> +%1 = struct $Int (%0 : $Builtin.Int64)
>> +  }
>> +
>> +In case a global has a static initializer, no ``alloc_global`` is needed 
>> before
>> +it can be accessed.
>> +
>> 

I just talked to MichaelG in person. He pointed out that the static initializer 
should not look like a function. Also the implicit convention that the last 
value is the actual top-level value is not obvious.
I think it makes sense to add some syntactic sugar to make this more clear 
(adding ‘=‘ and ‘init_value’):

+  sil_global hidden @_T04test3varSiv : $Int = {
+%0 = integer_literal $Builtin.Int64, 27
+init_value = struct $Int (%0 : $Builtin.Int64)
+  }



>> Now to represent a statically initialized object, we need a new instruction. 
>> Note that this “instruction" can only appear in the initializer of a 
>> sil_global.
>> 
>> +object
>> +``
>> +::
>> +
>> +  sil-instruction ::= 'object' sil-type '(' (sil-operand (',' 
>> sil-operand)*)? ')'
>> +
>> +  object $T (%a : $A, %b : $B, ...)
>> +  // $T must be a non-generic or bound generic reference type
>> +  // The first operands must match the stored properties of T
>> +  // Optionally there may be more elements, which are tail-allocated to T
>> +
>> +Constructs a statically initialized object. This instruction can only appear
>> +as final instruction in a global variable static initializer list.
>> 
>> Finally we need an instruction to use such a statically initialized global 
>>

[swift-dev] statically initialized arrays

[Erik Eckstein via swift-dev]

Hi,

I’m about implementing statically initialized arrays. It’s about allocating 
storage for arrays in the data section rather than on the heap.

Info: the array storage is a heap object. So in the following I’m using the 
general term “object” but the optimization will (probably) only handle array 
buffers.

This optimization can be done for array literals containing only other literals 
as elements.
Example:

func createArray() -> [Int] {
  return [1, 2, 3]
}

The compiler can allocate the whole array buffer as a statically initialized 
global llvm-variable with a reference count of 2 to make it immortal.
It avoids heap allocations for array literals in cases stack-promotion can’t 
kick in. It also saves code size.

What’s needed for this optimization?

1) An optimization pass (GlobalOpt) which detects such array literal 
initialization patterns and “outlines” those into a statically initialized 
global variable
2) A representation of statically initialized global variables in SIL
3) IRGen to create statically initialized objects as global llvm-variables

ad 2) Changes in SIL:

Currently a static initialized sil_global is represented by having a reference 
to a globalinit function which has to match a very specific pattern (e.g. must 
contain a single store to the global).
This is somehow quirky and would get even more complicated for statically 
initialized objects.

I’d like to change that so that the sil_global itself contains the 
initialization value.
This part is not yet related to statically initialized objects. It just 
improves the representation of statically initialized global in general.

@@ -1210,7 +1210,9 @@ Global Variables
 ::
 
   decl ::= sil-global-variable
+  static-initializer ::= '{' sil-instruction-def* '}'
   sil-global-variable ::= 'sil_global' sil-linkage identifier ':' sil-type
+ (static-initializer)?
 
 SIL representation of a global variable.
 
@@ -1221,6 +1223,19 @@ SIL instructions. Prior to performing any access on the 
global, the
 Once a global's storage has been initialized, ``global_addr`` is used to
 project the value.
 
+A global can also have a static initializer if it's initial value can be
+composed of literals. The static initializer is represented as a list of
+literal and aggregate instructions where the last instruction is the top-level
+value of the static initializer::
+
+  sil_global hidden @_T04test3varSiv : $Int {
+%0 = integer_literal $Builtin.Int64, 27
+%1 = struct $Int (%0 : $Builtin.Int64)
+  }
+
+In case a global has a static initializer, no ``alloc_global`` is needed before
+it can be accessed.
+

Now to represent a statically initialized object, we need a new instruction. 
Note that this “instruction" can only appear in the initializer of a sil_global.

+object
+``
+::
+
+  sil-instruction ::= 'object' sil-type '(' (sil-operand (',' sil-operand)*)? 
')'
+
+  object $T (%a : $A, %b : $B, ...)
+  // $T must be a non-generic or bound generic reference type
+  // The first operands must match the stored properties of T
+  // Optionally there may be more elements, which are tail-allocated to T
+
+Constructs a statically initialized object. This instruction can only appear
+as final instruction in a global variable static initializer list.

Finally we need an instruction to use such a statically initialized global 
object.

+global_object
+`
+::
+
+  sil-instruction ::= 'global_object' sil-global-name ':' sil-type
+
+  %1 = global_object @v : $T
+  // @v must be a global variable with a static initialized object
+  // $T must be a reference type
+
+Creates a reference to the address of a global variable which has a static
+initializer which is an object, i.e. the last instruction of the global's
+static initializer list is an ``object`` instruction.


ad 3) IRGen support

Generating statically initialized globals is already done today for structs and 
tuples.
What’s needed is the handling of objects.
In addition to creating the global itself, we also need a runtime call to 
initialize the object header. In other words: the object is statically 
initialized, except the header.

HeapObject *swift::swift_initImmortalObject(HeapMetadata const *metadata, 
HeapObject *object)

There are 2 reasons for that: first, the object header format is not part of 
the ABI. And second, in case of a bound generic type (e.g. array buffers) the 
metadata is not statically available.

One way to call this runtime function is dynamically at the global_object 
instruction whenever the metadata pointer is still null (via swift_once).
Another possibility would be to call it in a global constructor.

If you have any feedback, please let me know

Thanks,
Erik___
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.10 (master) #4003

[Erik Eckstein via swift-dev]

Some non-determinsitic problem in sourcekit?

*** Error in 
`/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/sourcekitd-test':
 corrupted double-linked 


> On Jun 1, 2017, at 12:02 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#4003]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/4003/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Thu, 01 Jun 2017 11:51:49 -0700
> Build duration:   10 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 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 1 test(s), Passed: 9462 test(s), Total: 9463 test(s)
> Failed: Swift(linux-x86_64).SourceKit/InterfaceGen.gen_swift_module.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 432 test(s), Total: 432 test(s)
> 
> Changes
> 
> Commit 72dd2fe084f9bfcbb10dc92bdc04d6a1fb2fc971 by Erik Eckstein:
> tests: adapt the character_literals test
> 
> edit: test/SILOptimizer/character_literals.swift

___
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 - OS X (swift 4.0) #228

[Erik Eckstein via swift-dev]

I think this is rdar://problem/31746923

> On Apr 25, 2017, at 11:47 AM, Jordan Rose via swift-dev  
> wrote:
> 
> I don’t think that’s any of us. Philippe, does this look familiar?
> 
> [ RUN  ] TestCharacterSet.test_moreSetOperations
> stdout>>> check failed at 
> /Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/swift/test/stdlib/TestCharacterSet.swift,
>  line 292
> stdout>>> unexpected value: " U+0064)>" (of type Foundation.CharacterSet)
> stdout>>> check failed at 
> /Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/swift/test/stdlib/TestCharacterSet.swift,
>  line 294
> stdout>>> expected: true
> stdout>>> check failed at 
> /Users/buildnode/jenkins/workspace/oss-swift-4.0-incremental-RA-osx/swift/test/stdlib/TestCharacterSet.swift,
>  line 296
> stdout>>> expected: true
> [ FAIL ] TestCharacterSet.test_moreSetOperations
> 
> Jordan
> 
>> On Apr 25, 2017, at 11:43, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-4.0-incremental-RA-osx [#228]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-4.0-incremental-RA-osx/228/ 
>> 
>> Project: oss-swift-4.0-incremental-RA-osx
>> Date of build:   Tue, 25 Apr 2017 10:59:23 -0700
>> Build duration:  44 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 
>> 
>> Tests:
>> 
>> Name: Swift(macosx-x86_64)
>> Failed: 1 test(s), Passed: 9211 test(s), Total: 9212 test(s)
>> Failed: Swift(macosx-x86_64).stdlib.TestCharacterSet.swift 
>> 
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
>> 
>> Changes
>> 
>> Commit 5d90b805331c3589478d854b52b617c788fd027a by Jordan Rose:
>> [ClangImporter] Classify enums using flag_enum and enum_extensibility
>> 
>> edit: lib/ClangImporter/ImportEnumInfo.cpp
>> edit: test/IDE/Inputs/swift_name.h
>> edit: test/ClangImporter/Inputs/enum-objc.h
>> edit: test/IDE/Inputs/print_clang_header_swift_name.h
>> edit: test/Inputs/clang-importer-sdk/usr/include/user_objc.h
>> edit: lib/PrintAsObjC/PrintAsObjC.cpp
>> edit: test/ClangImporter/enum.swift
>> edit: test/ClangImporter/Inputs/custom-modules/SwiftName.h
>> 
>> Commit 5e66ed04d95689d61dac61f58815b895fc9508be by Jordan Rose:
>> [ClangImporter] If enum_extensibility was removed, it's not an enum.
>> 
>> add: test/Inputs/clang-importer-sdk/usr/include/enums_using_attributes.h
>> add: 
>> test/Inputs/clang-importer-sdk/usr/include/enums_using_attributes.apinotes
>> edit: test/ClangImporter/enum.swift
>> edit: test/Inputs/clang-importer-sdk/usr/include/module.map
>> edit: lib/ClangImporter/ImportEnumInfo.cpp
>> 
>> Commit 026bbd4426dfebea9bf693d755fbef66b658c56b by Bruno Cardoso Lopes:
>> [Modules] Fix a null deference in new redefinition diagnostics
>> 
>> edit: lib/Sema/SemaDecl.cpp
> 
> ___
> 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.10 (master) #3160

[Erik Eckstein via swift-dev]

Thanks!

> On Apr 21, 2017, at 3:10 PM, Huon Wilson  wrote:
> 
> https://github.com/apple/swift/pull/8928 
> 
> 
> Huon
> 
>> On Apr 21, 2017, at 14:05, Erik Eckstein > > wrote:
>> 
>> Huon,
>> 
>> seems to be yours. 
>> 
>> In file included from 
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/lib/Basic/JSONSerialization.cpp:13:
>>  
>> <>/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/include/swift/Basic/JSONSerialization.h:448:47:
>>  error: no member named 'vector' in namespace 'std'
>> template  struct ArrayTraits> {
>>  ~^
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/include/swift/Basic/JSONSerialization.h:448:54:
>>  error: 'T' does not refer to a value
>> template  struct ArrayTraits> {
>>  ^
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/include/swift/Basic/JSONSerialization.h:448:20:
>>  note: declared here
>> template  struct ArrayTraits> {
>>^
>> 2 errors generated.
>> 
>> 
>> Can you please fix or revert?
>> 
>> Thanks,
>> Erik
>> 
>>> On Apr 21, 2017, at 2:01 PM, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3160]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/3160/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_10
>>> Date of build:  Fri, 21 Apr 2017 13:59:48 -0700
>>> Build duration: 1 min 37 sec
>>> 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 
>>> 
>>> Tests:
>>> 
>>> Name: Swift(linux-x86_64)
>>> Failed: 0 test(s), Passed: 9230 test(s), Total: 9230 test(s)
>>> Name: Swift-Unit
>>> Failed: 0 test(s), Passed: 415 test(s), Total: 415 test(s)
>>> 
>>> Changes
>>> 
>>> Commit 87aa3e6935ad99e933512eceb75f4691d3fa6ecb by Huon Wilson:
>>> [Frontend] -frontend -emit-loaded-module-trace.
>>> 
>>> edit: lib/Driver/ToolChains.cpp
>>> edit: include/swift/Option/Options.td
>>> add: test/Driver/loaded_module_trace.swift
>>> edit: include/swift/AST/DiagnosticsFrontend.def
>>> edit: lib/Driver/Types.cpp
>>> add: test/Driver/Inputs/loaded_module_trace_empty.swift
>>> edit: lib/FrontendTool/FrontendTool.cpp
>>> edit: include/swift/Driver/Types.def
>>> edit: lib/Frontend/CompilerInvocation.cpp
>>> add: test/Driver/loaded_module_trace_foundation.swift
>>> edit: lib/Driver/Driver.cpp
>>> edit: include/swift/Basic/JSONSerialization.h
>>> edit: include/swift/Frontend/FrontendOptions.h
>>> 
>>> Commit 7e8568d03d74c3e24d528fe67a22ecaf9f3246d5 by Huon Wilson:
>>> [Driver] Main compiler tells frontend to -emit-loaded-module-trace.
>>> 
>>> edit: test/Driver/loaded_module_trace_foundation.swift
>>> edit: include/swift/Driver/Compilation.h
>>> edit: lib/Driver/Driver.cpp
>>> edit: test/Driver/loaded_module_trace.swift
>>> 
>>> Commit 9c6c7c5105108d6bd0104d0441edc7df90a607e1 by Huon Wilson:
>>> [Driver] Support the SWIFT_LOADED_MODULE_TRACE_PATH env var.
>>> 
>>> edit: lib/Driver/Driver.cpp
>>> add: test/Driver/loaded_module_trace_env.swift
>>> 
>>> Commit b0656b032443a55941dc9f734a77a33cc1b70aa6 by Huon Wilson:
>>> [test] C header, multifile, is-one-line and transitive dependency tests
>>> 
>>> add: test/Driver/loaded_module_trace_header.swift
>>> add: test/Driver/Inputs/loaded_module_trace_imports_module.swift
>>> add: test/Driver/loaded_module_trace_multifile.swift
>>> edit: test/Driver/loaded_module_trace_env.swift
>>> add: test/Driver/Inputs/loaded_module_trace_header.h
>>> edit: test/Driver/loaded_module_trace.swift
>>> add: test/Driver/Inputs/loaded_module_trace_header2.h
>>> 
>>> Commit 268834aabf201d610d06429116d2b8a2614238e2 by Huon Wilson:
>>> [Frontend] Buffer loaded module trace in memory and append "atomically".
>>> 
>>> add: test/Driver/loaded_module_trace_append.swift
>>> edit: lib/FrontendTool/FrontendTool.cpp
>>> 
>>> Commit a9825bb7c633a9deed81ead26d2bb330dde2bc8d by Nathan Hawes:
>>> [migrator] Add -warn-swift3-objc-inference to the new migrator fixit
>>> 
>>> edit: include/swift/Migrator/FixitFilter.h
>> 
> 

___
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.10 (master) #3160

[Erik Eckstein via swift-dev]

Huon,

seems to be yours. 

In file included from 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/lib/Basic/JSONSerialization.cpp:13:
 
<>/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/include/swift/Basic/JSONSerialization.h:448:47:
 error: no member named 'vector' in namespace 'std'
template  struct ArrayTraits> {
 ~^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/include/swift/Basic/JSONSerialization.h:448:54:
 error: 'T' does not refer to a value
template  struct ArrayTraits> {
 ^
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/include/swift/Basic/JSONSerialization.h:448:20:
 note: declared here
template  struct ArrayTraits> {
   ^
2 errors generated.


Can you please fix or revert?

Thanks,
Erik

> On Apr 21, 2017, at 2:01 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3160]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/3160/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Fri, 21 Apr 2017 13:59:48 -0700
> Build duration:   1 min 37 sec
> 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 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9230 test(s), Total: 9230 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 415 test(s), Total: 415 test(s)
> 
> Changes
> 
> Commit 87aa3e6935ad99e933512eceb75f4691d3fa6ecb by Huon Wilson:
> [Frontend] -frontend -emit-loaded-module-trace.
> 
> edit: lib/Driver/ToolChains.cpp
> edit: include/swift/Option/Options.td
> add: test/Driver/loaded_module_trace.swift
> edit: include/swift/AST/DiagnosticsFrontend.def
> edit: lib/Driver/Types.cpp
> add: test/Driver/Inputs/loaded_module_trace_empty.swift
> edit: lib/FrontendTool/FrontendTool.cpp
> edit: include/swift/Driver/Types.def
> edit: lib/Frontend/CompilerInvocation.cpp
> add: test/Driver/loaded_module_trace_foundation.swift
> edit: lib/Driver/Driver.cpp
> edit: include/swift/Basic/JSONSerialization.h
> edit: include/swift/Frontend/FrontendOptions.h
> 
> Commit 7e8568d03d74c3e24d528fe67a22ecaf9f3246d5 by Huon Wilson:
> [Driver] Main compiler tells frontend to -emit-loaded-module-trace.
> 
> edit: test/Driver/loaded_module_trace_foundation.swift
> edit: include/swift/Driver/Compilation.h
> edit: lib/Driver/Driver.cpp
> edit: test/Driver/loaded_module_trace.swift
> 
> Commit 9c6c7c5105108d6bd0104d0441edc7df90a607e1 by Huon Wilson:
> [Driver] Support the SWIFT_LOADED_MODULE_TRACE_PATH env var.
> 
> edit: lib/Driver/Driver.cpp
> add: test/Driver/loaded_module_trace_env.swift
> 
> Commit b0656b032443a55941dc9f734a77a33cc1b70aa6 by Huon Wilson:
> [test] C header, multifile, is-one-line and transitive dependency tests
> 
> add: test/Driver/loaded_module_trace_header.swift
> add: test/Driver/Inputs/loaded_module_trace_imports_module.swift
> add: test/Driver/loaded_module_trace_multifile.swift
> edit: test/Driver/loaded_module_trace_env.swift
> add: test/Driver/Inputs/loaded_module_trace_header.h
> edit: test/Driver/loaded_module_trace.swift
> add: test/Driver/Inputs/loaded_module_trace_header2.h
> 
> Commit 268834aabf201d610d06429116d2b8a2614238e2 by Huon Wilson:
> [Frontend] Buffer loaded module trace in memory and append "atomically".
> 
> add: test/Driver/loaded_module_trace_append.swift
> edit: lib/FrontendTool/FrontendTool.cpp
> 
> Commit a9825bb7c633a9deed81ead26d2bb330dde2bc8d by Nathan Hawes:
> [migrator] Add -warn-swift3-objc-inference to the new migrator fixit
> 
> edit: include/swift/Migrator/FixitFilter.h

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

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.04 (swift 4.0) #7

[Erik Eckstein via swift-dev]

Jim, Jason,

/home/buildnode/disk2/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/lldb/source/Core/Mangled.cpp:20:9:
 warning: 'LLDB_USE_BUILTIN_DEMANGLER' macro redefined [-Wmacro-redefined]
#define LLDB_USE_BUILTIN_DEMANGLER
^
:5:9: note: previous definition is here
#define LLDB_USE_BUILTIN_DEMANGLER 1
^
/home/buildnode/disk2/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/lldb/source/Core/Mangled.cpp:34:10:
 fatal error: 'swift/Basic/Demangle.h' file not found
#include "swift/Basic/Demangle.h"
 ^
1 warning and 1 error generated.

Any idea why we get this error on the swift-4.0-branch?

Thanks,
Erik

> On Apr 20, 2017, at 11:18 PM, Andrew Jeffery  wrote:
> 
> On Thu, 2017-04-20 at 23:12 -0700, no-re...@swift.org wrote:
>> [FAILURE] oss-swift-4.0-package-linux-ubuntu-16_04 [#7]
>> Build URL:   https://ci.swift.org/job/oss-swift-4.0-package-linu
>> x-ubuntu-16_04/7/
>> Project: oss-swift-4.0-package-linux-ubuntu-16_04
>> Date of build:   Thu, 20 Apr 2017 22:47:26 -0700
>> Build duration:  24 min
>> 
>> Changes
>> Commit d53fe63ef8ab88018bec940d067ae965144e2dab by Andrew Jeffery:
>> lock: Avoid use of undefined DISPATCH_INTERNAL_CRASH
>> edit: src/shims/lock.h
>> 
> 
> Looking at other builds for this job it seems this wasn't a consequence
> of my change. Is this being addressed?
> 
> Cheers,
> 
> Andrew

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

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 16.04 (master) #845

[Erik Eckstein via swift-dev]

ok, thanks.
I filed https://bugs.swift.org/browse/SR-4647
and disabled the test for now: 8e8dd9bc73c5565e7b5423d809ee7bfdd39b30f7

Erik

> On Apr 20, 2017, at 12:24 AM, Pushkar N Kulkarni  
> wrote:
> 
> This failure has been coming up very intermittently for a while when running 
> TestFoundation locally.
> 
> Though we have a new commit in URLSession 
> (015ded4d70a7cf4b2741d7206fc60a3d1ceffe03), I don't think that change can 
> trigger this failure. Nevertheless, I'll try to reproduce it locally and 
> investigate.  
> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -swift-dev-boun...@swift.org <mailto:-swift-dev-boun...@swift.org> 
> wrote: -----
> To: Philippe Hausler mailto:phaus...@apple.com>>
> From: Erik Eckstein via swift-dev 
> Sent by: swift-dev-boun...@swift.org <mailto:swift-dev-boun...@swift.org>
> Date: 04/20/2017 10:00AM
> Cc: Jim Ingham mailto:jing...@apple.com>>, swift-dev 
> mailto:swift-dev@swift.org>>
> Subject: Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package 
> - Ubuntu 16.04 (master) #845
> 
> Hi Philippe,
> 
> this failing test seems to be flaky. Is it possible to fix this? Maybe 
> increase the timeout?
> 
> TestFoundation/TestNSURLSession.swift:254: error: 
> TestURLSession.test_downloadTaskWithURLAndHandler : Asynchronous wait failed 
> - Exceeded timeout of 12.0 seconds, with unfulfilled expectations: download 
> task with handler
> 
> Thanks,
> Erik
> 
>> On Apr 19, 2017, at 9:05 PM, no-re...@swift.org <mailto:no-re...@swift.org> 
>> wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-package-linux-ubuntu-16_04 [#845]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_04/845/ 
>> <https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_04/845/>
>> Project: oss-swift-package-linux-ubuntu-16_04
>> Date of build:   Wed, 19 Apr 2017 19:42:56 -0700
>> Build duration:  1 hr 22 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 
>> <https://ci.swift.org//job/oss-swift-package-linux-ubuntu-16_04/845/consoleFull#2072898497ee1a197b-acac-4b17-83cf-a53b95139a76>
>> Changes
>> 
>> Commit 86607e9364f583969abccb82fdea5f8470a993c3 by Daniel Dunbar:
>> Fix typo in comment.
>> 
>> edit: products/libllbuild/public-api/llbuild/buildsystem.h
>> 
>> Commit b0dc90bb06d94d5b5296a25cde5ff63a457311ee by Adrian Prantl:
>> Fix bug that caused DwarfExpression to drop DW_OP_deref from FI
>> 
>> edit: lib/CodeGen/AsmPrinter/DwarfExpression.cpp
>> edit: lib/CodeGen/AsmPrinter/DwarfUnit.cpp
>> edit: lib/CodeGen/AsmPrinter/DwarfDebug.cpp
>> add: test/DebugInfo/X86/fi-expr.ll
>> edit: lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
>> edit: lib/CodeGen/AsmPrinter/DwarfExpression.h
>> 
>> Commit d1d460b5a093eb04cba6914a05546a9fd165a589 by Sean Callanan:
>> [Expression parser] Don't try to materialize empty Swift structs.
>> 
>> edit: source/Expression/Materializer.cpp
>> add: packages/Python/lldbsuite/test/lang/swift/expression/empty_self/Makefile
>> add: 
>> packages/Python/lldbsuite/test/lang/swift/expression/empty_self/TestEmptySelf.py
>> add: 
>> packages/Python/lldbsuite/test/lang/swift/expression/empty_self/main.swift
>> 
>> Commit eb173567d971dad88c342d6750cb7b82c7977bd0 by Jim Ingham:
>> Fix !N and !-N commands and add a test case.
>> 
>> edit: source/Commands/CommandObjectCommands.cpp
>> add: 
>> packages/Python/lldbsuite/test/functionalities/history/TestHistoryRecall.py
>> edit: source/Interpreter/CommandHistory.cpp
>> 
>> Commit 1d09ebab8f94055e2b1a7c6057ffca67f72fcc98 by Jim Ingham:
>> x-fail this test while Adrian is working on a fix.
>> 
>> edit: 
>> packages/Python/lldbsuite/test/lang/swift/variables/generic_struct_debug_info/generic_flatmap/TestSwiftGenericStructDebugInfoGenericFlatMap.py
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org <mailto:swift-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev 
> <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 Still Failing: OSS - Swift Package - Ubuntu 16.04 (master) #845

[Erik Eckstein via swift-dev]

Hi Philippe,

this failing test seems to be flaky. Is it possible to fix this? Maybe increase 
the timeout?

TestFoundation/TestNSURLSession.swift:254: error: 
TestURLSession.test_downloadTaskWithURLAndHandler : Asynchronous wait failed - 
Exceeded timeout of 12.0 seconds, with unfulfilled expectations: download task 
with handler

Thanks,
Erik

> On Apr 19, 2017, at 9:05 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-package-linux-ubuntu-16_04 [#845]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_04/845/ 
> 
> Project:  oss-swift-package-linux-ubuntu-16_04
> Date of build:Wed, 19 Apr 2017 19:42:56 -0700
> Build duration:   1 hr 22 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 86607e9364f583969abccb82fdea5f8470a993c3 by Daniel Dunbar:
> Fix typo in comment.
> 
> edit: products/libllbuild/public-api/llbuild/buildsystem.h
> 
> Commit b0dc90bb06d94d5b5296a25cde5ff63a457311ee by Adrian Prantl:
> Fix bug that caused DwarfExpression to drop DW_OP_deref from FI
> 
> edit: lib/CodeGen/AsmPrinter/DwarfExpression.cpp
> edit: lib/CodeGen/AsmPrinter/DwarfUnit.cpp
> edit: lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> add: test/DebugInfo/X86/fi-expr.ll
> edit: lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
> edit: lib/CodeGen/AsmPrinter/DwarfExpression.h
> 
> Commit d1d460b5a093eb04cba6914a05546a9fd165a589 by Sean Callanan:
> [Expression parser] Don't try to materialize empty Swift structs.
> 
> edit: source/Expression/Materializer.cpp
> add: packages/Python/lldbsuite/test/lang/swift/expression/empty_self/Makefile
> add: 
> packages/Python/lldbsuite/test/lang/swift/expression/empty_self/TestEmptySelf.py
> add: 
> packages/Python/lldbsuite/test/lang/swift/expression/empty_self/main.swift
> 
> Commit eb173567d971dad88c342d6750cb7b82c7977bd0 by Jim Ingham:
> Fix !N and !-N commands and add a test case.
> 
> edit: source/Commands/CommandObjectCommands.cpp
> add: 
> packages/Python/lldbsuite/test/functionalities/history/TestHistoryRecall.py
> edit: source/Interpreter/CommandHistory.cpp
> 
> Commit 1d09ebab8f94055e2b1a7c6057ffca67f72fcc98 by Jim Ingham:
> x-fail this test while Adrian is working on a fix.
> 
> edit: 
> packages/Python/lldbsuite/test/lang/swift/variables/generic_struct_debug_info/generic_flatmap/TestSwiftGenericStructDebugInfoGenericFlatMap.py

___
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 14.04 (master) #2124

[Erik Eckstein via swift-dev]

This test is flaky. It only fails in some builds.
Slava, can you disable this test until it is fixed (means: stable)?

Thanks,
Erik

> On Apr 18, 2017, at 8:15 PM, Slava Pestov via swift-dev  
> wrote:
> 
> This is most definitely not your fault, because it is my fault, from the 
> subclass existential runtime changes. I first saw the failure a few days ago 
> but it slipped my mind. Will look at it now.
> 
> Slava
> 
>> On Apr 18, 2017, at 6:01 PM, Jordan Rose via swift-dev > > wrote:
>> 
>>  TEST 'Swift-Unit :: 
>> runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata' FAILED 
>> 
>> 
>> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/unittests/runtime/Metadata.cpp:462:
>>  Failure
>>   Expected: ab
>>   Which is: 0x53e6e0
>> To be equal to: ba
>>   Which is: 0x53e7d0
>> 
>> 
>> This can't possibly be my commit.
>> 
>> 
>>> On Apr 18, 2017, at 18:01, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#2124]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/2124/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-14_04
>>> Date of build:  Tue, 18 Apr 2017 17:25:59 -0700
>>> Build duration: 35 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 e88e93cabf72ba487362a6b25a8674c72d6f77e1 by Jordan Rose:
>>> Use PrettyStackTrace to say /which/ SIL function already exists.
>>> 
>>> edit: lib/SIL/SILFunction.cpp
>> 
>> ___
>> 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-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (master) #471

[Erik Eckstein via swift-dev]

Does anyone feel responsible for this asan crash?

=
==56579==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020e6b8 
at pc 0x000115dfdca9 bp 0x78f0 sp 0x78e8
READ of size 8 at 0x6020e6b8 thread T6
0  sourcekitd-test0x000109794c77 
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 231
1  sourcekitd-test0x000109791ee2 
llvm::sys::RunSignalHandlers() + 194
2  sourcekitd-test0x000109795afd SignalHandler(int) + 
765
3  libsystem_platform.dylib   0x7fff93067bba _sigtramp + 26
4  libsystem_platform.dylib   0x000115d1b968 _sigtramp + 2194357704
5  libdispatch.dylib  0x7fff92e2500d _dispatch_dispose + 35
6  libdispatch.dylib  0x7fff92e49201 -[OS_dispatch_queue 
_xref_dispose] + 57
7  libsourcekitdInProc.dylib  0x000115e38264 
SourceKit::SwiftLangSupport::~SwiftLangSupport() + 1284
8  libsourcekitdInProc.dylib  0x000115e3841e 
SourceKit::SwiftLangSupport::~SwiftLangSupport() + 14
9  libsourcekitdInProc.dylib  0x00011610eaa9 
SourceKit::Context::~Context() + 457
10 libsourcekitdInProc.dylib  0x000115e86c4a sourcekitd::shutdown() 
+ 26
11 libsourcekitdInProc.dylib  0x000115eb75b4 sourcekitd_shutdown + 
644
12 sourcekitd-test0x00010910ecf3 __main_block_invoke + 
3027
13 libclang_rt.asan_osx_dynamic.dylib 0x000109fe420f 
__wrap_dispatch_async_block_invoke + 271
14 libdispatch.dylib  0x7fff92e2cef7 
_dispatch_call_block_and_release + 12
15 libdispatch.dylib  0x7fff92e240b8 
_dispatch_client_callout + 8
16 libdispatch.dylib  0x7fff92e26029 
_dispatch_root_queue_drain + 917
17 libdispatch.dylib  0x7fff92e25c47 
_dispatch_worker_thread3 + 99
18 libsystem_pthread.dylib0x7fff93071712 _pthread_wqthread + 
1299
19 libsystem_pthread.dylib0x7fff930711ed start_wqthread + 13
/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64/test-macosx-x86_64/SourceKit/Sema/Output/sema_diag_after_edit_fixit.swift.script:
 line 1: 56579 Illegal instruction: 4  
/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64/bin/sourcekitd-test
 -req=open 
/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/SourceKit/Sema/sema_diag_after_edit_fixit.swift
 -- 
/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/SourceKit/Sema/sema_diag_after_edit_fixit.swift
 == -req=print-diags 
/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/SourceKit/Sema/sema_diag_after_edit_fixit.swift
 == -req=edit -pos=2:1 -replace="_" -length=5 
/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/SourceKit/Sema/sema_diag_after_edit_fixit.swift
 -print-raw-response
 56580 Done| 
/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/utils/PathSanitizingFileCheck
 --sanitize 
'BUILD_DIR=/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/swift-macosx-x86_64'
 --sanitize 
'SOURCE_DIR=/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift'
 --use-filecheck 
'/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/buildbot_incremental_asan/llvm-macosx-x86_64/./bin/FileCheck'
 
/Users/buildnode/jenkins/workspace/oss-swift-incremental-ASAN-RA-osx/swift/test/SourceKit/Sema/sema_diag_after_edit_fixit.swift

--

> On Apr 18, 2017, at 3:50 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-ASAN-RA-osx [#471]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/471/ 
> 
> Project:  oss-swift-incremental-ASAN-RA-osx
> Date of build:Tue, 18 Apr 2017 12:26:23 -0700
> Build duration:   3 hr 24 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 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 1 test(s), Passed: 9207 test(s), Total: 9208 test(s)
> Failed: Swift(macosx-x86_64).SourceKit/Sema.sema_diag_after_edit_fixit.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
> 
> Changes
> 
> Commit 7bedb6fdd590caf365760c447e250c8d0ab11812 by Huon Wilson:
> [TBDGen] Generic 

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

[Erik Eckstein via swift-dev]

Doug,

only your changes are on the blame list. Can you please check this?

The fail is:

 TEST 'Swift(linux-x86_64) :: TBD/protocol.swift' FAILED 

Script:
--
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift
 -frontend -target x86_64-unknown-linux-gnu  -module-cache-path 
'/tmp/swift-testsuite-clang-module-cachehxt0rb' -c -parse-as-library 
-module-name test -validate-tbd-against-ir 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/test/TBD/protocol.swift
--
Exit Code: 135

Command Output (stderr):
--
#0 0x03992f48 llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x3992f48)
#1 0x03993686 SignalHandler(int) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x3993686)
#2 0x7f9657ae1670 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11670)
#3 0x03935fee getOpenFileImpl(int, llvm::Twine const&, unsigned long, 
unsigned long, long, bool, bool) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x3935fee)
#4 0x03935a15 llvm::MemoryBuffer::getFileOrSTDIN(llvm::Twine const&, 
long, bool) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x3935a15)
#5 0x029e1b7a llvm::object::createBinary(llvm::StringRef) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x29e1b7a)
#6 0x005840b9 swift::performLLVM(swift::IRGenOptions&, 
swift::DiagnosticEngine*, llvm::sys::SmartMutex*, llvm::GlobalVariable*, 
llvm::Module*, llvm::TargetMachine*, swift::version::Version const&, 
llvm::StringRef) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x5840b9)
#7 0x004ac5bf swift::performFrontend(llvm::ArrayRef, char 
const*, void*, swift::FrontendObserver*) 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x4ac5bf)
#8 0x00465a87 main 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x465a87)
#9 0x7f96562073f1 __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x203f1)
#10 0x0046312a _start 
(/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x46312a)
Stack dump:
0.  Program arguments: 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift
 -frontend -target x86_64-unknown-linux-gnu -module-cache-path 
/tmp/swift-testsuite-clang-module-cachehxt0rb -c -parse-as-library -module-name 
test -validate-tbd-against-ir 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/test/TBD/protocol.swift
 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/test-linux-x86_64/TBD/Output/protocol.swift.script:
 line 1:  5938 Bus error   
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift
 -frontend -target x86_64-unknown-linux-gnu -module-cache-path 
'/tmp/swift-testsuite-clang-module-cachehxt0rb' -c -parse-as-library 
-module-name test -validate-tbd-against-ir 
/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/test/TBD/protocol.swift

--

> On Apr 18, 2017, at 10:00 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3083]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/3083/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Tue, 18 Apr 2017 09:45:27 -0700
> Build duration:   15 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 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 2 test(s), Passed: 9203 test(s), Total: 9205 test(s)
> Failed: Swift(linux-x86_64).TBD.protocol.swift 
> 
> Failed:

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

[Erik Eckstein via swift-dev]

Never mind, the following build is okay again.

> On Apr 17, 2017, at 4:15 PM, Erik Eckstein  wrote:
> 
> Hi Ankit,
> 
> this timed out in the swiftpm tests.
> 
> Can your changes caused this?
> 
> Can you please check?
> 
> Thanks,
> Erik
> 
>> On Apr 17, 2017, at 3:51 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_10 [#74]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-ubuntu-16_10/74/ 
>> 
>> Project: oss-swift-4.0-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Mon, 17 Apr 2017 13:32:27 -0700
>> Build duration:  2 hr 19 min
>> Identified problems:
>> 
>> Timeout: This build was marked as FAIL because it timed out.
>> Indication 1 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 9151 test(s), Total: 9151 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 416 test(s), Total: 416 test(s)
>> 
>> Changes
>> 
>> Commit 1ba2af8393d92a8d74ce112562d7023e188bb787 by Bruno Cardoso Lopes:
>> PR32280: Do not crash on nested initializers.
>> 
>> edit: test/Sema/designated-initializers.c
>> edit: lib/Sema/SemaInit.cpp
>> 
>> Commit 326b26f206478c70a14a25c06a1517f233616931 by Ankit Aggarwal:
>> [Workspace] Make non-editable checkouts immutable
>> 
>> edit: Sources/Workspace/Workspace.swift
>> edit: Tests/WorkspaceTests/WorkspaceTests.swift
>> edit: Tests/FunctionalTests/MiscellaneousTests.swift
> 

___
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 (swift 4.0) #40

[Erik Eckstein via swift-dev]

Max,

seems to be yours:

long-test/swift-corelibs-xctest/Sources/XCTest/Private/WallClockTimeMetric.swift:66:43:
 error: cannot invoke initializer for type 'Int' with an argument list of type 
'(Self.IndexDistance)'
return self.reduce(0, +) / Double(Int(count))
  ^

Can you please fix or revert?

Thanks,
Erik


> On Apr 17, 2017, at 5:18 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_04-long-test [#40]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-ubuntu-16_04-long-test/40/
>  
> 
> Project:  oss-swift-4.0-incremental-RA-linux-ubuntu-16_04-long-test
> Date of build:Mon, 17 Apr 2017 17:07:48 -0700
> Build duration:   10 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 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9151 test(s), Total: 9151 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 426 test(s), Total: 426 test(s)
> 
> Changes
> 
> Commit e2dbf673fdb58e3b49e76aa888ae4bcf35843bdd by Joe Groff:
> SILGen: Push 'usingImplicitVariablesForPattern' hack into 'where' clause
> 
> edit: lib/SILGen/SILGenPattern.cpp
> add: test/Interpreter/switch_where_clause.swift
> 
> Commit c538a2d3ae73b9920c444d3379854324abd2c565 by Max Moiseev:
> Upgrading to the new integer protocols
> 
> edit: Sources/XCTest/Private/WallClockTimeMetric.swift
> 
> Commit a664f83fc5818d40bce795c9816a0f3c0b92d6f6 by Bruno Cardoso Lopes:
> [Modules] Improve redefinition errors pointing to the same header
> 
> add: test/Modules/Inputs/SameHeader/A.h
> edit: test/SemaCXX/modules-ts.cppm
> add: test/Sema/redefinition-same-header.c
> edit: include/clang/Basic/DiagnosticSemaKinds.td
> edit: lib/Sema/SemaDecl.cpp
> add: test/Modules/redefinition-same-header.m
> add: test/Modules/Inputs/SameHeader/B.h
> edit: include/clang/Sema/Sema.h
> add: test/Modules/Inputs/SameHeader/C.h
> add: test/Modules/Inputs/SameHeader/module.modulemap

___
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.10 (swift 4.0) #74

[Erik Eckstein via swift-dev]

Hi Ankit,

this timed out in the swiftpm tests.

Can your changes caused this?

Can you please check?

Thanks,
Erik

> On Apr 17, 2017, at 3:51 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_10 [#74]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-ubuntu-16_10/74/ 
> 
> Project:  oss-swift-4.0-incremental-RA-linux-ubuntu-16_10
> Date of build:Mon, 17 Apr 2017 13:32:27 -0700
> Build duration:   2 hr 19 min
> Identified problems:
> 
> Timeout: This build was marked as FAIL because it timed out.
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9151 test(s), Total: 9151 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 416 test(s), Total: 416 test(s)
> 
> Changes
> 
> Commit 1ba2af8393d92a8d74ce112562d7023e188bb787 by Bruno Cardoso Lopes:
> PR32280: Do not crash on nested initializers.
> 
> edit: test/Sema/designated-initializers.c
> edit: lib/Sema/SemaInit.cpp
> 
> Commit 326b26f206478c70a14a25c06a1517f233616931 by Ankit Aggarwal:
> [Workspace] Make non-editable checkouts immutable
> 
> edit: Sources/Workspace/Workspace.swift
> edit: Tests/WorkspaceTests/WorkspaceTests.swift
> edit: Tests/FunctionalTests/MiscellaneousTests.swift

___
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 - OS X (master) #9379

[Erik Eckstein via swift-dev]

I’ll fix this.

> On Apr 13, 2017, at 11:22 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#9379]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9379/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Thu, 13 Apr 2017 10:53:36 -0700
> Build duration:   29 min
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 0 test(s), Passed: 9186 test(s), Total: 9186 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
> 
> Changes
> 
> Commit 789646a15be86391696a11b2f0544b6c2579e44d by Erik Eckstein:
> Demangling: Make demangled names more readable and further reduce the
> 
> edit: test/SILGen/SILDeclRef.swift
> edit: test/SILGen/accessibility_vtables.swift
> edit: test/stdlib/Mirror.swift
> edit: unittests/SwiftDemangle/DemangleTest.cpp
> edit: test/TBD/Inputs/class.log
> edit: test/SILGen/coverage_while.swift
> edit: test/TBD/Inputs/protocol.log
> edit: test/SILOptimizer/functionsigopts_self.swift
> edit: test/SILGen/dynamic.swift
> edit: test/SILGen/statements.swift
> edit: test/SILGen/accessors.swift
> edit: test/SILGen/generic_local_property.swift
> edit: include/swift/Demangling/Demangle.h
> edit: test/TBD/Inputs/struct.log
> edit: test/Interpreter/typeof.swift
> edit: test/ClangImporter/macro_literals.swift
> edit: test/SILOptimizer/inline_self.swift
> edit: test/SILOptimizer/alive_method_with_thunk.swift
> edit: test/Interpreter/tuple_casts.swift
> edit: test/SILGen/errors.swift
> edit: test/DebugInfo/linetable-do.swift
> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
> edit: test/Demangle/Inputs/manglings.txt
> edit: test/SILGen/properties.swift
> edit: test/SILGen/default_constructor.swift
> edit: test/SILGen/vtable_thunks_reabstraction.swift
> edit: test/SILGen/interface_type_mangling.swift
> edit: test/SILGen/nested_generics.swift
> edit: test/SILOptimizer/specialize_self.swift
> edit: test/Demangle/Inputs/simplified-manglings.txt
> edit: test/SILGen/weak.swift
> edit: test/Reflection/typeref_decoding.swift
> edit: test/SILGen/functions.swift
> edit: test/SILGen/if_while_binding.swift
> edit: test/SILGen/mangling.swift
> edit: lib/Demangling/NodePrinter.cpp
> edit: test/SILOptimizer/eager_specialize.sil

___
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.10 (master) #2664

[Erik Eckstein via swift-dev]

> On Mar 27, 2017, at 12:20 PM, Mishal Shah  wrote:
> 
> Please file a bug for missing dependency. 

I already did 2 month ago: rdar://problem/30315400 

> 
> Workspace deleted. 
> 
> Thanks,
> Mishal Sha
>> On Mar 27, 2017, at 11:43 AM, Erik Eckstein > > wrote:
>> 
>> Mishal, can you please clean the workspace?
>> Another missing build dependency.
>> 
>> Thanks
>> 
>>> On Mar 27, 2017, at 11:25 AM, no-re...@swift.org 
>>>  wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2664]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2664/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_10
>>> Date of build:  Mon, 27 Mar 2017 11:16:27 -0700
>>> Build duration: 8 min 57 sec
>>> 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 
>>> 
>>> Regression test failed: This build failed because a regression test in the 
>>> test suite FAILed. Below is a list of all errors:
>>> Indication 1 
>>> 
>>> Tests:
>>> 
>>> Name: Swift(linux-x86_64)
>>> Failed: 1 test(s), Passed: 9102 test(s), Total: 9103 test(s)
>>> Failed: Swift(linux-x86_64).Reflection.typeref_decoding.swift 
>>> 
>>> Name: Swift-Unit
>>> Failed: 0 test(s), Passed: 416 test(s), Total: 416 test(s)
>>> 
>>> Changes
>>> 
>>> Commit cd3da4a218924db9af70d6e68b0cb79c89e1ea57 by Erik Eckstein:
>>> Demangling: Print varargs correctly.
>>> 
>>> edit: test/Demangle/Inputs/manglings.txt
>>> edit: lib/Demangling/NodePrinter.cpp
>>> edit: test/Reflection/typeref_decoding.swift
>> 
> 

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

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

[Erik Eckstein via swift-dev]

And please for this as well

Thanks

> On Mar 27, 2017, at 11:38 AM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-osx [#9070]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9070/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Mon, 27 Mar 2017 11:15:42 -0700
> Build duration:   22 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(macosx-x86_64)
> Failed: 2 test(s), Passed: 9101 test(s), Total: 9103 test(s)
> Failed: Swift(macosx-x86_64).Python.gyb.swift 
> 
> Failed: Swift(macosx-x86_64).Reflection.typeref_decoding.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 476 test(s), Total: 476 test(s)
> 
> Changes
> 
> Commit cd3da4a218924db9af70d6e68b0cb79c89e1ea57 by Erik Eckstein:
> Demangling: Print varargs correctly.
> 
> edit: test/Reflection/typeref_decoding.swift
> edit: lib/Demangling/NodePrinter.cpp
> edit: test/Demangle/Inputs/manglings.txt

___
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.10 (master) #2664

[Erik Eckstein via swift-dev]

Mishal, can you please clean the workspace?
Another missing build dependency.

Thanks

> On Mar 27, 2017, at 11:25 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2664]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2664/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Mon, 27 Mar 2017 11:16:27 -0700
> Build duration:   8 min 57 sec
> 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 1 test(s), Passed: 9102 test(s), Total: 9103 test(s)
> Failed: Swift(linux-x86_64).Reflection.typeref_decoding.swift 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 416 test(s), Total: 416 test(s)
> 
> Changes
> 
> Commit cd3da4a218924db9af70d6e68b0cb79c89e1ea57 by Erik Eckstein:
> Demangling: Print varargs correctly.
> 
> edit: test/Demangle/Inputs/manglings.txt
> edit: lib/Demangling/NodePrinter.cpp
> edit: test/Reflection/typeref_decoding.swift

___
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.10 (master) #2646

[Erik Eckstein via swift-dev]

Mishal, can you please clean the workspace for this job?

It’s again the same issue of missing build dependencies from swiftc -> 
foundation

Thanks,
Erik

> On Mar 26, 2017, at 1:03 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2646]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2646/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Sun, 26 Mar 2017 12:50:18 -0700
> Build duration:   13 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9102 test(s), Total: 9102 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 416 test(s), Total: 416 test(s)
> 
> Changes
> 
> Commit 327017a65b87be09380a7ebd1f89b596e60cf314 by Erik Eckstein:
> Mangling: support mangling of varargs even if it's not the last
> 
> edit: test/Demangle/Inputs/manglings.txt
> edit: test/Serialization/function.swift
> edit: lib/Demangling/NodePrinter.cpp
> edit: test/SILGen/mangling.swift
> edit: test/SILGen/default_arguments_imported.swift
> edit: lib/Demangling/Demangler.cpp
> edit: test/SILGen/scalar_to_tuple_args.swift
> edit: test/SourceKit/DocSupport/doc_clang_module.swift.response
> edit: test/SILGen/retaining_globals.swift
> edit: test/SILGen/errors.swift
> edit: lib/AST/ASTMangler.cpp
> edit: docs/ABI.rst
> edit: test/SIL/Serialization/deserialize_generic.sil
> 
> Commit e427ded6c985b7b41f243f349dd35c47c91a3056 by Erik Eckstein:
> Mangling: refactoring: clean up tuple nodes
> 
> edit: include/swift/Remote/MetadataReader.h
> edit: test/Demangle/Inputs/manglings.txt
> edit: include/swift/Demangling/DemangleNodes.def
> edit: lib/Demangling/Remangler.cpp
> edit: stdlib/public/runtime/Demangle.cpp
> edit: lib/Demangling/NodePrinter.cpp
> edit: lib/IDE/TypeReconstruction.cpp
> edit: lib/Demangling/OldDemangler.cpp
> edit: lib/Demangling/Demangler.cpp

___
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.10 (master) #2428

[Erik Eckstein via swift-dev]

> On Mar 16, 2017, at 2:32 PM, Adrian Prantl  wrote:
> 
> I'm somewhat confused why this failed?

It needs a clean build.

> 
> -- adrian
> 
>> On Mar 16, 2017, at 2:31 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2428]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2428/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Thu, 16 Mar 2017 14:20:26 -0700
>> Build duration:  10 min
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 9079 test(s), Total: 9079 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 415 test(s), Total: 415 test(s)
>> 
>> Changes
>> 
>> Commit 2a55b26e46693c7324d50c6a2acda3e8a478 by Erik Eckstein:
>> Mangling: enable new mangling for symbols
>> 
>> edit: test/SILOptimizer/functionsigopts_sroa.sil
>> edit: test/SILGen/closures.swift
>> edit: test/IRGen/objc_attr_NSManaged.sil
>> edit: test/IRGen/partial_apply.sil
>> edit: include/swift/Demangling/ManglingMacros.h
>> edit: test/SILGen/default_constructor.swift
>> edit: test/DebugInfo/LinetableArtificialFn.swift
>> edit: test/IRGen/special_protocols.sil
>> edit: test/stdlib/Runtime.swift.gyb
>> edit: test/IRGen/class.sil
>> edit: test/IRGen/dllimport.swift
>> edit: test/IRGen/enum_value_semantics_special_cases_objc.sil
>> edit: test/SILOptimizer/bridged_casts_folding.swift
>> edit: test/SILGen/accessibility_vtables.swift
>> edit: test/IRGen/type_layout_reference_storage.swift
>> edit: test/IRGen/enum_value_semantics.sil
>> edit: test/SILGen/protocol_optional.swift
>> edit: test/IRGen/sil_witness_methods.sil
>> edit: test/IRGen/generic_types.swift
>> edit: test/SILOptimizer/allocbox_to_stack.sil
>> edit: validation-test/stdlib/MicroStdlib/Inputs/RuntimeStubs.c
>> edit: test/SILOptimizer/closure_specialize_simple.sil
>> edit: test/Frontend/Inputs/sil-primary-file-with-sib.sil
>> edit: test/IRGen/dynamic_self_metadata.swift
>> edit: test/IRGen/metadata_dominance.swift
>> edit: test/SILGen/sil_locations.swift
>> edit: test/IRGen/vtable.sil
>> edit: test/IRGen/generic_casts.swift
>> edit: test/SIL/Serialization/shared_function_serialization.sil
>> edit: test/SILGen/witness-init-requirement-with-base-class-init.swift
>> edit: test/SILGen/collection_upcast.swift
>> edit: test/IRGen/swift3-metadata-coff.swift
>> edit: test/Serialization/class-roundtrip-module.swift
>> edit: test/DebugInfo/byref-capture.swift
>> edit: test/SILGen/switch_objc.swift
>> edit: test/DebugInfo/fnptr.swift
>> edit: test/DebugInfo/typealias.swift
>> edit: test/DebugInfo/inout.swift
>> edit: test/IRGen/function_metadata.swift
>> edit: test/IRGen/cf.sil
>> edit: test/IRGen/struct_resilience.swift
>> edit: test/SILGen/enum.swift
>> edit: test/IRGen/field_type_vectors.sil
>> edit: test/SILGen/vtable_thunks.swift
>> edit: test/sil-nm/basic.sil
>> edit: test/IDE/merge_local_types.swift
>> edit: test/SILGen/extensions.swift
>> edit: test/SILOptimizer/closure_specialize_consolidated.sil
>> edit: test/SILGen/objc_bridging_any.swift
>> edit: test/IRGen/indirect_argument.sil
>> edit: test/SILGen/retaining_globals.swift
>> edit: test/IRGen/type_layout_objc.swift
>> edit: test/IDE/local_types.swift
>> edit: test/SILGen/opaque_values_silgen_lib.swift
>> edit: test/Serialization/inherited-initializer.swift
>> edit: test/SILGen/optional_lvalue.swift
>> edit: test/SILOptimizer/capture_promotion.sil
>> edit: test/Serialization/class.swift
>> edit: test/IDE/reconstruct_type_from_mangled_name_invalid.swift
>> edit: test/SILOptimizer/capture_promotion_reachability.sil
>> edit: test/DebugInfo/mangling.swift
>> edit: test/DebugInfo/bool.swift
>> edit: test/SILGen/default_arguments_imported.swift
>> edit: test/SourceKit/CursorInfo/cursor_info.swift
>> edit: test/IRGen/protocol_conformance_records.swift
>> edit: test/DebugInfo/enum.swift
>> edit: test/IRGen/class_resilience_objc_armv7k.swift
>> edit: test/IRGen/enum_32_bit.sil
>> edit: test/IRGen/generic_tuples.swift
>> edit: test/DebugInfo/test_ints.swift
>> edit: test/DebugInfo/typearg.swift
>> edit: test/DebugInfo/mangling-stdlib.swift
>> edit: test/SILGen/foreach.swift
>> edit: test/IRGen/indirect_enum.sil
>> edit: test/SILOptimizer/deadargsignatureopt.sil
>> edit: test/IRGen/errors.sil
>> edit: test/IRGen/objc_class_export.swift
>> edit: test/SILGen/SILDeclRef.swift
>> edit: test/IRGen/c_function_pointer.sil
>> edit: test/SILOptimizer/functionsigopts.sil
>> edit: test/SILGen/objc_bridging.swift
>> edit: test/IRGen/partial_apply_forwarder.sil
>> edit: test/IRGen/partial_apply_objc.sil
>> edit: test/DebugInfo/basic.swift
>> edit: test/SourceKit/Demangle/demangle.swift
>> edit: test/IRGen/dynamic_init.sil
>> edit: test/SILGen/default_arguments.swift
>> edit: test/sil-func-extractor/load-serialized-sil.swift
>> edit: test/SILOptimizer/linker.swift
>> edit: test/sil-opt/si

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

[Erik Eckstein via swift-dev]

Mishal,

can you trigger a clean build for this?

Thanks,
Erik

> On Mar 16, 2017, at 2:31 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2428]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2428/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Thu, 16 Mar 2017 14:20:26 -0700
> Build duration:   10 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 9079 test(s), Total: 9079 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 415 test(s), Total: 415 test(s)
> 
> Changes
> 
> Commit 2a55b26e46693c7324d50c6a2acda3e8a478 by Erik Eckstein:
> Mangling: enable new mangling for symbols
> 
> edit: test/SILOptimizer/functionsigopts_sroa.sil
> edit: test/SILGen/closures.swift
> edit: test/IRGen/objc_attr_NSManaged.sil
> edit: test/IRGen/partial_apply.sil
> edit: include/swift/Demangling/ManglingMacros.h
> edit: test/SILGen/default_constructor.swift
> edit: test/DebugInfo/LinetableArtificialFn.swift
> edit: test/IRGen/special_protocols.sil
> edit: test/stdlib/Runtime.swift.gyb
> edit: test/IRGen/class.sil
> edit: test/IRGen/dllimport.swift
> edit: test/IRGen/enum_value_semantics_special_cases_objc.sil
> edit: test/SILOptimizer/bridged_casts_folding.swift
> edit: test/SILGen/accessibility_vtables.swift
> edit: test/IRGen/type_layout_reference_storage.swift
> edit: test/IRGen/enum_value_semantics.sil
> edit: test/SILGen/protocol_optional.swift
> edit: test/IRGen/sil_witness_methods.sil
> edit: test/IRGen/generic_types.swift
> edit: test/SILOptimizer/allocbox_to_stack.sil
> edit: validation-test/stdlib/MicroStdlib/Inputs/RuntimeStubs.c
> edit: test/SILOptimizer/closure_specialize_simple.sil
> edit: test/Frontend/Inputs/sil-primary-file-with-sib.sil
> edit: test/IRGen/dynamic_self_metadata.swift
> edit: test/IRGen/metadata_dominance.swift
> edit: test/SILGen/sil_locations.swift
> edit: test/IRGen/vtable.sil
> edit: test/IRGen/generic_casts.swift
> edit: test/SIL/Serialization/shared_function_serialization.sil
> edit: test/SILGen/witness-init-requirement-with-base-class-init.swift
> edit: test/SILGen/collection_upcast.swift
> edit: test/IRGen/swift3-metadata-coff.swift
> edit: test/Serialization/class-roundtrip-module.swift
> edit: test/DebugInfo/byref-capture.swift
> edit: test/SILGen/switch_objc.swift
> edit: test/DebugInfo/fnptr.swift
> edit: test/DebugInfo/typealias.swift
> edit: test/DebugInfo/inout.swift
> edit: test/IRGen/function_metadata.swift
> edit: test/IRGen/cf.sil
> edit: test/IRGen/struct_resilience.swift
> edit: test/SILGen/enum.swift
> edit: test/IRGen/field_type_vectors.sil
> edit: test/SILGen/vtable_thunks.swift
> edit: test/sil-nm/basic.sil
> edit: test/IDE/merge_local_types.swift
> edit: test/SILGen/extensions.swift
> edit: test/SILOptimizer/closure_specialize_consolidated.sil
> edit: test/SILGen/objc_bridging_any.swift
> edit: test/IRGen/indirect_argument.sil
> edit: test/SILGen/retaining_globals.swift
> edit: test/IRGen/type_layout_objc.swift
> edit: test/IDE/local_types.swift
> edit: test/SILGen/opaque_values_silgen_lib.swift
> edit: test/Serialization/inherited-initializer.swift
> edit: test/SILGen/optional_lvalue.swift
> edit: test/SILOptimizer/capture_promotion.sil
> edit: test/Serialization/class.swift
> edit: test/IDE/reconstruct_type_from_mangled_name_invalid.swift
> edit: test/SILOptimizer/capture_promotion_reachability.sil
> edit: test/DebugInfo/mangling.swift
> edit: test/DebugInfo/bool.swift
> edit: test/SILGen/default_arguments_imported.swift
> edit: test/SourceKit/CursorInfo/cursor_info.swift
> edit: test/IRGen/protocol_conformance_records.swift
> edit: test/DebugInfo/enum.swift
> edit: test/IRGen/class_resilience_objc_armv7k.swift
> edit: test/IRGen/enum_32_bit.sil
> edit: test/IRGen/generic_tuples.swift
> edit: test/DebugInfo/test_ints.swift
> edit: test/DebugInfo/typearg.swift
> edit: test/DebugInfo/mangling-stdlib.swift
> edit: test/SILGen/foreach.swift
> edit: test/IRGen/indirect_enum.sil
> edit: test/SILOptimizer/deadargsignatureopt.sil
> edit: test/IRGen/errors.sil
> edit: test/IRGen/objc_class_export.swift
> edit: test/SILGen/SILDeclRef.swift
> edit: test/IRGen/c_function_pointer.sil
> edit: test/SILOptimizer/functionsigopts.sil
> edit: test/SILGen/objc_bridging.swift
> edit: test/IRGen/partial_apply_forwarder.sil
> edit: test/IRGen/partial_apply_objc.sil
> edit: test/DebugInfo/basic.swift
> edit: test/SourceKit/Demangle/demangle.swift
> edit: test/IRGen/dynamic_init.sil
> edit: test/SILGen/default_arguments.swift
> edit: test/sil-func-extractor/load-serialized-sil.swift
> edit: test/SILOptimizer/linker.swift
> edit: test/sil-opt/sil-opt.swift
> edit: test/DebugInfo/test-foundation.swift
> edit: test/IRGen/enum_resilience.swift
> edit: test/IRGen/objc_generic_class_metadata.sil
> edit: test/SILGen/objc_thunks.swift
> edit: test/SILOptimizer/speci

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

[Erik Eckstein via swift-dev]

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


> On Feb 24, 2017, at 8:18 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#8561]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/8561/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Fri, 24 Feb 2017 20:16:27 -0800
> Build duration:   1 min 38 sec
> 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 7d7dc5aaac0f5581863c1d0d32fe5d2752d75e2a by eeckstein:
> Demangler: Use a bump-pointer allocator for node allocation.
> 
> edit: stdlib/public/Reflection/TypeRef.cpp
> edit: stdlib/public/runtime/Metadata.cpp
> edit: include/swift/Basic/Demangler.h
> edit: include/swift/Remote/MetadataReader.h
> edit: tools/SourceKit/tools/sourcekitd/lib/API/Requests.cpp
> edit: lib/Basic/Remangler.cpp
> edit: lib/IDE/TypeReconstruction.cpp
> edit: include/swift/Basic/DemangleWrappers.h
> edit: lib/Basic/Remangle.cpp
> edit: stdlib/public/Reflection/TypeRefBuilder.cpp
> edit: tools/swift-reflection-dump/swift-reflection-dump.cpp
> edit: tools/swift-demangle/swift-demangle.cpp
> edit: lib/Basic/Demangle.cpp
> edit: lib/SILOptimizer/Utils/SpecializationMangler.cpp
> edit: stdlib/public/runtime/Private.h
> edit: include/swift/Basic/Demangle.h
> edit: stdlib/public/runtime/Demangle.cpp
> edit: lib/Basic/Mangler.cpp
> edit: tools/swift-reflection-test/swift-reflection-test.c
> edit: lib/Basic/Demangler.cpp
> edit: stdlib/public/runtime/MetadataLookup.cpp
> edit: lib/Basic/DemangleWrappers.cpp
> edit: lib/RemoteAST/RemoteAST.cpp
> edit: stdlib/public/runtime/Casting.cpp

___
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 (master) #1877

[Erik Eckstein via swift-dev]

> On Feb 22, 2017, at 12:35 PM, Pierre Habouzit  wrote:
> 
> Note that you’ll face another issue that Daniel noticed, which is that we 
> have a new dependency on the linux kernel headers, usually in the 
> linux-libc-dev package on Debian and derivatives, and in linux-devel on 
> redhat derivatives.
> 
> We will work around the fact that we need this for now as it is not really 
> required for Intel, but by abandonning libkqueue (in this merge) and on the 
> long term libpwq and similar things, libdispatch on linux will start 
> requiring kernel headers more.
> 
> Can you adjust the CI scripts to make sure this dependency is added ?
> 

Forwarding this question to Mishal

> Thanks.
> 
> -Pierre
> 
>> On Feb 22, 2017, at 10:56 AM, Erik Eckstein via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Thanks! I’ll give it a try
>> 
>>> On Feb 22, 2017, at 10:55 AM, Daniel A. Steffen >> <mailto:dstef...@apple.com>> wrote:
>>> 
>>> 
>>>> On Feb 22, 2017, at 10:48, Erik Eckstein via swift-dev 
>>>> mailto:swift-dev@swift.org>> wrote:
>>>> 
>>>>> 
>>>>> On Feb 22, 2017, at 10:47 AM, Daniel A. Steffen >>>> <mailto:dstef...@apple.com>> wrote:
>>>>> 
>>>>> thanks, I don’t think Dave saw that locally in his testing but I believe 
>>>>> he is in the air now
>>>>> 
>>>>> does this block anything ?
>>>> 
>>>> yes, it’s blocking PR testing.
>>>> 
>>>>> I can disable the test temporarily if necessary, but one of the Linux 
>>>>> guys will probably have to debug (we certainly don’t see this on Darwin 
>>>>> internally)
>>>> 
>>>> yes, please
>>> 
>>> done
>>> 
>>> https://github.com/apple/swift-corelibs-libdispatch/pull/220 
>>> <https://github.com/apple/swift-corelibs-libdispatch/pull/220>
>>>> 
>>>>> 
>>>>>> On Feb 22, 2017, at 10:41, Erik Eckstein via swift-dev 
>>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>>> 
>>>>>> Now there is a fail in the tests:
>>>>>> 
>>>>>> https://ci.swift.org/job/swift-PR-Linux-smoke-test/5128/ 
>>>>>> <https://ci.swift.org/job/swift-PR-Linux-smoke-test/5128/>
>>>>>> 
>>>>>> FAIL: dispatch_context_for_key
>>>>>> ==
>>>>>> 
>>>>>> 
>>>>>> ==
>>>>>> [TEST] Dispatch Queue Specific
>>>>>> [PID] 40365
>>>>>> ==
>>>>>> 
>>>>>> 
>>>>>> [BEGIN] get context for app
>>>>>>  Actual: 0x40409c
>>>>>>  Expected: 0x40409c
>>>>>> [PASS] get context for app
>>>>>> 
>>>>>> [BEGIN] get context for key 2
>>>>>>  Actual: 0x4040b8
>>>>>>  Expected: 0x4040b8
>>>>>> [PASS] get context for key 2
>>>>>> 
>>>>>> [BEGIN] Process exited
>>>>>>  Actual: 1
>>>>>>  Expected: 0
>>>>>> [FAIL] Process exited (bsdtestharness.c:132)
>>>>>>  bsdtestharness.c:132
>>>>>> [PERF]   wall time: 0.66
>>>>>> [PERF]   user time: 0.064000
>>>>>> [PERF]   system time: 0.008000
>>>>>> [PERF]   max resident set size: 18356
>>>>>> [PERF]   page faults: 0
>>>>>> [PERF]   swaps: 0
>>>>>> [PERF]   voluntary context switches: 78
>>>>>> [PERF]   involuntary context switches: 10
>>>>>> FAIL dispatch_context_for_key (exit status: 1)
>>>>>> 
>>>>>> 
>>>>>> Testsuite summary for libdispatch 1.3
>>>>>> 
>>>>>> # TOTAL: 21
>>>>>> # PASS:  20
>>>>>> # SKIP:  0
>>>>>> # XFAIL: 0
>>>>>> # FAIL:  1
>>>>>> # XPASS: 0
>>>>>> # ERROR: 0
>>>>>> 
>>>>>> 
>>>>>>> On Feb 22, 2017, at 10:11 AM, Daniel 

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

[Erik Eckstein via swift-dev]

Thanks! I’ll give it a try

> On Feb 22, 2017, at 10:55 AM, Daniel A. Steffen  wrote:
> 
> 
>> On Feb 22, 2017, at 10:48, Erik Eckstein via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>>> 
>>> On Feb 22, 2017, at 10:47 AM, Daniel A. Steffen >> <mailto:dstef...@apple.com>> wrote:
>>> 
>>> thanks, I don’t think Dave saw that locally in his testing but I believe he 
>>> is in the air now
>>> 
>>> does this block anything ?
>> 
>> yes, it’s blocking PR testing.
>> 
>>> I can disable the test temporarily if necessary, but one of the Linux guys 
>>> will probably have to debug (we certainly don’t see this on Darwin 
>>> internally)
>> 
>> yes, please
> 
> done
> 
> https://github.com/apple/swift-corelibs-libdispatch/pull/220 
> <https://github.com/apple/swift-corelibs-libdispatch/pull/220>
>> 
>>> 
>>>> On Feb 22, 2017, at 10:41, Erik Eckstein via swift-dev 
>>>> mailto:swift-dev@swift.org>> wrote:
>>>> 
>>>> Now there is a fail in the tests:
>>>> 
>>>> https://ci.swift.org/job/swift-PR-Linux-smoke-test/5128/ 
>>>> <https://ci.swift.org/job/swift-PR-Linux-smoke-test/5128/>
>>>> 
>>>> FAIL: dispatch_context_for_key
>>>> ==
>>>> 
>>>> 
>>>> ==
>>>> [TEST] Dispatch Queue Specific
>>>> [PID] 40365
>>>> ==
>>>> 
>>>> 
>>>> [BEGIN] get context for app
>>>>Actual: 0x40409c
>>>>Expected: 0x40409c
>>>> [PASS] get context for app
>>>> 
>>>> [BEGIN] get context for key 2
>>>>Actual: 0x4040b8
>>>>Expected: 0x4040b8
>>>> [PASS] get context for key 2
>>>> 
>>>> [BEGIN] Process exited
>>>>Actual: 1
>>>>Expected: 0
>>>> [FAIL] Process exited (bsdtestharness.c:132)
>>>>bsdtestharness.c:132
>>>> [PERF] wall time: 0.66
>>>> [PERF] user time: 0.064000
>>>> [PERF] system time: 0.008000
>>>> [PERF] max resident set size: 18356
>>>> [PERF] page faults: 0
>>>> [PERF] swaps: 0
>>>> [PERF] voluntary context switches: 78
>>>> [PERF] involuntary context switches: 10
>>>> FAIL dispatch_context_for_key (exit status: 1)
>>>> 
>>>> 
>>>> Testsuite summary for libdispatch 1.3
>>>> 
>>>> # TOTAL: 21
>>>> # PASS:  20
>>>> # SKIP:  0
>>>> # XFAIL: 0
>>>> # FAIL:  1
>>>> # XPASS: 0
>>>> # ERROR: 0
>>>> 
>>>> 
>>>>> On Feb 22, 2017, at 10:11 AM, Daniel A. Steffen >>>> <mailto:dstef...@apple.com>> wrote:
>>>>> 
>>>>> +Erik
>>>>> 
>>>>> I merged
>>>>>   https://github.com/apple/swift-corelibs-libdispatch/pull/218 
>>>>> <https://github.com/apple/swift-corelibs-libdispatch/pull/218>
>>>>> which should fix this
>>>>> 
>>>>> Daniel
>>>>> 
>>>>>> On Feb 22, 2017, at 9:59, Daniel A. Steffen via swift-dev 
>>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>>> 
>>>>>> +phausler
>>>>>> 
>>>>>>> In file included from CoreFoundation/Collections.subproj/CFTree.c:12:
>>>>>>> In file included from 
>>>>>>> ../buildbot_incremental/foundation-linux-x86_64/Foundation/usr//lib/swift/CoreFoundation/CFInternal.h:838:
>>>>>>> In file included from 
>>>>>>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/buildbot_incremental/libdispatch-linux-x86_64/tests/dispatch/private.h:56:
>>>>>>> 
>>>>>>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/buildbot_incremental/libdispatch-linux-x86_64/tests/dispatch/source_private.h:81:33:
>>>>>>>  error: expected parameter declarator
>>>>>>> 
>>>>>>> API_DEPRECATED_WITH_REPLACEMENT("DI

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

[Erik Eckstein via swift-dev]

> On Feb 22, 2017, at 10:47 AM, Daniel A. Steffen  wrote:
> 
> thanks, I don’t think Dave saw that locally in his testing but I believe he 
> is in the air now
> 
> does this block anything ?

yes, it’s blocking PR testing.

> I can disable the test temporarily if necessary, but one of the Linux guys 
> will probably have to debug (we certainly don’t see this on Darwin internally)

yes, please

> 
>> On Feb 22, 2017, at 10:41, Erik Eckstein via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> Now there is a fail in the tests:
>> 
>> https://ci.swift.org/job/swift-PR-Linux-smoke-test/5128/ 
>> <https://ci.swift.org/job/swift-PR-Linux-smoke-test/5128/>
>> 
>> FAIL: dispatch_context_for_key
>> ==
>> 
>> 
>> ==
>> [TEST] Dispatch Queue Specific
>> [PID] 40365
>> ==
>> 
>> 
>> [BEGIN] get context for app
>>  Actual: 0x40409c
>>  Expected: 0x40409c
>> [PASS] get context for app
>> 
>> [BEGIN] get context for key 2
>>  Actual: 0x4040b8
>>  Expected: 0x4040b8
>> [PASS] get context for key 2
>> 
>> [BEGIN] Process exited
>>  Actual: 1
>>  Expected: 0
>> [FAIL] Process exited (bsdtestharness.c:132)
>>  bsdtestharness.c:132
>> [PERF]   wall time: 0.66
>> [PERF]   user time: 0.064000
>> [PERF]   system time: 0.008000
>> [PERF]   max resident set size: 18356
>> [PERF]   page faults: 0
>> [PERF]   swaps: 0
>> [PERF]   voluntary context switches: 78
>> [PERF]   involuntary context switches: 10
>> FAIL dispatch_context_for_key (exit status: 1)
>> 
>> 
>> Testsuite summary for libdispatch 1.3
>> 
>> # TOTAL: 21
>> # PASS:  20
>> # SKIP:  0
>> # XFAIL: 0
>> # FAIL:  1
>> # XPASS: 0
>> # ERROR: 0
>> 
>> 
>>> On Feb 22, 2017, at 10:11 AM, Daniel A. Steffen >> <mailto:dstef...@apple.com>> wrote:
>>> 
>>> +Erik
>>> 
>>> I merged
>>> https://github.com/apple/swift-corelibs-libdispatch/pull/218 
>>> <https://github.com/apple/swift-corelibs-libdispatch/pull/218>
>>> which should fix this
>>> 
>>> Daniel
>>> 
>>>> On Feb 22, 2017, at 9:59, Daniel A. Steffen via swift-dev 
>>>> mailto:swift-dev@swift.org>> wrote:
>>>> 
>>>> +phausler
>>>> 
>>>>> In file included from CoreFoundation/Collections.subproj/CFTree.c:12:
>>>>> In file included from 
>>>>> ../buildbot_incremental/foundation-linux-x86_64/Foundation/usr//lib/swift/CoreFoundation/CFInternal.h:838:
>>>>> In file included from 
>>>>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/buildbot_incremental/libdispatch-linux-x86_64/tests/dispatch/private.h:56:
>>>>> 
>>>>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/buildbot_incremental/libdispatch-linux-x86_64/tests/dispatch/source_private.h:81:33:
>>>>>  error: expected parameter declarator
>>>>> 
>>>>> API_DEPRECATED_WITH_REPLACEMENT("DISPATCH_SOURCE_TYPE_MEMORYPRESSURE",
>>>>> 
>>>> 
>>>> Dave, you didn’t see this in your local Linux testing right ?
>>>> 
>>>> I would have expected the following in dispatch/dispatch.h to provide a 
>>>> definition of API_DEPRECATED_WITH_REPLACEMENT() on Linux, I’m guessing 
>>>> that maybe that doesn’t trigger for CF because that its own fallback 
>>>> definition of API_AVAILABLE ? Philippe ?
>>>> 
>>>> #ifndef API_AVAILABLE
>>>> #define API_AVAILABLE(...)
>>>> #define API_DEPRECATED(...)
>>>> #define API_UNAVAILABLE(...)
>>>> #define API_DEPRECATED_WITH_REPLACEMENT(...)
>>>> #endif // !API_AVAILABLE
>>>> 
>>>> Daniel
>>>> 
>>>> 
>>>>> On Feb 22, 2017, at 9:49, no-re...@swift.org <mailto:no-re...@swift.org> 
>>>>> wrote:
>>>>> 
>>>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#1877]
>>>>> 
>>>>> Build URL:
>>>>> https

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

[Erik Eckstein via swift-dev]

Now there is a fail in the tests:

https://ci.swift.org/job/swift-PR-Linux-smoke-test/5128/ 


FAIL: dispatch_context_for_key
==


==
[TEST] Dispatch Queue Specific
[PID] 40365
==


[BEGIN] get context for app
Actual: 0x40409c
Expected: 0x40409c
[PASS] get context for app

[BEGIN] get context for key 2
Actual: 0x4040b8
Expected: 0x4040b8
[PASS] get context for key 2

[BEGIN] Process exited
Actual: 1
Expected: 0
[FAIL] Process exited (bsdtestharness.c:132)
bsdtestharness.c:132
[PERF]  wall time: 0.66
[PERF]  user time: 0.064000
[PERF]  system time: 0.008000
[PERF]  max resident set size: 18356
[PERF]  page faults: 0
[PERF]  swaps: 0
[PERF]  voluntary context switches: 78
[PERF]  involuntary context switches: 10
FAIL dispatch_context_for_key (exit status: 1)


Testsuite summary for libdispatch 1.3

# TOTAL: 21
# PASS:  20
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0


> On Feb 22, 2017, at 10:11 AM, Daniel A. Steffen  wrote:
> 
> +Erik
> 
> I merged
>   https://github.com/apple/swift-corelibs-libdispatch/pull/218 
> 
> which should fix this
> 
> Daniel
> 
>> On Feb 22, 2017, at 9:59, Daniel A. Steffen via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> +phausler
>> 
>>> In file included from CoreFoundation/Collections.subproj/CFTree.c:12:
>>> In file included from 
>>> ../buildbot_incremental/foundation-linux-x86_64/Foundation/usr//lib/swift/CoreFoundation/CFInternal.h:838:
>>> In file included from 
>>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/buildbot_incremental/libdispatch-linux-x86_64/tests/dispatch/private.h:56:
>>> 
>>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_04/buildbot_incremental/libdispatch-linux-x86_64/tests/dispatch/source_private.h:81:33:
>>>  error: expected parameter declarator
>>> 
>>> API_DEPRECATED_WITH_REPLACEMENT("DISPATCH_SOURCE_TYPE_MEMORYPRESSURE",
>>> 
>> 
>> Dave, you didn’t see this in your local Linux testing right ?
>> 
>> I would have expected the following in dispatch/dispatch.h to provide a 
>> definition of API_DEPRECATED_WITH_REPLACEMENT() on Linux, I’m guessing that 
>> maybe that doesn’t trigger for CF because that its own fallback definition 
>> of API_AVAILABLE ? Philippe ?
>> 
>> #ifndef API_AVAILABLE
>> #define API_AVAILABLE(...)
>> #define API_DEPRECATED(...)
>> #define API_UNAVAILABLE(...)
>> #define API_DEPRECATED_WITH_REPLACEMENT(...)
>> #endif // !API_AVAILABLE
>> 
>> Daniel
>> 
>> 
>>> On Feb 22, 2017, at 9:49, no-re...@swift.org  
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#1877]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/1877/ 
>>> 
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_04
>>> Date of build:  Wed, 22 Feb 2017 09:28:46 -0800
>>> Build duration: 20 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 b213f5603334c166a7919c2444b8bf47e15035b6 by bbuegling:
>>> Do not process dependencies of cancelled commands
>>> 
>>> edit: lib/BuildSystem/BuildSystem.cpp
>>> edit: lib/BuildSystem/SwiftTools.cpp
>>> edit: lib/BuildSystem/ExternalCommand.cpp
>>> edit: lib/BuildSystem/LaneBasedExecutionQueue.cpp
>>> edit: products/libllbuild/BuildSystem-C-API.cpp
>>> edit: unittests/BuildSystem/BuildSystemTaskTests.cpp
>>> edit: include/llbuild/BuildSystem/ExternalCommand.h
>>> edit: include/llbuild/BuildSystem/BuildExecutionQueue.h
>>> edit: lib/BuildSystem/BuildExecutionQueue.cpp
>>> edit: unittests/BuildSystem/MockBuildSystemDelegate.h
>>> 
>>> Commit 0d24de788fe596814723a4fb8fe7a18b1dbf67c1 by rlevenstein:
>>> [sil-combine] Add peephole: alloc_ref/set_deallocating/dealloc_ref ->
>>> 
>>> edit: test/SILOptimizer/sil_combine.sil
>>> edit: lib/SILOptimizer/SILCombiner/SILCombiner.h
>>> edit: lib/SILOptimizer/SILCombiner/SILCombinerMiscVisitors.cpp
>>> 
>>> Commit 4eae3cd756d1a2fb6062e0411dd1230f7f70e5da by dsteffen:
>>> [SE-0111] Update for removal of argument labels from function types
>>> 
>>> edit: src/swift/Wrapper.swift
>>> edit: src/swift/Data.swift
>>> edit: src/swift/IO.swift
>>> 
>>> Commit 623e47492af6d46f85e59966816d6c306e33f699 by dsteffen:

[swift-dev] linux pr testing is broken

[Erik Eckstein via swift-dev]

Hi Danial,

Looks like your recent merge in libdispatch broke the linux PR bot:

https://ci.swift.org/job/swift-PR-Linux-smoke-test/5126/ 



/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/buildbot_linux/libdispatch-linux-x86_64/tests/dispatch/source_private.h:81:33:
 error: expected parameter declarator
API_DEPRECATED_WITH_REPLACEMENT("DISPATCH_SOURCE_TYPE_MEMORYPRESSURE",
^
/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/buildbot_linux/libdispatch-linux-x86_64/tests/dispatch/source_private.h:81:33:
 error: expected ')'

Can you please fix or revert?

Thanks,
Erik
___
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.10 (master) #1923

[Erik Eckstein via swift-dev]

The clean build passed.

> On Feb 15, 2017, at 2:44 PM, Erik Eckstein  wrote:
> 
> Well, it might be a build-problem. I cannot reproduce it locally.
> I’ll try to make a clean build first before I revert.
> 
>> On Feb 15, 2017, at 1:36 PM, Erik Eckstein via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> That’s me.
>> I’m going to revert
>> 
>>> On Feb 15, 2017, at 1:30 PM, no-re...@swift.org <mailto:no-re...@swift.org> 
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1923]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1923/ 
>>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1923/>
>>> Project:oss-swift-incremental-RA-linux-ubuntu-16_10
>>> Date of build:  Wed, 15 Feb 2017 13:13:47 -0800
>>> Build duration: 16 min
>>> Tests:
>>> 
>>> Name: Swift(linux-x86_64)
>>> Failed: 0 test(s), Passed: 8976 test(s), Total: 8976 test(s)
>>> Name: Swift-Unit
>>> Failed: 0 test(s), Passed: 310 test(s), Total: 310 test(s)
>>> 
>>> Changes
>>> 
>>> Commit ca906d1e9998763e4691acac7514e986357ef94d by kyrtzidis:
>>> Add '-Fsystem' framework search option to indicate path for frameworks
>>> 
>>> edit: lib/Driver/ToolChains.cpp
>>> edit: lib/Frontend/CompilerInvocation.cpp
>>> edit: lib/Serialization/Serialization.cpp
>>> edit: tools/SourceKit/lib/SwiftLang/SwiftEditorInterfaceGen.cpp
>>> edit: lib/ClangImporter/ClangImporter.cpp
>>> edit: include/swift/AST/ClangModuleLoader.h
>>> edit: include/swift/ClangImporter/ClangImporter.h
>>> edit: lib/AST/ASTContext.cpp
>>> edit: tools/sil-opt/SILOpt.cpp
>>> edit: lib/Serialization/SerializedModuleLoader.cpp
>>> edit: test/Driver/driver-compile.swift
>>> add: 
>>> test/ClangImporter/Inputs/systemframeworks/Module.framework/Modules/module.modulemap
>>> edit: include/swift/Serialization/ModuleFile.h
>>> edit: include/swift/Serialization/ModuleFormat.h
>>> edit: include/swift/AST/ASTContext.h
>>> add: test/ClangImporter/system-framework-search-path.swift
>>> add: 
>>> test/ClangImporter/Inputs/systemframeworks/Module.framework/Headers/Module.h
>>> edit: tools/swift-ide-test/swift-ide-test.cpp
>>> edit: lib/Serialization/ModuleFile.cpp
>>> edit: include/swift/Option/Options.td
>>> edit: test/Serialization/search-paths-relative.swift
>>> edit: lib/Immediate/Immediate.cpp
>>> edit: include/swift/Frontend/Frontend.h
>>> edit: tools/swift-api-digester/swift-api-digester.cpp
>>> edit: tools/sil-llvm-gen/SILLLVMGen.cpp
>>> edit: include/swift/AST/SearchPathOptions.h
>>> edit: tools/lldb-moduleimport-test/lldb-moduleimport-test.cpp
>>> edit: test/Serialization/search-paths.swift
>>> 
>>> Commit 497cac64d9bcd03d80d7aab87ffcf03534afcdf5 by beanz:
>>> [CMake] Add support for Swift buildtrees including CMake packages
>>> 
>>> edit: cmake/modules/AddSwift.cmake
>>> add: cmake/modules/SwiftConfig.cmake.in
>>> add: cmake/modules/CMakeLists.txt
>>> edit: CMakeLists.txt
>>> 
>>> Commit 89b038ea7e6db3e289cbd76b8d8a4e4019cd1e96 by beanz:
>>> [CMake] Include the CMark exports in SwiftConfig.cmake
>>> 
>>> edit: cmake/modules/SwiftConfig.cmake.in
>>> 
>>> Commit e8645f37503202ebdb07e1a725111aa1c13745d6 by beanz:
>>> [CMake] A few fixups to the Swift CMake package generation
>>> 
>>> edit: cmake/modules/CMakeLists.txt
>>> edit: cmake/modules/SwiftConfig.cmake.in
>>> 
>>> Commit 32e5112874db157b247aa560f25738a173e128dd by kyrtzidis:
>>> For the -Fsystem option, address feedback by Jordan.
>>> 
>>> edit: lib/Driver/ToolChains.cpp
>>> edit: tools/SourceKit/lib/SwiftLang/SwiftEditorInterfaceGen.cpp
>>> edit: include/swift/Option/Options.td
>>> edit: lib/Frontend/CompilerInvocation.cpp
>>> 
>>> Commit 86e7bdeed859b3e3ca5264b0d4184b5613d7e7e0 by eeckstein:
>>> Demangler: Use a fixed-size array for Word substitutions.
>>> 
>>> edit: lib/Basic/Demangler.cpp
>>> edit: include/swift/Basic/Demangler.h
>>> 
>>> Commit 2d127e4192771fd3ebea7ca231e0a7459b6af754 by eeckstein:
>>> Reinstate ”Use the new mangling for reflection."
>>> 
>>> edit: test/IRGen/generic_classes.sil
>>> edit: stdlib/public/runtime/Dem

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

[Erik Eckstein via swift-dev]

Well, it might be a build-problem. I cannot reproduce it locally.
I’ll try to make a clean build first before I revert.

> On Feb 15, 2017, at 1:36 PM, Erik Eckstein via swift-dev 
>  wrote:
> 
> That’s me.
> I’m going to revert
> 
>> On Feb 15, 2017, at 1:30 PM, no-re...@swift.org <mailto:no-re...@swift.org> 
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1923]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1923/ 
>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1923/>
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Wed, 15 Feb 2017 13:13:47 -0800
>> Build duration:  16 min
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8976 test(s), Total: 8976 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 310 test(s), Total: 310 test(s)
>> 
>> Changes
>> 
>> Commit ca906d1e9998763e4691acac7514e986357ef94d by kyrtzidis:
>> Add '-Fsystem' framework search option to indicate path for frameworks
>> 
>> edit: lib/Driver/ToolChains.cpp
>> edit: lib/Frontend/CompilerInvocation.cpp
>> edit: lib/Serialization/Serialization.cpp
>> edit: tools/SourceKit/lib/SwiftLang/SwiftEditorInterfaceGen.cpp
>> edit: lib/ClangImporter/ClangImporter.cpp
>> edit: include/swift/AST/ClangModuleLoader.h
>> edit: include/swift/ClangImporter/ClangImporter.h
>> edit: lib/AST/ASTContext.cpp
>> edit: tools/sil-opt/SILOpt.cpp
>> edit: lib/Serialization/SerializedModuleLoader.cpp
>> edit: test/Driver/driver-compile.swift
>> add: 
>> test/ClangImporter/Inputs/systemframeworks/Module.framework/Modules/module.modulemap
>> edit: include/swift/Serialization/ModuleFile.h
>> edit: include/swift/Serialization/ModuleFormat.h
>> edit: include/swift/AST/ASTContext.h
>> add: test/ClangImporter/system-framework-search-path.swift
>> add: 
>> test/ClangImporter/Inputs/systemframeworks/Module.framework/Headers/Module.h
>> edit: tools/swift-ide-test/swift-ide-test.cpp
>> edit: lib/Serialization/ModuleFile.cpp
>> edit: include/swift/Option/Options.td
>> edit: test/Serialization/search-paths-relative.swift
>> edit: lib/Immediate/Immediate.cpp
>> edit: include/swift/Frontend/Frontend.h
>> edit: tools/swift-api-digester/swift-api-digester.cpp
>> edit: tools/sil-llvm-gen/SILLLVMGen.cpp
>> edit: include/swift/AST/SearchPathOptions.h
>> edit: tools/lldb-moduleimport-test/lldb-moduleimport-test.cpp
>> edit: test/Serialization/search-paths.swift
>> 
>> Commit 497cac64d9bcd03d80d7aab87ffcf03534afcdf5 by beanz:
>> [CMake] Add support for Swift buildtrees including CMake packages
>> 
>> edit: cmake/modules/AddSwift.cmake
>> add: cmake/modules/SwiftConfig.cmake.in
>> add: cmake/modules/CMakeLists.txt
>> edit: CMakeLists.txt
>> 
>> Commit 89b038ea7e6db3e289cbd76b8d8a4e4019cd1e96 by beanz:
>> [CMake] Include the CMark exports in SwiftConfig.cmake
>> 
>> edit: cmake/modules/SwiftConfig.cmake.in
>> 
>> Commit e8645f37503202ebdb07e1a725111aa1c13745d6 by beanz:
>> [CMake] A few fixups to the Swift CMake package generation
>> 
>> edit: cmake/modules/CMakeLists.txt
>> edit: cmake/modules/SwiftConfig.cmake.in
>> 
>> Commit 32e5112874db157b247aa560f25738a173e128dd by kyrtzidis:
>> For the -Fsystem option, address feedback by Jordan.
>> 
>> edit: lib/Driver/ToolChains.cpp
>> edit: tools/SourceKit/lib/SwiftLang/SwiftEditorInterfaceGen.cpp
>> edit: include/swift/Option/Options.td
>> edit: lib/Frontend/CompilerInvocation.cpp
>> 
>> Commit 86e7bdeed859b3e3ca5264b0d4184b5613d7e7e0 by eeckstein:
>> Demangler: Use a fixed-size array for Word substitutions.
>> 
>> edit: lib/Basic/Demangler.cpp
>> edit: include/swift/Basic/Demangler.h
>> 
>> Commit 2d127e4192771fd3ebea7ca231e0a7459b6af754 by eeckstein:
>> Reinstate ”Use the new mangling for reflection."
>> 
>> edit: test/IRGen/generic_classes.sil
>> edit: stdlib/public/runtime/Demangle.cpp
>> edit: lib/IRGen/GenMeta.cpp
>> edit: lib/IRGen/Linking.cpp
>> edit: stdlib/public/Reflection/Demangle.cpp
>> edit: stdlib/public/runtime/Remangle.cpp
>> edit: tools/swift-demangle/swift-demangle.cpp
>> edit: stdlib/public/Reflection/TypeLowering.cpp
>> edit: test/stdlib/RuntimeObjC.swift
>> edit: lib/Basic/Remangle.cpp
>> edit: include/swift/Basic/Demangle.h
>> edit: include/swift/Reflection/TypeRef.h
>> edit: test/Reflection/typeref_lower

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

[Erik Eckstein via swift-dev]

That’s me.
I’m going to revert

> On Feb 15, 2017, at 1:30 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1923]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/1923/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-16_10
> Date of build:Wed, 15 Feb 2017 13:13:47 -0800
> Build duration:   16 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8976 test(s), Total: 8976 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 310 test(s), Total: 310 test(s)
> 
> Changes
> 
> Commit ca906d1e9998763e4691acac7514e986357ef94d by kyrtzidis:
> Add '-Fsystem' framework search option to indicate path for frameworks
> 
> edit: lib/Driver/ToolChains.cpp
> edit: lib/Frontend/CompilerInvocation.cpp
> edit: lib/Serialization/Serialization.cpp
> edit: tools/SourceKit/lib/SwiftLang/SwiftEditorInterfaceGen.cpp
> edit: lib/ClangImporter/ClangImporter.cpp
> edit: include/swift/AST/ClangModuleLoader.h
> edit: include/swift/ClangImporter/ClangImporter.h
> edit: lib/AST/ASTContext.cpp
> edit: tools/sil-opt/SILOpt.cpp
> edit: lib/Serialization/SerializedModuleLoader.cpp
> edit: test/Driver/driver-compile.swift
> add: 
> test/ClangImporter/Inputs/systemframeworks/Module.framework/Modules/module.modulemap
> edit: include/swift/Serialization/ModuleFile.h
> edit: include/swift/Serialization/ModuleFormat.h
> edit: include/swift/AST/ASTContext.h
> add: test/ClangImporter/system-framework-search-path.swift
> add: 
> test/ClangImporter/Inputs/systemframeworks/Module.framework/Headers/Module.h
> edit: tools/swift-ide-test/swift-ide-test.cpp
> edit: lib/Serialization/ModuleFile.cpp
> edit: include/swift/Option/Options.td
> edit: test/Serialization/search-paths-relative.swift
> edit: lib/Immediate/Immediate.cpp
> edit: include/swift/Frontend/Frontend.h
> edit: tools/swift-api-digester/swift-api-digester.cpp
> edit: tools/sil-llvm-gen/SILLLVMGen.cpp
> edit: include/swift/AST/SearchPathOptions.h
> edit: tools/lldb-moduleimport-test/lldb-moduleimport-test.cpp
> edit: test/Serialization/search-paths.swift
> 
> Commit 497cac64d9bcd03d80d7aab87ffcf03534afcdf5 by beanz:
> [CMake] Add support for Swift buildtrees including CMake packages
> 
> edit: cmake/modules/AddSwift.cmake
> add: cmake/modules/SwiftConfig.cmake.in
> add: cmake/modules/CMakeLists.txt
> edit: CMakeLists.txt
> 
> Commit 89b038ea7e6db3e289cbd76b8d8a4e4019cd1e96 by beanz:
> [CMake] Include the CMark exports in SwiftConfig.cmake
> 
> edit: cmake/modules/SwiftConfig.cmake.in
> 
> Commit e8645f37503202ebdb07e1a725111aa1c13745d6 by beanz:
> [CMake] A few fixups to the Swift CMake package generation
> 
> edit: cmake/modules/CMakeLists.txt
> edit: cmake/modules/SwiftConfig.cmake.in
> 
> Commit 32e5112874db157b247aa560f25738a173e128dd by kyrtzidis:
> For the -Fsystem option, address feedback by Jordan.
> 
> edit: lib/Driver/ToolChains.cpp
> edit: tools/SourceKit/lib/SwiftLang/SwiftEditorInterfaceGen.cpp
> edit: include/swift/Option/Options.td
> edit: lib/Frontend/CompilerInvocation.cpp
> 
> Commit 86e7bdeed859b3e3ca5264b0d4184b5613d7e7e0 by eeckstein:
> Demangler: Use a fixed-size array for Word substitutions.
> 
> edit: lib/Basic/Demangler.cpp
> edit: include/swift/Basic/Demangler.h
> 
> Commit 2d127e4192771fd3ebea7ca231e0a7459b6af754 by eeckstein:
> Reinstate ”Use the new mangling for reflection."
> 
> edit: test/IRGen/generic_classes.sil
> edit: stdlib/public/runtime/Demangle.cpp
> edit: lib/IRGen/GenMeta.cpp
> edit: lib/IRGen/Linking.cpp
> edit: stdlib/public/Reflection/Demangle.cpp
> edit: stdlib/public/runtime/Remangle.cpp
> edit: tools/swift-demangle/swift-demangle.cpp
> edit: stdlib/public/Reflection/TypeLowering.cpp
> edit: test/stdlib/RuntimeObjC.swift
> edit: lib/Basic/Remangle.cpp
> edit: include/swift/Basic/Demangle.h
> edit: include/swift/Reflection/TypeRef.h
> edit: test/Reflection/typeref_lowering_objc.swift
> edit: lib/IRGen/GenReflection.cpp
> edit: test/Reflection/typeref_lowering.swift
> edit: test/Interpreter/SDK/archiving_generic_swift_class.swift
> edit: lib/Basic/Remangler.cpp
> edit: lib/Basic/Demangle.cpp
> edit: test/IRGen/cf.sil
> edit: test/Reflection/typeref_lowering_missing.swift
> edit: stdlib/public/Reflection/TypeRefBuilder.cpp
> edit: stdlib/public/runtime/Metadata.cpp
> edit: test/Reflection/typeref_lowering_imported.swift
> edit: lib/Basic/Mangler.cpp
> edit: lib/SILOptimizer/Utils/SpecializationMangler.cpp
> edit: test/IRGen/generic_structs.sil
> edit: stdlib/public/Reflection/Remangle.cpp
> edit: test/IRGen/enum.sil
> 
> Commit e6ce2ff388a8da3a14882939132ff1b7279b3cde by beanz:
> [CMake] Fixing up CMark exports to expand at configuration
> 
> edit: cmake/modules/SwiftConfig.cmake.in
> 
> Commit bf661853f6c189c211a2ec8f58a47d62a97dd982 by aschwaighofer:
> AddressSanitizer: don't track swifterror memory addresses
> 
> edit: test/Instrumentation/AddressSa

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

[Erik Eckstein via swift-dev]

I’m not sure if I understood.
What if there is a call to a function and that conditionally calls a noreturn 
function:

func foo() {
  let x = Myclass()
  bar(true)
  // release x here?
}

func bar(_ dontReturn: Bool) {
  if (dontReturn) {
noreturn_func()
  }
}

Is it even possible to “clean up before” in such a case?

Erik

> On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
>> 
>> On Feb 6, 2017, at 11:44 AM, Jordan Rose > > wrote:
>> 
>> 
>>> On Feb 6, 2017, at 11:25, Joe Groff via swift-dev >> > wrote:
>>> 
>>> 
 On Feb 6, 2017, at 11:22 AM, Michael Gottesman >>> > wrote:
 
 Here is my suggestion:
 
 1. We assume by default the leaking case.
 2. We change noreturn functions from C to maybe have a special semantic 
 tag on them that says that cleanups should occur before them (i.e. 
 UIApplicationMain).
>> 
>> I'm not sure what you mean by this. Functions from C exist in both groups, 
>> and I don't see why one assumption is better than the other.
>> 
>> 
>>> 
>>> I feel that "clean up before" is the safer ground case, and if we do any 
>>> work to whitelist a group, it should be for the common "leakable" 
>>> noreturns, like exit/_exit/abort/fatalError. That way, we momentarily burn 
>>> some pointless cycles in the case we get it "wrong" rather than permanently 
>>> leak memory.
>> 
>> I don't like this because of the reverse issue: under -Onone, you may want 
>> to pop back up the stack in the debugger and see what values you had, and 
>> they won't be available. It's almost always possible to get things released 
>> sooner; usually more awkward to get them to stay alive.
> 
> On the other hand, this is safe to do in the short term. We can special case 
> asserts. One thing to consider though is if this should be provided to users. 
> If not, we can just use semantics. Otherwise, we would need to discuss how to 
> surface this at the language level.
> 
> Michael
> 
>> 
>> Jordan
> 
> ___
> 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.10 (master) #1699

[Erik Eckstein via swift-dev]

> On Feb 6, 2017, at 2:17 PM, mishal_shah  wrote:
> 
> Hi Erik,
> 
> Please try “@swift-ci Please clean test”. This will clean up the workspace 
> before building. 

Thanks! That worked!

> 
> Thanks, 
> Mishal Shah
>> On Feb 6, 2017, at 2:08 PM, Erik Eckstein via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> Is there a workaround?
>> PR testing is blocked on this.
>> 
>>> On Feb 3, 2017, at 11:13 AM, Douglas Gregor via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> 
>>>> On Feb 3, 2017, at 11:12 AM, Michael Ilseman >>> <mailto:milse...@apple.com>> wrote:
>>>> 
>>>> Is that a missing dependency in CMake then?
>>> 
>>> They’re totally separate projects (swift vs. swift-corelibs-foundation), so 
>>> it’s an issue with cross-project dependencies.
>>> 
>>> - Doug
>>> 
>>> 
>>>> 
>>>>> On Feb 3, 2017, at 10:40 AM, Douglas Gregor >>>> <mailto:dgre...@apple.com>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Feb 3, 2017, at 10:37 AM, Ankit Aggarwal >>>>> <mailto:ankit_aggar...@apple.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 03-Feb-2017, at 11:55 PM, Douglas Gregor >>>>>> <mailto:dgre...@apple.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Feb 3, 2017, at 10:24 AM, Michael Ilseman >>>>>>> <mailto:milse...@apple.com>> wrote:
>>>>>>>> 
>>>>>>>> Doug G, is this this same issue you’re working on, or a different one?
>>>>>>> 
>>>>>>> Oooh, could be different! Ankit, is this only on Linux?
>>>>>>> 
>>>>>> 
>>>>>> Looks likes it happened only on the ubuntu 1610 incremental bot once 
>>>>>> (#1699). The builds after this failure are blue 
>>>>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/ 
>>>>>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/>
>>>>>> 
>>>>>> I did not hit this locally or on PR bots (which are macOS and 1604).
>>>>> 
>>>>> Oh! This is actually sensitive to the standard library not getting 
>>>>> rebuilt fully before SwiftPM gets built, which is an issue we’ve seen 
>>>>> with Foundation failing in incremental PR testing.
>>>>> 
>>>>>   - Doug
>>>>> 
>>>>>> 
>>>>>>> - Doug
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Feb 3, 2017, at 5:52 AM, Ankit Aggarwal >>>>>>>> <mailto:ankit_aggar...@apple.com>> wrote:
>>>>>>>>> 
>>>>>>>>> Hm there is a compiler crash is in SwiftPM's Basic module but that 
>>>>>>>>> wasn't touched by my commit.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Compile Swift Module 'Basic' (23 sources)
>>>>>>>>> swift: 
>>>>>>>>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/lib/AST/ArchetypeBuilder.cpp:2461:
>>>>>>>>>  auto 
>>>>>>>>> swift::ArchetypeBuilder::getGenericEnvironment(swift::GenericSignature
>>>>>>>>>  *)::(anonymous 
>>>>>>>>> class)::operator()(swift::ArchetypeBuilder::PotentialArchetype *) 
>>>>>>>>> const: Assertion `(inContext->isEqual(repInContext) || 
>>>>>>>>> inContext->hasError() || repInContext->hasError()) && "Potential 
>>>>>>>>> archetype mapping differs from representative!"' failed.
>>>>>>>>> 0  swift   0x038aaf48
>>>>>>>>> 1  swift   0x038ab686
>>>>>>>>> 2  libpthread.so.0 0x7f6105a83670
>>>>>>>>> 3  libc.so.6   0x7f61045fe7ef gsignal + 159
>>>>>>>>> 4  libc.so.6   0x7f61046003ea abort + 362
>>>>>>>>> 5  libc.so.6   0x7f61045f6bb7
>>>>>>>>> 6  libc.so.6 

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

[Erik Eckstein via swift-dev]

Is there a workaround?
PR testing is blocked on this.

> On Feb 3, 2017, at 11:13 AM, Douglas Gregor via swift-dev 
>  wrote:
> 
> 
>> On Feb 3, 2017, at 11:12 AM, Michael Ilseman > > wrote:
>> 
>> Is that a missing dependency in CMake then?
> 
> They’re totally separate projects (swift vs. swift-corelibs-foundation), so 
> it’s an issue with cross-project dependencies.
> 
>   - Doug
> 
> 
>> 
>>> On Feb 3, 2017, at 10:40 AM, Douglas Gregor >> > wrote:
>>> 
 
 On Feb 3, 2017, at 10:37 AM, Ankit Aggarwal >>> > wrote:
 
 
> On 03-Feb-2017, at 11:55 PM, Douglas Gregor  > wrote:
> 
> 
>> On Feb 3, 2017, at 10:24 AM, Michael Ilseman > > wrote:
>> 
>> Doug G, is this this same issue you’re working on, or a different one?
> 
> Oooh, could be different! Ankit, is this only on Linux?
> 
 
 Looks likes it happened only on the ubuntu 1610 incremental bot once 
 (#1699). The builds after this failure are blue 
 https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/ 
 
 
 I did not hit this locally or on PR bots (which are macOS and 1604).
>>> 
>>> Oh! This is actually sensitive to the standard library not getting rebuilt 
>>> fully before SwiftPM gets built, which is an issue we’ve seen with 
>>> Foundation failing in incremental PR testing.
>>> 
>>> - Doug
>>> 
 
>   - Doug
> 
>> 
>> 
>>> On Feb 3, 2017, at 5:52 AM, Ankit Aggarwal >> > wrote:
>>> 
>>> Hm there is a compiler crash is in SwiftPM's Basic module but that 
>>> wasn't touched by my commit.
>>> 
>>> 
>>> Compile Swift Module 'Basic' (23 sources)
>>> swift: 
>>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swift/lib/AST/ArchetypeBuilder.cpp:2461:
>>>  auto 
>>> swift::ArchetypeBuilder::getGenericEnvironment(swift::GenericSignature 
>>> *)::(anonymous 
>>> class)::operator()(swift::ArchetypeBuilder::PotentialArchetype *) 
>>> const: Assertion `(inContext->isEqual(repInContext) || 
>>> inContext->hasError() || repInContext->hasError()) && "Potential 
>>> archetype mapping differs from representative!"' failed.
>>> 0  swift   0x038aaf48
>>> 1  swift   0x038ab686
>>> 2  libpthread.so.0 0x7f6105a83670
>>> 3  libc.so.6   0x7f61045fe7ef gsignal + 159
>>> 4  libc.so.6   0x7f61046003ea abort + 362
>>> 5  libc.so.6   0x7f61045f6bb7
>>> 6  libc.so.6   0x7f61045f6c62
>>> 7  swift   0x0132700b
>>> 8  swift   0x012ca979
>>> 9  swift   0x012a6b96
>>> 10 swift   0x0129b41a
>>> 11 swift   0x0129c1a0
>>> 12 swift   0x014198db
>>> 13 swift   0x012ccd26
>>> 14 swift   0x012ccbd7
>>> 15 swift   0x01255e3d
>>> 16 swift   0x0121f6f1
>>> 17 swift   0x012210ee
>>> 18 swift   0x0121dfbb
>>> 19 swift   0x0130923e
>>> 20 swift   0x01300db0
>>> 21 swift   0x01305be8
>>> 22 swift   0x013b3a9c
>>> 23 swift   0x013b07cb
>>> 24 swift   0x012fdad1
>>> 25 swift   0x0122dc9d
>>> 26 swift   0x012892a4
>>> 27 swift   0x0128c916
>>> 28 swift   0x01290631
>>> 29 swift   0x01290fa8
>>> 30 swift   0x011a35c1
>>> 31 swift   0x011a2ebd
>>> 32 swift   0x011a129d
>>> 33 swift   0x011a1108
>>> 34 swift   0x011a1e21
>>> 35 swift   0x011b79f8
>>> 36 swift   0x011b8755
>>> 37 swift   0x00f0e06a
>>> 38 swift   0x004a5e56
>>> 39 swift   0x004643c7
>>> 40 libc.so.6   0x7f61045e93f1 __libc_start_main + 241
>>> 41 swift   0x00461a6a
>>> Stack dump:
>>> 0.  Program arguments: 
>>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift
>>>  -frontend -c 
>>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swiftpm/Sources/Basic/TemporaryFile.swift
>>>  
>>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/swiftpm/Sources/Basic/Path.swift
>>>  
>>> /home/buildnode/disk1/workspace/oss-swift-incremental-RA-linux-ubuntu

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

[Erik Eckstein via swift-dev]

> On Jan 24, 2017, at 10:52 PM, Andrew Trick  wrote:
> 
> So it looks like the Foundation tests haven’t been run for a few builds. 
> Taking a wild guess, could this have something to do with mangling Erik?
> 

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

Re: [swift-dev] Inability to leverage privacy in the stdlib

[Erik Eckstein via swift-dev]

> On Oct 28, 2016, at 5:01 PM, Jordan Rose  wrote:
> 
> 
>> On Oct 28, 2016, at 17:00, Erik Eckstein > > wrote:
>> 
>>> 
>>> On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev >> > wrote:
>>> 
>>> 
 On Oct 23, 2016, at 16:13, Michael Gottesman >>> > wrote:
 
 
> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> 
> Dave pointed out to me this week that the build crashes if the stdlib 
> tries to use private/fileprivate. I tried it myself and lo and behold the 
> linker can't find the private symbols. He couldn't recall what about the 
> build caused that, though.
> 
> Can anyone recall why this is? How hard is it to fix?
 
 I am not 100% sure, but if it happens only with the stdlib and has to do 
 with access control, I wouldn't be surprised if it has to do with 
 -sil-serialize-all and friends. But I may be correct. I think Jordan is 
 the right person to answer this question.
>>> 
>>> I don't have it all paged in, but there are three main pieces I remember:
>>> 
>>> - Private and fileprivate decls can of course conflict across file 
>>> boundaries, which means it's possible we wouldn't be able to rebuild the 
>>> standard library from textual SIL. I think this is just a hypothetical 
>>> concern, since we don't actually have a reason to reuse names.
>>> 
>>> - Textual SIL again: the mangling for a private decl depends on its file. 
>>> We could fix this with an attribute that hardcodes manglings, or hardcodes 
>>> a private discriminator, or something. (We also have a bug today where 
>>> multiple 'private' decls in the same file will conflict in their mangling.)
>>> 
>>> - The standard library currently builds with -sil-serialize-all ("magic 
>>> performance mode") to make everything inlinable. This option currently 
>>> mucks with linkages at the SIL level in a fairly unprincipled way.
>> 
>> This was the case (long time ago). But now the SIL linkage is not affected 
>> by -sil-serialize-all, just the llvm linkage.
>> But maybe you are referring to another issue.
> 
> Then I guess it’s the same issue the other way around: we don’t muck with the 
> real linkage enough to make the symbols actually public. Again, being 
> principled about what an inlinable function can and can’t refer to would help 
> here.

Currently the rule is that a fragile function (= inlinable, AFAIK) cannot call 
a non-public non-fragile function. And with -sil-serialize-all all functions 
are set to fragile.
This is checked in the SILVerifier, which is of course not the right way to do 
the check (Slava told me he is going to make this a compiler warning instead, 
or something like this).

> 
>> 
>>> This is probably the underlying cause of whatever linking issues you're 
>>> seeing, but even if it's not it would probably get in the way of trying to 
>>> fix things.
>>> 
>>> docs/AccessControlInStdlib.rst points to another, similar issue: 
>>> > Figure out how inlined 
>>> XREFs to private entities work. Our planned answer for this is that 
>>> inlinable things can't reference private entities, only internal ones (and 
>>> even then only those marked as "versioned"). That's a bit annoying, but 
>>> does correspond with the notion that a versioned entity is an ABI promise, 
>>> and the file you declare something in should never be part of the library's 
>>> ABI. (There are other answers that could work here, of course.)
>>> 
>>> Fortunately those last issues are something we need to fix anyway as part 
>>> of deciding which parts of the standard library should be resilient and 
>>> which parts are fragile, so maybe we'll be in a good enough place to start 
>>> allowing private decls again later this release.
>>> 
>>> Jordan
>>> 
>>> 
>>> 
>>> ___
>>> 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] Inability to leverage privacy in the stdlib

[Erik Eckstein via swift-dev]

> On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev  
> wrote:
> 
> 
>> On Oct 23, 2016, at 16:13, Michael Gottesman > > wrote:
>> 
>> 
>>> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Dave pointed out to me this week that the build crashes if the stdlib tries 
>>> to use private/fileprivate. I tried it myself and lo and behold the linker 
>>> can't find the private symbols. He couldn't recall what about the build 
>>> caused that, though.
>>> 
>>> Can anyone recall why this is? How hard is it to fix?
>> 
>> I am not 100% sure, but if it happens only with the stdlib and has to do 
>> with access control, I wouldn't be surprised if it has to do with 
>> -sil-serialize-all and friends. But I may be correct. I think Jordan is the 
>> right person to answer this question.
> 
> I don't have it all paged in, but there are three main pieces I remember:
> 
> - Private and fileprivate decls can of course conflict across file 
> boundaries, which means it's possible we wouldn't be able to rebuild the 
> standard library from textual SIL. I think this is just a hypothetical 
> concern, since we don't actually have a reason to reuse names.
> 
> - Textual SIL again: the mangling for a private decl depends on its file. We 
> could fix this with an attribute that hardcodes manglings, or hardcodes a 
> private discriminator, or something. (We also have a bug today where multiple 
> 'private' decls in the same file will conflict in their mangling.)
> 
> - The standard library currently builds with -sil-serialize-all ("magic 
> performance mode") to make everything inlinable. This option currently mucks 
> with linkages at the SIL level in a fairly unprincipled way.

This was the case (long time ago). But now the SIL linkage is not affected by 
-sil-serialize-all, just the llvm linkage.
But maybe you are referring to another issue.

> This is probably the underlying cause of whatever linking issues you're 
> seeing, but even if it's not it would probably get in the way of trying to 
> fix things.
> 
> docs/AccessControlInStdlib.rst points to another, similar issue: 
> > Figure out how inlined 
> XREFs to private entities work. Our planned answer for this is that inlinable 
> things can't reference private entities, only internal ones (and even then 
> only those marked as "versioned"). That's a bit annoying, but does correspond 
> with the notion that a versioned entity is an ABI promise, and the file you 
> declare something in should never be part of the library's ABI. (There are 
> other answers that could work here, of course.)
> 
> Fortunately those last issues are something we need to fix anyway as part of 
> deciding which parts of the standard library should be resilient and which 
> parts are fragile, so maybe we'll be in a good enough place to start allowing 
> private decls again later this release.
> 
> Jordan
> 
> 
> 
> ___
> 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] copy-on-write proposal

[Erik Eckstein via swift-dev]

> On Oct 20, 2016, at 10:11 AM, Andrew Trick  wrote:
> 
> 
>> On Oct 20, 2016, at 8:41 AM, Erik Eckstein > > wrote:
>> 
>>> To clarify: I proposed an alternate approach in which the @sil_cow 
>>> reference is only mutable during the Array’s @inout scope—to be 
>>> automatically enforced by the compiler once @inout scopes are enforced. But 
>>> the text in question is not referring to that approach, so your comments 
>>> are on target.
>> 
>> After thinking about Joe’s suggestion (having the cow attribute on the class 
>> type and make a reference to that type move-only), I’m more inclined to go 
>> with the isUnique builtin. If such a reference can only be returned by 
>> isUnique, it is really guaranteed that only a uniquely referenced buffer can 
>> be mutated. With the inout approach, the programmer is not forced to make 
>> the uniqueness check before modifying the buffer.
> 
> 
> In my mind, relying on a move-only reference type is exactly what I was 
> advocating for, but relies on a language feature rather than a “special” 
> compiler verification.

Well, I think we are not blocked on this. We could just add a mandatory pass to 
check that there are no move-only violations. In the future a language feature 
might do this in a more elegant way in the type checker or whatever. But for 
now I believe we don’t need more than the attributes on the class type and the 
COW reference field.

> This all still needs to work with an ‘inout’ Array. The compiler will 
> effectively be doing the same verification that I was proposing but as a side 
> effect of move-only semantics (type system support makes it much easier). The 
> isUnique builtin would just be a mechanism to get the mutable type, and the 
> endUnique builtin is the mechanism to move the type back. As Dave pointed 
> out, we could provide additional mechanisms for mutation that don’t depend on 
> uniqueness. But the SIL optimizer doesn’t need to be explicitly taught about 
> any of those builtin mechanisms for correctness. More importantly, the user 
> is no longer responsible for some easy-to-violate, unverified property of the 
> data type as a whole.

I think we are more or less on the same page. All I’m saying is that the 
mutable reference can only be obtained by the isUnique/is_unique 
builtin/instruction (or by creating a new buffer).

> 
> -Andy

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

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

[Erik Eckstein via swift-dev]

> On Oct 20, 2016, at 8:51 AM, Dave Abrahams  wrote:
> 
> We might want to leave some room in the design for a shared atomic cache 
> reference to live in the buffer, FWIW. It would have to be mutable even when 
> the buffer was multiply-referenced 

Should be no problem with an attribute on that field. Like ‘mutable' in C++.
> 
> Sent from my moss-covered three-handled family gradunza
> 
> On Oct 20, 2016, at 8:41 AM, Erik Eckstein  <mailto:eeckst...@apple.com>> wrote:
> 
>> 
>>> On Oct 19, 2016, at 6:36 PM, Andrew Trick via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>>> 
>>>> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev 
>>>> mailto:swift-dev@swift.org>> wrote:
>>>> 
>>>> 
>>>> on Tue Oct 18 2016, Erik Eckstein >>> <http://swift-dev-at-swift.org/>> wrote:
>>>> 
>>>>>> On Oct 17, 2016, at 10:21 AM, Dave Abrahams >>>>> <mailto:dabrah...@apple.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> on Mon Oct 17 2016, Erik Eckstein >>>>> <http://eeckstein-at-apple.com/>> wrote:
>>>>>> 
>>>>> 
>>>>>>> On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev 
>>>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>>>> 
>>>>>>>> on Thu Oct 13 2016, Joe Groff >>>>>>> <http://swift-dev-at-swift.org/> <http://swift-dev-at-swift.org/ 
>>>>>>>> <http://swift-dev-at-swift.org/>>> wrote:
>>>>>>>> 
>>>>>>>>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
>>>>>>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>>>>>>> 
>>>>>>>>>> This is a proposal for representing copy-on-write buffers in
>>>>>>>>>> SIL. Actually it’s still a draft for a proposal. It also heavily
>>>>>>>>>> depends on how we move forward with SIL ownership.
>>>>>>>>>> 
>>>>>>>>>> If you have any comments, please let me know.
>>>>>>>>> 
>>>>>>>>> The SIL-level design seems sensible to me at a glance. At the language
>>>>>>>>> level, I think it would make more sense to treat this as an attribute
>>>>>>>>> on class types rather than on properties in structs using the class. I
>>>>>>>>> don't think many people reuse class definitions as both shared
>>>>>>>>> reference types and as value type payloads, 
>>>>>>>> 
>>>>>>>> Foundation does, or would if they could.
>>>>>>>> 
>>>>>>>>> but beyond that, I think that making it an attribute of classes would
>>>>>>>>> put us into a better position to leverage the borrow model to enforce
>>>>>>>>> the "mutable-only-when-unique" aspect of COW implementations. John
>>>>>>>>> alluded to this in the "SIL address types and borrowing" thread:
>>>>>>>>> 
>>>>>>>>>> I wonder if it would make more sense to make copy-on-write buffer
>>>>>>>>>> references a move-only type, so that as long as you were just
>>>>>>>>>> working with the raw reference (as opposed to the CoW aggregate,
>>>>>>>>>> which would remain copyable) it wouldn't get implicitly copied
>>>>>>>>>> anymore.  You could have mutable and immutable buffer reference
>>>>>>>>>> types, both move-only, and there could be a consuming checkUnique
>>>>>>>>>> operation on the immutable one that, I dunno, returned an Either of
>>>>>>>>>> the mutable and immutable versions.
>>>>>>>>>> 
>>>>>>>>>> For CoW aggregates, you'd need some @copied attribute on the field
>>>>>>>>>> to make sure that the CoW attribute was still copyable.  Within the
>>>>>>>>>> implementation of the type, though, you would be projecting out the
>>>>>>>>>> reference immediately, and thereafter you'd be certain that you were
>>>>>>>>

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

[Erik Eckstein via swift-dev]

> On Oct 19, 2016, at 6:36 PM, Andrew Trick via swift-dev  
> wrote:
> 
>> 
>> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> 
>> on Tue Oct 18 2016, Erik Eckstein > <http://swift-dev-at-swift.org/>> wrote:
>> 
>>>> On Oct 17, 2016, at 10:21 AM, Dave Abrahams >>> <mailto:dabrah...@apple.com>> wrote:
>>>> 
>>>> 
>>>> on Mon Oct 17 2016, Erik Eckstein >>> <http://eeckstein-at-apple.com/>> wrote:
>>>> 
>>> 
>>>>> On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev 
>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>> 
>>>>>> on Thu Oct 13 2016, Joe Groff >>>>> <http://swift-dev-at-swift.org/> <http://swift-dev-at-swift.org/ 
>>>>>> <http://swift-dev-at-swift.org/>>> wrote:
>>>>>> 
>>>>>>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
>>>>>>>> mailto:swift-dev@swift.org>> wrote:
>>>>>>>> 
>>>>>>>> This is a proposal for representing copy-on-write buffers in
>>>>>>>> SIL. Actually it’s still a draft for a proposal. It also heavily
>>>>>>>> depends on how we move forward with SIL ownership.
>>>>>>>> 
>>>>>>>> If you have any comments, please let me know.
>>>>>>> 
>>>>>>> The SIL-level design seems sensible to me at a glance. At the language
>>>>>>> level, I think it would make more sense to treat this as an attribute
>>>>>>> on class types rather than on properties in structs using the class. I
>>>>>>> don't think many people reuse class definitions as both shared
>>>>>>> reference types and as value type payloads, 
>>>>>> 
>>>>>> Foundation does, or would if they could.
>>>>>> 
>>>>>>> but beyond that, I think that making it an attribute of classes would
>>>>>>> put us into a better position to leverage the borrow model to enforce
>>>>>>> the "mutable-only-when-unique" aspect of COW implementations. John
>>>>>>> alluded to this in the "SIL address types and borrowing" thread:
>>>>>>> 
>>>>>>>> I wonder if it would make more sense to make copy-on-write buffer
>>>>>>>> references a move-only type, so that as long as you were just
>>>>>>>> working with the raw reference (as opposed to the CoW aggregate,
>>>>>>>> which would remain copyable) it wouldn't get implicitly copied
>>>>>>>> anymore.  You could have mutable and immutable buffer reference
>>>>>>>> types, both move-only, and there could be a consuming checkUnique
>>>>>>>> operation on the immutable one that, I dunno, returned an Either of
>>>>>>>> the mutable and immutable versions.
>>>>>>>> 
>>>>>>>> For CoW aggregates, you'd need some @copied attribute on the field
>>>>>>>> to make sure that the CoW attribute was still copyable.  Within the
>>>>>>>> implementation of the type, though, you would be projecting out the
>>>>>>>> reference immediately, and thereafter you'd be certain that you were
>>>>>>>> borrowing / moving it around as appropriate.
>>>>>>> 
>>>>>>> If 'copy-on-write' were a trait on classes, then we could distinguish
>>>>>>> unique and nonunique references to the class. A unique reference would
>>>>>>> act like a move-only type to prevent accidental loss of uniqueness. 
>>>>>> 
>>>>>> +1
>>>>>> 
>>>>>>> We can also allow a copy-on-write class to have "mutating" methods,
>>>>>>> and only allow mutation on unique references. It seems to me like,
>>>>>>> exploring this direction, we could also come up with a way for the
>>>>>>> high-level value-semantics operations on the struct to statically
>>>>>>> indicate which methods are known to leave the value's buffers in a
>>>>>>> unique state, or which return values that are uniquely owned,

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

[Erik Eckstein via swift-dev]

> On Oct 17, 2016, at 10:21 AM, Dave Abrahams  wrote:
> 
> 
> on Mon Oct 17 2016, Erik Eckstein  wrote:
> 
>> On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev 
>>  wrote:
>> 
>>> on Thu Oct 13 2016, Joe Groff >> <http://swift-dev-at-swift.org/>> wrote:
>>> 
>>>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
>>>>>  wrote:
>>>>> 
>>>>> This is a proposal for representing copy-on-write buffers in
>>>>> SIL. Actually it’s still a draft for a proposal. It also heavily
>>>>> depends on how we move forward with SIL ownership.
>>>>> 
>>>>> If you have any comments, please let me know.
>>>> 
>>>> The SIL-level design seems sensible to me at a glance. At the language
>>>> level, I think it would make more sense to treat this as an attribute
>>>> on class types rather than on properties in structs using the class. I
>>>> don't think many people reuse class definitions as both shared
>>>> reference types and as value type payloads, 
>>> 
>>> Foundation does, or would if they could.
>>> 
>>>> but beyond that, I think that making it an attribute of classes would
>>>> put us into a better position to leverage the borrow model to enforce
>>>> the "mutable-only-when-unique" aspect of COW implementations. John
>>>> alluded to this in the "SIL address types and borrowing" thread:
>>>> 
>>>>> I wonder if it would make more sense to make copy-on-write buffer
>>>>> references a move-only type, so that as long as you were just
>>>>> working with the raw reference (as opposed to the CoW aggregate,
>>>>> which would remain copyable) it wouldn't get implicitly copied
>>>>> anymore.  You could have mutable and immutable buffer reference
>>>>> types, both move-only, and there could be a consuming checkUnique
>>>>> operation on the immutable one that, I dunno, returned an Either of
>>>>> the mutable and immutable versions.
>>>>> 
>>>>> For CoW aggregates, you'd need some @copied attribute on the field
>>>>> to make sure that the CoW attribute was still copyable.  Within the
>>>>> implementation of the type, though, you would be projecting out the
>>>>> reference immediately, and thereafter you'd be certain that you were
>>>>> borrowing / moving it around as appropriate.
>>>> 
>>>> If 'copy-on-write' were a trait on classes, then we could distinguish
>>>> unique and nonunique references to the class. A unique reference would
>>>> act like a move-only type to prevent accidental loss of uniqueness. 
>>> 
>>> +1
>>> 
>>>> We can also allow a copy-on-write class to have "mutating" methods,
>>>> and only allow mutation on unique references. It seems to me like,
>>>> exploring this direction, we could also come up with a way for the
>>>> high-level value-semantics operations on the struct to statically
>>>> indicate which methods are known to leave the value's buffers in a
>>>> unique state, or which return values that are uniquely owned, which
>>>> would give the optimizer more ability to avoid uniqueness checks
>>>> across calls without relying on inlining and IPO.
>>> 
>>> That's pretty cool.  However, I think there's nothing to prevent any
>>> mutating method from storing a copy of self in a global, so I think we'd
>>> need some participation from the programmer (either an agreement not to
>>> do that, or an explicit claim of uniqueness on exit) in order to
>>> identify operations that create/preserve uniqueness.
>> 
>> If a mutating reference (like self in a mutating method) is move-only
>> then you would not be able to “copy” it to a global.
> 
> Yes, a reference to a move-only type would work for this purpose.
> 
> 
>>> On Oct 16, 2016, at 2:01 PM, Dave Abrahams via swift-dev 
>>>  wrote:
>>> 
>>> 
>>> on Tue Oct 11 2016, Erik Eckstein  wrote:
>>> 
>>>> This is a proposal for representing copy-on-write buffers in
>>>> SIL. Actually it’s still a draft for a proposal. It also heavily
>>>> depends on how we move forward with SIL ownership.
>>>> 
>>>> :orphan:
>>>> 
>>>> .. highlight:: sil
>>>> 

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

[Erik Eckstein via swift-dev]

On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev  
wrote:


> on Thu Oct 13 2016, Joe Groff  <http://swift-dev-at-swift.org/>> wrote:
> 
>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
>>>  wrote:
>>> 
>>> This is a proposal for representing copy-on-write buffers in
>>> SIL. Actually it’s still a draft for a proposal. It also heavily
>>> depends on how we move forward with SIL ownership.
>>> 
>>> If you have any comments, please let me know.
>> 
>> The SIL-level design seems sensible to me at a glance. At the language
>> level, I think it would make more sense to treat this as an attribute
>> on class types rather than on properties in structs using the class. I
>> don't think many people reuse class definitions as both shared
>> reference types and as value type payloads, 
> 
> Foundation does, or would if they could.
> 
>> but beyond that, I think that making it an attribute of classes would
>> put us into a better position to leverage the borrow model to enforce
>> the "mutable-only-when-unique" aspect of COW implementations. John
>> alluded to this in the "SIL address types and borrowing" thread:
>> 
>>> I wonder if it would make more sense to make copy-on-write buffer
>>> references a move-only type, so that as long as you were just
>>> working with the raw reference (as opposed to the CoW aggregate,
>>> which would remain copyable) it wouldn't get implicitly copied
>>> anymore.  You could have mutable and immutable buffer reference
>>> types, both move-only, and there could be a consuming checkUnique
>>> operation on the immutable one that, I dunno, returned an Either of
>>> the mutable and immutable versions.
>>> 
>>> For CoW aggregates, you'd need some @copied attribute on the field
>>> to make sure that the CoW attribute was still copyable.  Within the
>>> implementation of the type, though, you would be projecting out the
>>> reference immediately, and thereafter you'd be certain that you were
>>> borrowing / moving it around as appropriate.
>> 
>> If 'copy-on-write' were a trait on classes, then we could distinguish
>> unique and nonunique references to the class. A unique reference would
>> act like a move-only type to prevent accidental loss of uniqueness. 
> 
> +1
> 
>> We can also allow a copy-on-write class to have "mutating" methods,
>> and only allow mutation on unique references. It seems to me like,
>> exploring this direction, we could also come up with a way for the
>> high-level value-semantics operations on the struct to statically
>> indicate which methods are known to leave the value's buffers in a
>> unique state, or which return values that are uniquely owned, which
>> would give the optimizer more ability to avoid uniqueness checks
>> across calls without relying on inlining and IPO.
> 
> That's pretty cool.  However, I think there's nothing to prevent any
> mutating method from storing a copy of self in a global, so I think we'd
> need some participation from the programmer (either an agreement not to
> do that, or an explicit claim of uniqueness on exit) in order to
> identify operations that create/preserve uniqueness.

If a mutating reference (like self in a mutating method) is move-only then you 
would not be able to “copy” it to a global.

> 
> 
> On Oct 16, 2016, at 2:01 PM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> on Tue Oct 11 2016, Erik Eckstein  wrote:
> 
>> This is a proposal for representing copy-on-write buffers in
>> SIL. Actually it’s still a draft for a proposal. It also heavily
>> depends on how we move forward with SIL ownership.
>> 
>> :orphan:
>> 
>> .. highlight:: sil
>> 
>> ===
>> Copy-On-Write Representation in SIL
>> ===
>> 
>> .. contents::
>> 
>> Overview
>> 
>> 
>> This document proposes:
>> 
>> - An ownership attribute to define copy-on-write (COW) buffers in Swift data
>>  types.
>> 
>> - A representation of COW buffers in SIL so that optimizations can take 
>> benefit
>>  of it.
>> 
>> The basic idea is to enable the SIL optimizer to reason about COW data types
>> in the same way as a programmer can do.
>> This means: a COW buffer can only be modified by its owning SIL value, 
>> because
>> either it's uniquely referenced or the buffer is copied before modified.
>> 
>

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

[Erik Eckstein via swift-dev]

> On Oct 13, 2016, at 10:36 AM, Joe Groff  wrote:
> 
> 
>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
>>  wrote:
>> 
>> This is a proposal for representing copy-on-write buffers in SIL. Actually 
>> it’s still a draft for a proposal. It also heavily depends on how we move 
>> forward with SIL ownership.
>> 
>> If you have any comments, please let me know.
> 
> The SIL-level design seems sensible to me at a glance. At the language level, 
> I think it would make more sense to treat this as an attribute on class types 
> rather than on properties in structs using the class. I don't think many 
> people reuse class definitions as both shared reference types and as value 
> type payloads, but beyond that, I think that making it an attribute of 
> classes would put us into a better position to leverage the borrow model to 
> enforce the "mutable-only-when-unique" aspect of COW implementations.

I think this makes sense. Although we would need an attribute on the field as 
well (what John called the @copied attribute).

> John alluded to this in the "SIL address types and borrowing" thread:
> 
>> I wonder if it would make more sense to make copy-on-write buffer references 
>> a move-only type, so that as long as you were just working with the raw 
>> reference (as opposed to the CoW aggregate, which would remain copyable) it 
>> wouldn't get implicitly copied anymore.  You could have mutable and 
>> immutable buffer reference types, both move-only, and there could be a 
>> consuming checkUnique operation on the immutable one that, I dunno, returned 
>> an Either of the mutable and immutable versions.
>> 
>> For CoW aggregates, you'd need some @copied attribute on the field to make 
>> sure that the CoW attribute was still copyable.  Within the implementation 
>> of the type, though, you would be projecting out the reference immediately, 
>> and thereafter you'd be certain that you were borrowing / moving it around 
>> as appropriate.
> 
> If 'copy-on-write' were a trait on classes, then we could distinguish unique 
> and nonunique references to the class. A unique reference would act like a 
> move-only type to prevent accidental loss of uniqueness. We can also allow a 
> copy-on-write class to have "mutating" methods, and only allow mutation on 
> unique references.

The only way to get a unique reference would then be to use the 
isUnique-builtin - or to create a new buffer. This is good, because we could 
statically check that the programmer can only modify uniquely referenced 
buffers (although to get full memory safety we would probably have  to 
invalidate the original buffer reference between the is_unique - end_unique 
scope, e.g. by storing a null pointer into it).

Thinking about this in detail I believe we have to change how a COW is 
implemented. For example we could not write back the unique reference and use 
it afterwards:

if let uniqueRef = isUnique(&cow.buffer) {
} else {
  uniqueRef = Buffer()
  cow.buffer = uniqueRef // <- this would not work. It’s a copy of a unique 
buffer
}
uniqueRef.someData = ...

Instead this could be done like

if let uniqueRef = isUnique(&cow.buffer) {
} else {
  uniqueRef = Buffer()
}
uniqueRef.someData = ...
cow.buffer = uniqueRef // OK, end of lifetime of uniqueRef

It would mean that we write back the buffer even in the unique-case, But I 
think this is ok.

For the implementation we would need two different reference types in the AST 
(unique and nonunique), right? Could this be just a different StorageType?

> It seems to me like, exploring this direction, we could also come up with a 
> way for the high-level value-semantics operations on the struct to statically 
> indicate which methods are known to leave the value's buffers in a unique 
> state, or which return values that are uniquely owned, which would give the 
> optimizer more ability to avoid uniqueness checks across calls without 
> relying on inlining and IPO.
> 
> -Joe

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

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

[Erik Eckstein via swift-dev]

> On Oct 12, 2016, at 11:19 AM, Alexis  wrote:
> 
> I’m having trouble figuring something out: is all of this contingent on all 
> of the relevant operations being completely inlined into a single function at 
> the SIL level? Could failing to inline a standard library function lead to 
> performance cliffs? I understand this is generally true of inlining and 
> dead-code elimination; but I’m wondering how this affects the abstractions we 
> expose. Can we know that some things will “always” work, even if parts aren’t 
> inlined?

Yes, also these optimizations heavily rely on inlining. I would say that 
originally almost everything is inside a called function, just think of all the 
generated getters/setters. But usually this is not a problem because most of 
the relevant functions are quite small and always inlined anyway.


> 
>> On Oct 11, 2016, at 7:48 PM, Erik Eckstein via swift-dev 
>>  wrote:
>> 
>> This is a proposal for representing copy-on-write buffers in SIL. Actually 
>> it’s still a draft for a proposal. It also heavily depends on how we move 
>> forward with SIL ownership.
>> 
>> If you have any comments, please let me know.
>> 
>> Erik
>> 
>> 
>> ___
>> 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] copy-on-write proposal

[Erik Eckstein via swift-dev]

t;>// An _addr instruction with one load/store use doesn't really need its 
>> own scope.
>>%arrayref._storageref = struct_element_addr %arrayref, #Array._storage
>> 
>>// ARC optimization can promote this to a borrow, replacing 
>> strong_release with end_borrow.
>>%arrayref.cow_storage = load [copy] %arrayref._storageref : $*@sil_cow 
>> ArrayStorage
>>%arrayref._storage = cow_to_ref %arrayref.cow_storage : $@sil_cow 
>> ArrayStorage
>> 
>>// Write some data into the CoW buffer.
>>// (For simplicity, pretend ArrayStorage has a "someData" field).
>>// A single-use _addr instruction, so no scope.
>>%somedata_addr = ref_element_addr %arrayref._storage, #someData
>>// A store with an implicit [exclusive] scope.
>>store [assign] %x to %somedata_addr
>> 
>>strong_release %arrayref._storage : $*ArrayStorage
>> 
>>// End the isUnique argument's exclusive scope.
>>// The same verification is needed here, but the inner scope would be 
>> eliminated.
>>end_exclusive %arrayref : $*Array // End scope #0
>> 
>> In general this approach looks more "user-friendly" than the first 
>> alternative.
>> But it depends on implementing the general feature to insert the inout 
>> scoping
>> instructions.
>> Also, we still have to think through all the details of this approach.
>> 
>> Dependency between a buffer reference to the scope-begin
>> 
>> 
>> With both alternatives there is no explicit dependency from a buffer 
>> reference
>> to a scope-begin instruction::
>> 
>>%b_cow = load %baddr
>>%b = cow_to_ref %b_cow
>>%x = load %b // No dependency between this...
>>...
>>begin_exclusive %baddr   // ... and this instruction.
>>...
>> 
>> So in theory the optimizer is free to reschedule the instructions::
>> 
>>%b_cow = load %baddr
>>%b = cow_to_ref %b_cow
>>...
>>begin_exclusive %baddr
>>%x = load %b // Wrong! Buffer could be modified here
>>...
>> 
>> We still have to figure out how to cope with this.
>> 
>> - We could add an end-of-lifetime instruction for a COW buffer reference, 
>> which
>>  the optimizer may not move over a begin-of-scope instruction.
>> 
>> - Or we just define the implicit rule for the optimizer that any use of a COW
>>  reference may not be moved over a begin-of-scope instruction.
>> 
>> Preconditions
>> =
>> 
>> To benefit from COW optimizations in the stdlib Array, Set and Dictionary 
>> data
>> structures we first need eager bridging, meaning getting rid of the bridged
>> buffer. At least for Array this is implemented as low-level bit operations 
>> and
>> optimizations cannot reason about it (e.g. finding a reasonable RC-root for 
>> the
>> buffer reference).
>> 
>> Another thing is that we currently cannot use ``copy_on_write`` for Array
>> because of pinning. Array pins it’s buffer when passing an element address to
>> an inout parameter. This allows the array buffer to be modified even if its
>> reference count is > 1. With ``copy_on_write``, a programmer could break 
>> memory
>> safety when violating the inout rule. Example::
>> 
>>var arr = [MyClass()]  // a global array
>> 
>>foo(&arr[0])// Pins the buffer of arr during the call
>> 
>>func foo(_ x: inout MyClass) -> Int {
>>  let b = arr   // The ref-count of the buffer is not incremented, 
>> because it is pinned!
>>  let r = b[0]  // optimizer removes the retain of r because it 
>> thinks the following code cannot modify b
>>  arr.removeAll()   // does not copy the array buffer and thus 
>> de-allocates r
>>  return r.i// use-after-free!
>>}
> 
> From a quick (re-)reading, this proposal still makes sense to me. My largest 
> comment is that I would really like to have some way that the program will 
> assert if the constraints are violated. Otherwise it will be difficult to 
> debug when your invariants are broken. The state machine seems simple enough 
> that I think you could reuse the pinned buffer and (if necessary) 1 
> additional bit in the object header (or perhaps tagged pointer bits).

Yeah, we could do this. I think it would just be sufficient to write a null 
pointer into the cow reference on at the begin-scope and restore it at the 
end-scope. It’s the same thing as having runtime checks for not violating 
borrowing rules.

> 
> Michael
> 
>> 
>> 
>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev 
>>>  wrote:
>>> 
>>> This is a proposal for representing copy-on-write buffers in SIL. Actually 
>>> it’s still a draft for a proposal. It also heavily depends on how we move 
>>> forward with SIL ownership.
>>> If you have any comments, please let me know.
>>> 
>>> Erik
>>> 
>>> 
>>> ___
>>> 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] copy-on-write proposal

[Erik Eckstein via swift-dev]

This is a proposal for representing copy-on-write buffers in SIL. Actually it’s 
still a draft for a proposal. It also heavily depends on how we move forward 
with SIL ownership.


CopyOnWrite.rst
Description: Binary data

If you have any comments, please let me know.

Erik


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

Re: [swift-dev] Are there any Swift/LLVM optimizations I could be assigned to?

[Erik Eckstein via swift-dev]

Hi Eddie,

> On Sep 19, 2016, at 6:10 PM, Eddie Santos via swift-dev  
> wrote:
> 
> Hi all,
> 
> Are there any moderately do-able optimizations that can be done in the Swift 
> compiler that have not been done yet?
> 
> I am a masters student at the University of Alberta in Dr. J. Nelson Amaral's 
> compiler optimization course, and I am searching for a project that can be 
> reasonably completed in two months' time. Contributing to Swift's compiler 
> seems like a great choice!

Cool! Welcome!

> I am also open to making improvements to LLVM in general, though the point of 
> this project is to get my feet wet in static analysis -- I'm not an expert 
> yet.
> 
> I'm interested in anything character encodings, strings and unicode, but that 
> limits my options in terms of *compiler optimizations*. I can also look into 
> profile-guided optimizations in LLVM [Profile], but I wanna know who's got 
> dibs before I start off on my own.
> 

There are two things which I have in mind:

1) You could look at optimizing character literals. Try to compile the 
following code and you’ll see what I mean.

func foo() -> Character {
  return Character("x")
}

2) Vedant has started working on PGO for swift. When the basic infrastructure 
is in place you could work on using PGO data in various SIL optimizations.


Erik



> Your input is welcome.
> 
> [Profile]: http://llvm.org/OpenProjects.html#profileguided 
> 
> 
> Regards,
> Eddie
> --
> Eddie Antonio Santos
> M.Sc. Student and Teaching Assistant
> Department of Computing Science
> University of Alberta
> easan...@ualberta.ca 
> http://eddieantonio.ca/ 
> ___
> 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 15.10 (master) #7632

[Erik Eckstein via swift-dev]

The test itself is problematic: rdar://problem/28337667 


> On Sep 16, 2016, at 12:33 AM, Slava Pestov via swift-dev 
>  wrote:
> 
> This is a random one-off failure.
> 
> Also my PR for the swift-3.0-branch hit a set of segfaults in the Dictionary 
> tests, but this time in the iphone simulator tests:
> 
> https://ci.swift.org/job/swift-PR-osx/3639/consoleFull#-1473877083fca400bf-2f4a-462e-b517-e058d770b2d7
>  
> 
> 
> The only relevant patch common between the below run and the above PR is the 
> SILGen @pseudogeneric fix. I can’t imagine this is breaking anything through, 
> especially on Linux. Does anyone have any ideas?
> 
> Slava
> 
>> On Sep 16, 2016, at 12:06 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7632]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7632/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-15_10
>> Date of build:   Thu, 15 Sep 2016 23:54:20 -0700
>> Build duration:  12 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 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 1 test(s), Passed: 8321 test(s), Total: 8322 test(s)
>> Failed: Swift(linux-x86_64).stdlib.Dictionary.swift 
>> 
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 297 test(s), Total: 297 test(s)
>> 
>> Changes
>> 
>> Commit a006834a16d0781b8bffe723c29c7c97720cf694 by spestov:
>> Don't drop requirements from potential archetypes if they came from a
>> 
>> edit: include/swift/AST/ArchetypeBuilder.h
>> edit: lib/AST/ArchetypeBuilder.cpp
>> edit: test/IRGen/same_type_constraints.swift
>> 
>> Commit 6f074f7677908b41154fd2790c535856622c226e by spestov:
>> IRGen: Fix capture descriptor emission for @pseudogeneric functions
>> 
>> edit: test/Reflection/capture_descriptors.sil
>> edit: lib/IRGen/GenReflection.cpp
>> 
>> Commit b5decb6be4cd09c3002a87ba67ec998b4a8fea99 by spestov:
>> SILGen: Fix some issues with @pseudogeneric thunks
>> 
>> edit: test/SILGen/objc_blocks_bridging.swift
>> edit: lib/SILGen/SILGenBridging.cpp
>> edit: lib/SILGen/SILGenDecl.cpp
>> edit: lib/SILGen/SILGenPoly.cpp
>> edit: test/SILGen/objc_bridging_any.swift
>> edit: test/SILGen/objc_imported_generic.swift
>> 
>> Commit 90d6e8dce8fa7e36cc7c398d99f0ac121e13f316 by spestov:
>> Sema: Variadic parameters are always @escaping and cannot be
>> 
>> edit: lib/Sema/TypeCheckAttr.cpp
>> edit: include/swift/AST/DiagnosticsSema.def
>> edit: test/attr/attr_inout.swift
>> edit: lib/Sema/TypeCheckPattern.cpp
>> edit: lib/Sema/TypeCheckType.cpp
>> edit: test/decl/func/vararg.swift
>> edit: test/type/types.swift
>> edit: test/attr/attr_escaping.swift
>> edit: test/attr/attr_autoclosure.swift
>> edit: lib/Sema/TypeChecker.h
>> 
>> Commit a1eef126ba303c26b74ef38482e7e0f33ed211ed by spestov:
>> AST: Don't print "aka <>" for generic function types
>> 
>> edit: lib/AST/ASTDumper.cpp
>> edit: lib/AST/DiagnosticEngine.cpp
>> edit: test/attr/attr_specialize.swift
>> edit: test/expr/capture/generic_params.swift
>> edit: test/decl/protocol/conforms/fixit_stub.swift
>> edit: test/Constraints/override.swift
>> edit: lib/Sema/TypeCheckAttr.cpp
>> edit: lib/Sema/TypeCheckDecl.cpp
>> 
>> Commit 8c3d93503fcfa8abbad9be7cca519b913f13a0f0 by spestov:
>> SILGen: Only give bridging and re-abstraction thunks a generic signature
>> 
>> edit: test/SILGen/generic_closures.swift
>> edit: test/SILGen/property_abstraction.swift
>> edit: lib/SILGen/SILGenPoly.cpp
>> edit: lib/SILGen/SILGenBridging.cpp
>> edit: test/SILGen/objc_blocks_bridging.swift
>> edit: test/SILGen/generic_objc_block_bridge.swift
> 
> ___
> 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] Advice on adding PGO support

[Erik Eckstein via swift-dev]

Hi Vedant,

nice work!

> On Sep 6, 2016, at 12:36 PM, Vedant Kumar via swift-dev  
> wrote:
> 
> Hi swift-dev,
> 
> I've been working on some patches which add basic support for PGO to swift 
> [1].
> What I have so far is just a proof-of-concept. I'd like to get some feedback 
> on
> the approach I've taken.
> 
> I've added support for loading profile data, matching up execution counts to
> the right parts of the AST, and attaching those execution counts to 
> conditional
> branches. I added two fields to CondBranchInst (in SIL):
> 
>  /// The number of times the True branch was executed.
>  Optional TrueBBCount;
> 
>  /// The number of times the False branch was executed.
>  Optional FalseBBCount;
> 
> I fixed up the SILCloner and a few other sites where conditional branches are
> created to propagate the branch taken counts. I have a patch to propagate
> branch taken counts through the SILOptimizer, but I didn't include it in [1]
> because I don't know how to write tests for it.
> 
> In IRGen, I added some logic to scale execution counts and create llvm
> branch_weight metadata.
> 
> Some questions:
> 
>  1. Is it acceptable to make some SIL objects larger in order to store
> execution counts (e.g CondBranchInst)?

Yes, I don’t see a problem with that.
But for saving some space, you might want to store the counts as a plain 
uint64_t instead of an Optional and use a special value (e.g. ~0) for the 
none-case.


> If not, what's the best way to make
> this information visible to SILOptimizer and IRGen?
> 
>  2. Is it better to associate counts with SIL instructions, or with
> SILSuccessor?

I think storing the counts in SILSuccessor makes sense, because counts are 
needed for all kind of terminator instructions (like switch_enum), except for 
the unconditional br, but IMO we can live with wasting some bytes for this 
instructions.

Another thing to consider is that the count information should be 
printed/parsed/serialized when writing and reading SIL.

> 
>  3. Does anyone have tips on modifying swift/benchmark? I'd like to add a
> benchmark driver which generates profile data, and another driver which
> uses that data to turn on PGO.
> 
> thanks,
> vedant
> 
> [1] https://github.com/vedantk/swift/tree/profile_use
> ___
> 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] End of source-breaking changes for Swift 3

[Erik Eckstein via swift-dev]

> On Jul 27, 2016, at 2:01 PM, Roman Levenstein  wrote:
> 
> 
> SE-0130 - Replace repeating Character and UnicodeScalar forms of String.init 
> 
> 
> This one was implemented by me. It was committed yesterday. 
> And, BTW, it was not mentioned in the original list of proposals sent out by 
> Ted.
> 
> SE-0127 - Cleaning up stdlib Pointer and Buffer Routines 
> 
> I’ve implemented  the unsafeAddress(of:) part. It was committed yesterday.
> Erik and Bob were working on other parts of it. I don’t know for sure if all 
> sub-tasks are completed by now.

I think that all tasks of SE-0127 are completed. Bob merged all PR related to 
the other 3 parts yesterday.

> 
> -Roman
> 
>> On Jul 27, 2016, at 1:21 PM, Jordan Rose via swift-dev > > wrote:
>> 
>> Associating some proposals with their current implementers for the record…
>> 
>>> On Jul 27, 2016, at 12:38, Ted Kremenek via swift-dev >> > wrote:
>>> 
>>> Dear friends,
>>> 
>>> Today is July 27 — and the last planned day to take source-breaking changes 
>>> for Swift 3. It has been an incredible ride to this point, so let's take 
>>> stock of where we are. Here are the list of currently accepted — but not 
>>> yet (fully) implemented — evolution proposals (this is drawn from the 
>>> "accepted" but not marked "implemented" proposals from the swift-evolution 
>>>  repository):
>>> 
>>> SE-0025 - Scoped Access Level 
>>> This
>>>  one is nearly done (me).
>> 
>> 
>>> SE-0077 - Improved operator declarations 
>>> I
>>>  believe this is what John’s working on at the moment.
>> 
>> 
>>> SE-0081 - Move where clause to end of declaration 
>>> David
>>>  was looking at this, but I’m not sure if it’s done.
>> 
>>> SE-0088 - Modernize libdispatch for Swift 3 naming conventions 
>>> I
>>>  think we can call this done.
>> 
>>> SE-0099 - Restructuring Condition Clauses 
>>> This
>>>  is implemented; it’s just still marked as a warning rather than an error 
>>> to use ‘where’.
>> 
>>> SE-0103 - Make non-escaping closures the default 
>>> MichaelI
>>>  has been working on this.
>> 
>>> SE-0107 - UnsafeRawPointer API 
>>> Andy
>>>  has been working on this.
>> 
>> Jordan
>> ___
>> 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 - OS X (master) #5519

[Erik Eckstein via swift-dev]

Actually, what I reproduced is the other problem, which Michael already 
investigated

> On Jul 27, 2016, at 10:23 AM, Andrew Trick  wrote:
> 
> FYI: Swift CI just passed on this commit minutes before this crash (it was 
> automerged). Of course validation tests also pass for me locally on linux and 
> darwin.
> 
> -Andy
> 
>> On Jul 27, 2016, at 10:11 AM, Erik Eckstein > > wrote:
>> 
>> I just reproduced it locally. It's a swift compiler crash
>> 
>> 
>>> On Jul 27, 2016, at 9:59 AM, Andrew Trick via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Mishal,
>>> 
>>> Can you tell me what happened here?
>>> 
>>> -Andy
>>> 
 On Jul 27, 2016, at 9:57 AM, no-re...@swift.org 
  wrote:
 
 [FAILURE] oss-swift-incremental-RA-osx [#5519]
 
 Build URL: https://ci.swift.org/job/oss-swift-incremental-RA-osx/5519/ 
 
 Project:   oss-swift-incremental-RA-osx
 Date of build: Wed, 27 Jul 2016 09:49:36 -0700
 Build duration:7 min 53 sec
 
 Changes
 
 Commit 37c084bbebdcf6a46ae1e96369b95d4f4d9dac17 by atrick:
 Use UnsafeMutableRawPointer in HashedCollection
 
 edit: stdlib/public/core/HashedCollections.swift.gyb
 
 Commit c12552860019984c75c44dc0bd3617bce650b706 by atrick:
 Use a `UnsafeMutableRawPointer` in SwiftNativeNSArray.getObjects()
 
 edit: stdlib/public/core/SwiftNativeNSArray.swift
 
 Commit 2e0dd7b046486934abe024668ea7fdb34dde7ea8 by atrick:
 Use UnsafeRawPointer in withArrayOfCStrings.
 
 edit: stdlib/private/SwiftPrivate/SwiftPrivate.swift
 
 Commit 3e2372b6a381c09af040752746e47bba4f30f77a by atrick:
 Use UnsafeRawPointer in GLKit _indexHomogeneousValue.
 
 edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
 
 Commit 9886e4ef54e1b50f95d18a27908196658c0ff97c by atrick:
 Use UnsafeRawPointer in StringCore.
 
 edit: stdlib/public/core/StringBuffer.swift
 edit: stdlib/public/core/StringCore.swift
 edit: stdlib/public/core/StringUnicodeScalarView.swift
 edit: stdlib/public/core/String.swift
 edit: stdlib/public/core/StringUTF8.swift
 edit: stdlib/public/core/StringBridge.swift
 edit: test/1_stdlib/NewStringAppending.swift
 edit: test/1_stdlib/NewString.swift
 edit: stdlib/public/core/Character.swift
 edit: stdlib/public/core/Runtime.swift.gyb
 edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
 edit: stdlib/public/core/UnsafePointer.swift.gyb
>>> 
>>> ___
>>> 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 - OS X (master) #5519

[Erik Eckstein via swift-dev]

I just reproduced it locally. It's a swift compiler crash


> On Jul 27, 2016, at 9:59 AM, Andrew Trick via swift-dev  
> wrote:
> 
> Mishal,
> 
> Can you tell me what happened here?
> 
> -Andy
> 
>> On Jul 27, 2016, at 9:57 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#5519]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-RA-osx/5519/ 
>> 
>> Project: oss-swift-incremental-RA-osx
>> Date of build:   Wed, 27 Jul 2016 09:49:36 -0700
>> Build duration:  7 min 53 sec
>> 
>> Changes
>> 
>> Commit 37c084bbebdcf6a46ae1e96369b95d4f4d9dac17 by atrick:
>> Use UnsafeMutableRawPointer in HashedCollection
>> 
>> edit: stdlib/public/core/HashedCollections.swift.gyb
>> 
>> Commit c12552860019984c75c44dc0bd3617bce650b706 by atrick:
>> Use a `UnsafeMutableRawPointer` in SwiftNativeNSArray.getObjects()
>> 
>> edit: stdlib/public/core/SwiftNativeNSArray.swift
>> 
>> Commit 2e0dd7b046486934abe024668ea7fdb34dde7ea8 by atrick:
>> Use UnsafeRawPointer in withArrayOfCStrings.
>> 
>> edit: stdlib/private/SwiftPrivate/SwiftPrivate.swift
>> 
>> Commit 3e2372b6a381c09af040752746e47bba4f30f77a by atrick:
>> Use UnsafeRawPointer in GLKit _indexHomogeneousValue.
>> 
>> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
>> 
>> Commit 9886e4ef54e1b50f95d18a27908196658c0ff97c by atrick:
>> Use UnsafeRawPointer in StringCore.
>> 
>> edit: stdlib/public/core/StringBuffer.swift
>> edit: stdlib/public/core/StringCore.swift
>> edit: stdlib/public/core/StringUnicodeScalarView.swift
>> edit: stdlib/public/core/String.swift
>> edit: stdlib/public/core/StringUTF8.swift
>> edit: stdlib/public/core/StringBridge.swift
>> edit: test/1_stdlib/NewStringAppending.swift
>> edit: test/1_stdlib/NewString.swift
>> edit: stdlib/public/core/Character.swift
>> edit: stdlib/public/core/Runtime.swift.gyb
>> edit: stdlib/public/SDK/GLKit/GLKit.swift.gyb
>> edit: stdlib/public/core/UnsafePointer.swift.gyb
> 
> ___
> 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 15.10 (master) #5724

[Erik Eckstein via swift-dev]

Hi Mishal,

this might be a problem with incremental. I’d like to rebuild with a clean 
workspace. How can I clean the workspace?

Thanks,
Erik

> On Jun 16, 2016, at 5:13 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5724]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5724/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 16 Jun 2016 08:04:27 -0700
> Build duration:   8 min 33 sec
> Tests: 
> 
> Name: Swift
> Failed: 0 test(s), Passed: 8032 test(s), Total: 8032 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 292 test(s), Total: 292 test(s)
> 
> Changes
> 
> Commit d23551a25b0b2d5523478c2bf14a1eee87321459 by eeckstein:
> Don't generate code for transparent functions. They are mandatory
> 
> edit: lib/SILOptimizer/Mandatory/MandatoryInlining.cpp
> edit: test/IRGen/Inputs/multithread_module/main.swift
> edit: test/IRGen/sil_linkage.sil
> edit: lib/IRGen/Linking.h
> edit: lib/SILOptimizer/IPO/ExternalDefsToDecls.cpp
> edit: lib/IRGen/GenDecl.cpp
> edit: test/IRGen/multithread_module.swift

___
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 15.10 - Long Test (master) #70

[Erik Eckstein via swift-dev]

I could not reproduce it locally. But I noticed that foundation tests 
(foundation-linux-x86_64/TestFoundation/TestFoundation) were not recompiled in 
my local build, although the compiler changed. After I did a clean build all 
foundation tests passed.
Can we try a clean build on the bot?

Erik

> On Apr 29, 2016, at 5:00 PM, Daniel Dunbar  wrote:
> 
> --
> Test Suite 'All tests' started at 18:01:00.742
> Test Suite 'TestFoundation.xctest' started at 18:01:00.745
> Test Suite 'TestNSAffineTransform' started at 18:01:00.745
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10-long-test/swift/utils/build-script-impl:
>  line 2029:  4531 Segmentation fault  (core dumped) 
> LD_LIBRARY_PATH="${INSTALL_DESTDIR}"/"${INSTALL_PREFIX}"/lib/swift/:"${build_dir}/Foundation":"${XCTEST_BUILD_DIR}":${LD_LIBRARY_PATH}
>  "${build_dir}"/TestFoundation/TestFoundation
> --
> 
> Miscompile?
> 
>  - Daniel
> 
>> On Apr 29, 2016, at 4:58 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10-long-test [#70]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10-long-test/70/
>>  
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-15_10-long-test
>> Date of build:   Fri, 29 Apr 2016 16:39:13 -0700
>> Build duration:  19 min
>> Tests: 
>> 
>> Name: Swift
>> Failed: 0 test(s), Passed: 7877 test(s), Total: 7877 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 291 test(s), Total: 291 test(s)
>> 
>> Changes
>> 
>> Commit d40171cc31cf285913d045acda6fed036a01b2f3 by daniel_dunbar:
>> [CMake] Add support for selecting which bindings to build.
>> 
>> edit: CMakeLists.txt
>> 
>> Commit f1b5d2bf37ba6cd10bf7ab4b51877d68eae97cbc by ccross:
>> Fix NINJA_STATUS %e on dumb terminals
>> 
>> edit: src/build.cc 
>> Commit af4973d2251bf9bc616ceb5f9d9d64dd948ed569 by ccross:
>> Fix NINJA_STATUS %r on dumb terminals
>> 
>> edit: src/build.h
>> edit: src/build_test.cc
>> edit: src/build.cc 
>> Commit 16e600a6a1c09b9d06238c6a6f0eb4b958487b38 by eeckstein:
>> StackPromotion: fix a bug which could place the deallocation inside a
>> 
>> edit: test/SILOptimizer/stack_promotion.sil
>> edit: lib/SILOptimizer/Transforms/StackPromotion.cpp
>> 
>> Commit e3dc3e2fd2a06df2dda7d3cdc38210d2460e5764 by eeckstein:
>> SIL: remove an assert which checks that an operand value cannot be the
>> 
>> edit: include/swift/SIL/SILValue.h
>> 
>> Commit a5aa22565e62bdd447eb3441ac4a6cc3d7e5e21e by gribozavr:
>> stdlib: simplify LazyFilterCollection
>> 
>> edit: stdlib/public/core/Filter.swift.gyb
>> 
>> Commit 225b94ad0964bcf36577bac4b86772ab8343112a by jgroff:
>> Further refinement of `isBindableTo` for BoundGenericType conformances.
>> 
>> edit: lib/AST/Type.cpp
>> 
>> Commit 53bb3e8ea10f574510c8622f713f479fe9620e47 by eeckstein:
>> SimplifyCFG: improve switch_enum simplification.
>> 
>> edit: lib/SILOptimizer/Transforms/SimplifyCFG.cpp
>> edit: test/SILOptimizer/simplify_cfg.sil
>> 
>> Commit 66c4c87aae2b9a9c4d6a2a7eb36d0660397fca81 by modocache:
>> [Runtime] Android does not support constexpr
>> 
>> edit: include/swift/Runtime/MutexPThread.h
>> 
>> Commit d00dddbdabe448642524cbd684d7996ada04d384 by moiseev:
>> [stdlib][swift-3-indexing-model] fixing the ReversedCollection/lazy test
>> 
>> edit: 
>> stdlib/private/StdlibCollectionUnittest/CheckCollectionInstance.swift.gyb
>> edit: validation-test/stdlib/Lazy.swift.gyb
>> edit: stdlib/public/core/ClosedRange.swift
>> 
>> Commit ef4249bbc4bdbc9f37375e83c033f3599b9ed0e8 by gribozavr:
>> stdlib: set the right displayStyle in Optional's Mirror
>> 
>> edit: test/1_stdlib/Optional.swift
>> edit: test/IDE/complete_generic_optional.swift
>> edit: test/1_stdlib/Reflection.swift
>> edit: stdlib/public/core/Optional.swift
>> 
>> Commit 01d4fd5a2fa6bbda8f0c9de7fc63ca846b7f11db by egranata:
>> This code is supposed to fail when the read fails. Make it so
>> 
>> edit: lib/RemoteAST/RemoteAST.cpp
>> 
>> Commit d525b8320bbbe769a4ca4cc8f8028a43a70cdac9 by daniel_dunbar:
>> [build-script] Don't try to build llbuild Swift bindings as part of
>> 
>> edit: utils/build-script-impl
>> 
>> Commit 5594fc5339cef82f1999513412fb54b7ae92c881 by dfarler:
>> Collect builtins referenced by captures
>> 
>> edit: lib/IRGen/GenReflection.cpp
>> 
>> Commit 8f06358b5bbae0fde8676071c5206cf0c4607405 by spestov:
>> Reflection: Fix typos
>> 
>> edit: include/swift/Reflection/ReflectionContext.h
>> edit: stdlib/public/SwiftRemoteMirror/SwiftRemoteMirror.cpp
>> 
>> Commit 0273167b5d22f2c7efd17293c9b492c654e12206 by rjmccall:
>> Use the known type parameters to determine static offsets to stored
>> 
>> edit: test/RemoteAST/member_offsets.swift
>> edit: lib/IRGen/StructLayout.h
>> edit: test/IRGen/class.sil
>> edit: test/IRGen/fulfillment.sil
>> edit: lib/IRGen/GenType.h
>> edit: test/IRGen/gen

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

[Erik Eckstein via swift-dev]

(resending with less recipients)

I could not reproduce it locally. But I noticed that foundation tests 
(foundation-linux-x86_64/TestFoundation/TestFoundation) were not recompiled in 
my local build, although the compiler changed. After I did a clean build all 
foundation tests passed.
Can we try a clean build on the bot?

Erik

> On Apr 29, 2016, at 5:00 PM, Daniel Dunbar  > wrote:
> 
> --
> Test Suite 'All tests' started at 18:01:00.742
> Test Suite 'TestFoundation.xctest' started at 18:01:00.745
> Test Suite 'TestNSAffineTransform' started at 18:01:00.745
> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10-long-test/swift/utils/build-script-impl:
>  line 2029:  4531 Segmentation fault  (core dumped) 
> LD_LIBRARY_PATH="${INSTALL_DESTDIR}"/"${INSTALL_PREFIX}"/lib/swift/:"${build_dir}/Foundation":"${XCTEST_BUILD_DIR}":${LD_LIBRARY_PATH}
>  "${build_dir}"/TestFoundation/TestFoundation
> --
> 
> Miscompile?
> 
>  - Daniel
> 
>> On Apr 29, 2016, at 4:58 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10-long-test [#70]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10-long-test/70/
>>  
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-15_10-long-test
>> Date of build:   Fri, 29 Apr 2016 16:39:13 -0700
>> Build duration:  19 min
>> Tests: 
>> 
>> Name: Swift
>> Failed: 0 test(s), Passed: 7877 test(s), Total: 7877 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 291 test(s), Total: 291 test(s)
>> 
>> Changes
>> 
>> Commit d40171cc31cf285913d045acda6fed036a01b2f3 by daniel_dunbar:
>> [CMake] Add support for selecting which bindings to build.
>> 
>> edit: CMakeLists.txt
>> 
>> Commit f1b5d2bf37ba6cd10bf7ab4b51877d68eae97cbc by ccross:
>> Fix NINJA_STATUS %e on dumb terminals
>> 
>> edit: src/build.cc 
>> Commit af4973d2251bf9bc616ceb5f9d9d64dd948ed569 by ccross:
>> Fix NINJA_STATUS %r on dumb terminals
>> 
>> edit: src/build.h
>> edit: src/build_test.cc
>> edit: src/build.cc 
>> Commit 16e600a6a1c09b9d06238c6a6f0eb4b958487b38 by eeckstein:
>> StackPromotion: fix a bug which could place the deallocation inside a
>> 
>> edit: test/SILOptimizer/stack_promotion.sil
>> edit: lib/SILOptimizer/Transforms/StackPromotion.cpp
>> 
>> Commit e3dc3e2fd2a06df2dda7d3cdc38210d2460e5764 by eeckstein:
>> SIL: remove an assert which checks that an operand value cannot be the
>> 
>> edit: include/swift/SIL/SILValue.h
>> 
>> Commit a5aa22565e62bdd447eb3441ac4a6cc3d7e5e21e by gribozavr:
>> stdlib: simplify LazyFilterCollection
>> 
>> edit: stdlib/public/core/Filter.swift.gyb
>> 
>> Commit 225b94ad0964bcf36577bac4b86772ab8343112a by jgroff:
>> Further refinement of `isBindableTo` for BoundGenericType conformances.
>> 
>> edit: lib/AST/Type.cpp
>> 
>> Commit 53bb3e8ea10f574510c8622f713f479fe9620e47 by eeckstein:
>> SimplifyCFG: improve switch_enum simplification.
>> 
>> edit: lib/SILOptimizer/Transforms/SimplifyCFG.cpp
>> edit: test/SILOptimizer/simplify_cfg.sil
>> 
>> Commit 66c4c87aae2b9a9c4d6a2a7eb36d0660397fca81 by modocache:
>> [Runtime] Android does not support constexpr
>> 
>> edit: include/swift/Runtime/MutexPThread.h
>> 
>> Commit d00dddbdabe448642524cbd684d7996ada04d384 by moiseev:
>> [stdlib][swift-3-indexing-model] fixing the ReversedCollection/lazy test
>> 
>> edit: 
>> stdlib/private/StdlibCollectionUnittest/CheckCollectionInstance.swift.gyb
>> edit: validation-test/stdlib/Lazy.swift.gyb
>> edit: stdlib/public/core/ClosedRange.swift
>> 
>> Commit ef4249bbc4bdbc9f37375e83c033f3599b9ed0e8 by gribozavr:
>> stdlib: set the right displayStyle in Optional's Mirror
>> 
>> edit: test/1_stdlib/Optional.swift
>> edit: test/IDE/complete_generic_optional.swift
>> edit: test/1_stdlib/Reflection.swift
>> edit: stdlib/public/core/Optional.swift
>> 
>> Commit 01d4fd5a2fa6bbda8f0c9de7fc63ca846b7f11db by egranata:
>> This code is supposed to fail when the read fails. Make it so
>> 
>> edit: lib/RemoteAST/RemoteAST.cpp
>> 
>> Commit d525b8320bbbe769a4ca4cc8f8028a43a70cdac9 by daniel_dunbar:
>> [build-script] Don't try to build llbuild Swift bindings as part of
>> 
>> edit: utils/build-script-impl
>> 
>> Commit 5594fc5339cef82f1999513412fb54b7ae92c881 by dfarler:
>> Collect builtins referenced by captures
>> 
>> edit: lib/IRGen/GenReflection.cpp
>> 
>> Commit 8f06358b5bbae0fde8676071c5206cf0c4607405 by spestov:
>> Reflection: Fix typos
>> 
>> edit: include/swift/Reflection/ReflectionContext.h
>> edit: stdlib/public/SwiftRemoteMirror/SwiftRemoteMirror.cpp
>> 
>> Commit 0273167b5d22f2c7efd17293c9b492c654e12206 by rjmccall:
>> Use the known type parameters to determine static offsets to stored
>> 
>> edit: test/RemoteAST/member_offsets.swift
>> edit: lib/IRGen/StructLayout.h
>> edit: test/IRGen/class.sil
>> edit: test/IRGen/

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (master) #1059

[Erik Eckstein via swift-dev]

BTW, this is the radar: rdar://problem/25842757 

> On Apr 20, 2016, at 5:03 PM, Erik Eckstein via swift-dev 
>  wrote:
> 
> Xin and I working on a fix for the original problem.
> I think we should _disable_ this test on linux in the meantime and not 
> _xfail_ it.
> 
> Erik
> 
> 
>> On Apr 20, 2016, at 2:10 PM, Greg Parker via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> Nope, not your fault. This is a pre-existing problem. I'm not sure why the 
>> CI system thought that was a new issue.
>> 
>> 
>>> On Apr 20, 2016, at 2:08 PM, Michael Ilseman >> <mailto:milse...@apple.com>> wrote:
>>> 
>>> 
>>> Unexpected Passing Tests (1):
>>> Swift :: 1_stdlib/ArrayTraps.swift.gyb
>>> 
>>> I don’t think my changes could affect this test.
>>> 
>>>> On Apr 20, 2016, at 1:51 PM, no-re...@swift.org 
>>>> <mailto:no-re...@swift.org> wrote:
>>>> 
>>>> New issue found!
>>>> 
>>>> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1059]
>>>> 
>>>> Build URL: 
>>>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1059/ 
>>>> <https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1059/>
>>>> Project:   oss-swift-package-linux-ubuntu-15_10
>>>> Date of build: Wed, 20 Apr 2016 13:37:30 -0700
>>>> Build duration:14 min
>>>> Identified problems:
>>>> 
>>>> Unexpected pass: This build failed because a test marked as XFAIL 
>>>> unexpectedly passes. This could mean that the cause for the XFAIL is 
>>>> fixed, but it warrants investigation in any case.
>>>> Indication 1 
>>>> <https://ci.swift.org//job/oss-swift-package-linux-ubuntu-15_10/1059/consoleFull#801347659b011c97a-0462-424c-ac47-5640e6148d79>
>>>> Regression test failed: This build failed because a regression test in the 
>>>> test suite FAILed. Below is a list of all errors:
>>>> Indication 1 
>>>> <https://ci.swift.org//job/oss-swift-package-linux-ubuntu-15_10/1059/consoleFull#529225681fca400bf-2f4a-462e-b517-e058d770b2d7>
>>>> Changes
>>>> 
>>>> Commit 2e3662d1e7158f715d49428d1a2a2f23b03ca6fb by jordan_rose:
>>>> [stdlib] Tweak callback for pthread_create to avoid signature issues.
>>>> 
>>>> edit: 
>>>> stdlib/private/SwiftPrivatePthreadExtras/SwiftPrivatePthreadExtras.swift
>>>> 
>>>> Commit 093009b3ef9329e44d8d4b8b69e271ba5e3b80d2 by rjmccall:
>>>> Enhance the Remote / RemoteAST libraries with an error mechanism.
>>>> 
>>>> add: include/swift/Remote/Failure.h
>>>> add: include/swift/Remote/RemoteAddress.h
>>>> add: include/swift/Remote/FailureKinds.def
>>>> edit: include/swift/Remote/MemoryReader.h
>>>> edit: lib/RemoteAST/RemoteAST.cpp
>>>> edit: include/swift/RemoteAST/RemoteAST.h
>>>> 
>>>> Commit a8f9c8338bf7ba599b88a42e8c4e4df0f04ba1c0 by rjmccall:
>>>> Adding missing #include for Linux.
>>>> 
>>>> edit: include/swift/Remote/Failure.h
>>>> 
>>>> Commit 74933f775d6d94f96748dbee14fb6452461e45b1 by milseman:
>>>> [swift_newtype] Support for swift_wrapper/newtype attribute.
>>>> 
>>>> edit: include/clang/Basic/DiagnosticSemaKinds.td
>>>> edit: include/clang/Basic/AttrDocs.td
>>>> edit: include/clang/Basic/Attr.td
>>>> add: test/SemaObjC/attr-swift_newtype.c
>>>> edit: lib/Sema/SemaDeclAttr.cpp
>>>> edit: include/clang/Parse/Parser.h
>>>> edit: lib/Parse/ParseDecl.cpp
>>>> 
>>>> Commit fbe65cfab684a34b11208641bfdee9bbb9093b31 by milseman:
>>>> [swift_name] add warning group, to enable flags
>>>> 
>>>> edit: include/clang/Basic/DiagnosticSemaKinds.td
>>> 
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org <mailto: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-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (master) #1059

[Erik Eckstein via swift-dev]

Xin and I working on a fix for the original problem.
I think we should _disable_ this test on linux in the meantime and not _xfail_ 
it.

Erik


> On Apr 20, 2016, at 2:10 PM, Greg Parker via swift-dev  
> wrote:
> 
> Nope, not your fault. This is a pre-existing problem. I'm not sure why the CI 
> system thought that was a new issue.
> 
> 
>> On Apr 20, 2016, at 2:08 PM, Michael Ilseman > > wrote:
>> 
>> 
>> Unexpected Passing Tests (1):
>> Swift :: 1_stdlib/ArrayTraps.swift.gyb
>> 
>> I don’t think my changes could affect this test.
>> 
>>> On Apr 20, 2016, at 1:51 PM, no-re...@swift.org  
>>> wrote:
>>> 
>>> New issue found!
>>> 
>>> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1059]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1059/ 
>>> 
>>> Project:oss-swift-package-linux-ubuntu-15_10
>>> Date of build:  Wed, 20 Apr 2016 13:37:30 -0700
>>> Build duration: 14 min
>>> Identified problems:
>>> 
>>> Unexpected pass: This build failed because a test marked as XFAIL 
>>> unexpectedly passes. This could mean that the cause for the XFAIL is fixed, 
>>> but it warrants investigation in any case.
>>> Indication 1 
>>> 
>>> 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 2e3662d1e7158f715d49428d1a2a2f23b03ca6fb by jordan_rose:
>>> [stdlib] Tweak callback for pthread_create to avoid signature issues.
>>> 
>>> edit: 
>>> stdlib/private/SwiftPrivatePthreadExtras/SwiftPrivatePthreadExtras.swift
>>> 
>>> Commit 093009b3ef9329e44d8d4b8b69e271ba5e3b80d2 by rjmccall:
>>> Enhance the Remote / RemoteAST libraries with an error mechanism.
>>> 
>>> add: include/swift/Remote/Failure.h
>>> add: include/swift/Remote/RemoteAddress.h
>>> add: include/swift/Remote/FailureKinds.def
>>> edit: include/swift/Remote/MemoryReader.h
>>> edit: lib/RemoteAST/RemoteAST.cpp
>>> edit: include/swift/RemoteAST/RemoteAST.h
>>> 
>>> Commit a8f9c8338bf7ba599b88a42e8c4e4df0f04ba1c0 by rjmccall:
>>> Adding missing #include for Linux.
>>> 
>>> edit: include/swift/Remote/Failure.h
>>> 
>>> Commit 74933f775d6d94f96748dbee14fb6452461e45b1 by milseman:
>>> [swift_newtype] Support for swift_wrapper/newtype attribute.
>>> 
>>> edit: include/clang/Basic/DiagnosticSemaKinds.td
>>> edit: include/clang/Basic/AttrDocs.td
>>> edit: include/clang/Basic/Attr.td
>>> add: test/SemaObjC/attr-swift_newtype.c
>>> edit: lib/Sema/SemaDeclAttr.cpp
>>> edit: include/clang/Parse/Parser.h
>>> edit: lib/Parse/ParseDecl.cpp
>>> 
>>> Commit fbe65cfab684a34b11208641bfdee9bbb9093b31 by milseman:
>>> [swift_name] add warning group, to enable flags
>>> 
>>> edit: include/clang/Basic/DiagnosticSemaKinds.td
>> 
> 
> ___
> 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 - OS X (master) #3504

[Erik Eckstein via swift-dev]

This looks like there is some kind of non-determinism in the compilation.

> On Apr 19, 2016, at 8:14 PM, Greg Parker  wrote:
> 
> 
>> On Apr 19, 2016, at 12:45 PM, no-re...@swift.org wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#3504]
>> 
>> Tests: 
>> 
>> Name: Swift
>> Failed: 1 test(s), Passed: 7808 test(s), Total: 7809 test(s)
>>  • Failed: Swift.IRGen.module_hash.swift
>> 
> 
> This may be an older failure recently uncovered by changes to which tests get 
> run. Jordan, Erik, any guesses of changes that might have broken it?
> 
> Errors and recorded output below:
> 
> /Volumes/precious/cvs/swift-github/swift/test/IRGen/module_hash.swift:49:15: 
> error: expected string not found in input
> // CHECK-DAG: test.o: MD5=[[TEST4_MD5]]
>  ^
> :21:1: note: scanning from here
> thread 0: fetched 
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o
> ^
> :21:1: note: with variable "TEST4_MD5" equal to 
> "c32902f17598124702a017fac0e9b86d"
> thread 0: fetched 
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o
> ^
> :26:161: note: possible intended match here
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  MD5=e888cbc861bdeaaf786df90c4e5a40da
>   
>   
>^
> /Volumes/precious/cvs/swift-github/swift/test/IRGen/module_hash.swift:59:15: 
> error: expected string not found in input
> // CHECK-DAG: test.o: prev MD5=[[TEST4_MD5]] skipping
>  ^
> :30:1: note: scanning from here
> thread 0: fetched 
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o
> ^
> :30:1: note: with variable "TEST4_MD5" equal to 
> "c32902f17598124702a017fac0e9b86d"
> thread 0: fetched 
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o
> ^
> :35:161: note: possible intended match here
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  prev MD5=e888cbc861bdeaaf786df90c4e5a40da recompiling
>   
>   
>^
> 
> 
> 
> single-threaded initial
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  MD5=bbfcd715eee1f17799113c1826dfe124
> single-threaded same compilation
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  MD5=bbfcd715eee1f17799113c1826dfe124
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  prev MD5=bbfcd715eee1f17799113c1826dfe124 skipping
> single-threaded file changed
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  MD5=bd6e3d5aef7c83992235017dacea08a9
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  prev MD5=bbfcd715eee1f17799113c1826dfe124 recompiling
> single-threaded option changed
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  MD5=d67d06dfe12e11f7a2e4403461c646cd
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o:
>  prev MD5=bd6e3d5aef7c83992235017dacea08a9 recompiling
> multi-threaded initial
> thread 0: fetched 
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/test.o
> thread 1: fetched 
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInfoAssert+stdlib-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64/IRGen/Output/module_hash.swift.tmp/simple.o
> /Volumes/precious/cvs/swift-github/build/Ninja-RelWithDebInf

[swift-dev] changes in the inliner

[Erik Eckstein via swift-dev]

Hi,

I'd like to give some more information about the inliner changes I landed this 
week.

The goal was to restrict inlining to improve code size while not degrade 
performance (too much).
This was mainly achieved by improving the heuristic for the inlining decisions.
Some of our optimizations are still not as inlining-indepenent as we want them 
to be. Therefore I had to do some fine-tuning in the stdlib (e.g. with the new 
onFastPath builtin).
There are a few minor regressions, but overall performance looks ok.

The code size reductions are approximately:
stdlib: 3%
Benchmarks_O: 9%
Two larger applications: 15%, 20%

Erik

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

[swift-dev] inout and aliasing in the optimizer

[Erik Eckstein via swift-dev]

Hi,

I'm currently working on improving alias analysis in the optimizer and I run 
into following problem:

If alias analysis assumes that inout may not alias any other object, we may 
violate memory safety. Note that currently it's not always assumed, e.g. not in 
computeMemoryBehavior for apply insts.

As I understood, if the inout rule is violated, the program is not expected to 
behave as intended, but is still must be memory safe.
For this reason we had to insert explicit checks for inout violations in the 
stdlib, e.g. in ArrayBuffer: _precondition(_isNativeTypeChecked == 
wasNativeTypeChecked, "inout rules were violated: the array was overwritten")

Now with improved alias analysis and assuming inout-no-alias, the optimizer 
(specifically redundant load elimination) may eliminate these precondition 
checks in the stdlib.
And I can think of other cases, e.g.

sil @test(@inout %1 : $*C) {
  %2 = load %1
  apply inout_violating_function // replaces *%1 and releases the original *%1.
  %3 = load %1
  %4 = ref_element_addr %3
  %ptr = load %4
}

Redundant load elimination may optimize this to

sil @test(@inout %1 : $*C) {
  %2 = load %1
  apply inout_violating_function // replaces *%1 and releases the original *%1.
  %4 = ref_element_addr %2
  %ptr = load %4  // load pointer from freed memory
}

What I propose is to add a utility function in Types.h

inline bool isNotAliasedIndirectParameter(ParameterConvention conv,
  bool assumeInoutIsNotAliasing)

and optimizations, which use this function, must decide if it is safe to pass 
true in assumeInoutIsNotAliasing. This might be the case for high-level 
optimizations like COW array opts.
For alias analysis I think we have to go the conservative way.

John, Joe: any comments?

Thanks,
Erik


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