Re: [swift-dev] State of String: ABI & Performance

[Bob Wilson via swift-dev]

> On Jan 11, 2018, at 9:46 PM, Chris Lattner via swift-dev 
>  wrote:
> 
>>> 
>>> Finally, what tradeoffs do you see between a 1-word vs 2-word string?  Are 
>>> we really destined to have 2-words?  That’s still much better than the 3 
>>> words we have now, but for some workloads it is a significant bloat.
>> 
>> . Some 
>> arguments in favor of 2-word, presented roughly in order of impact:
> 
> Understood.  I don’t have a strong opinion on 1 vs 2 words, either are 
> dramatically better than 3 :-).  I’m glad you’re carefully evaluating the 
> tradeoff.
> 
>> 1. This allows the String type to accommodate llvm::StringRef-style usages. 
>> This is pretty broad usage: “mmap a file and treat its contents as a 
>> String”, “store all my contents in an llvm::BumpPtr which outlives uses”, 
>> un-owned slices, etc. One word String would greatly limit this to only 
>> whole-string nul-terminated cases.
> 
> Yes, StringRef style algorithms are a big deal, as I mentioned in my previous 
> email, but it is also unclear if this will really be a win when shoehorned 
> into String.  The benefit of StringRef is that it is a completely trivial 
> type (both in the SIL sense but also in the implementation sense) and all the 
> primitive ops get inlined.  Given the “all things to all people” design of 
> String, I’m very much afraid that trying to shoehorn this into the String 
> currency type will fail to provide significant wins and thus lead to having a 
> separate StringRef style type anyway.  Providing a StringRef style projection 
> type that is trivial (in the Swift sense) that knows in its static type that 
> it never owns memory seems like the best path.
> 
> By point of comparison, C++ has std::string (yes, sure, with lots of issues) 
> but they still introduced StringRef nee std::string_view instead of wedging 
> it in.
> 
>> 2. Two-word String fits more small strings. Exactly where along the 
>> diminishing-returns curve 7 vs 15 UTF-8 code units lie is dependent on the 
>> data set. One example is NSString, which (according to reasoning at 
>> https://www.mikeash.com/pyblog/friday-qa-2015-07-31-tagged-pointer-strings.html
>>  
>> )
>>  considered it important enough to have 6- and 5- bit reduced ASCII 
>> character sets to squeeze up to 11-length strings in a word. 15 code unit 
>> small strings would be a super-set of tagged NSStrings, meaning we could 
>> bridge them eagerly in-line, while 7 code unit small strings would be a 
>> subset (and also a strong argument against eagerly bridging them). 
> 
> Agreed, this is a big deal.
> 
>> If you have access to any interesting data sets and can report back some 
>> statistics, that would be immensely helpful!
> 
> Sadly, I don’t. I’m only an opinionated hobbyist in this domain, one who has 
> coded a lot of string processing over the years and understands at least some 
> of the tradeoffs.
> 
>> 3. More bits available to reserve for future-proofing, etc., though many of 
>> these could be stored in the header.
>> 
>> 4. The second word can cache useful information from large strings. 
>> `endIndex` is a very frequently requested computed property and it could be 
>> stored directly in-line rather than loaded from memory (though perhaps a 
>> load happens anyways in a subsequent read of the string). Alternatively, we 
>> could store the grapheme count or some other piece of information that we’d 
>> otherwise have to recompute. More experimentation needed here.
> 
> This seems weakly motivated: large strings can store end index in the heap 
> allocation.
> 
>> 5. (vague and hand-wavy) Two-words fits into a nice groove that 3-words 
>> doesn’t: 2 words is a rule-of-thumb size for very small buffers. It’s a 
>> common heap alignment, stack alignment, vector-width, double-word-load 
>> width, etc.. 1-word Strings may be under-utilizing available resources, that 
>> is the second word will often be there for use anyways. The main case where 
>> this is not true and 1-word shines is aggregates of String.
> 
> What is the expected existential inline buffer size going to wind up being?  
> We sized it to 3 words specifically to fit string and array.  It would be 
> great to shrink that to 2 or 1 words.
> 

We are planning to reevaluate the size of the inline buffer based on 
experimental performance data, but we can’t do that in a useful way until the 
size of String has been settled.___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] preliminary Swift 5 branch

[Bob Wilson via swift-dev]

Yesterday the LLVM project created its release branch for version 6.0, and we 
plan to align with this branch for Swift 5.0. The swift-llvm, swift-clang, and 
swift-compiler-rt repos on GitHub have been updated with new branches named 
"swift-5.0-branch" that track the LLVM 6.0 branches.

On Monday (Jan. 8), we plan to create a preliminary swift-5.0-branch for Swift 
as well. This will allow us to get started setting up infrastructure to support 
the Swift 5 release. There will be additional information about the Swift 5 
release and branching in the future. For now, you can safely ignore this branch.

Note that because the LLVM 6.0 release is just getting started, we’re going to 
hold off switching over to use it for a little while. The “stable” branches for 
the swift-llvm, swift-clang, and swift-compiler-rt repos will continue to merge 
from swift-4.1-branch for a while longer.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Correspondence between swift-clang and Apple's Clang end user releases

[Bob Wilson via swift-dev]

> On Aug 7, 2017, at 1:55 PM, John McCall via swift-dev  
> wrote:
> 
> 
>> On Aug 7, 2017, at 3:47 PM, Oleksii Vilchanskyi via swift-dev 
>>  wrote:
>> Hello,
>> 
>> I would like to know when a feature
>> (https://github.com/apple/swift-clang/commit/14bfc9e99e6e6903b09480a22c153032be77ae4e)
>> was introduced in a binary version of Clang shipped by Apple.
>> 
>> I tried the latest source code version from
>> https://opensource.apple.com, which is clang-800.0.42.1, but the feature
>> is not there.
> 
> I believe that what gets uploaded to that site is the clang that is used to 
> build the latest
> macOS release.  So it doesn't get uploads until macOS is actually released, 
> and the upload
> is of a slightly different clang anyway from the Xcode release — typically 
> it's a earlier tag of
> the same release branch.

Minor correction: it used to be that way a while back, but more recently, the 
compiler sources on opensource.apple.com have matched the Xcode releases. For 
some reason, that page has lagged behind and the latest release posted is from 
Xcode 8.2.1.

> 
>> Then I found a public repository, swift-clang. However, even though I
>> see that the commit is on 4.0 branch, I have no idea how to tell the
>> precise version when the commit was cherry-picked onto the release which
>> gets shipped to the end user (which I assume doesn't happen in this repo).
> 
> Apple believes strongly in the LLVM/Clang/Swift open-source process.  While 
> the
> ultimate, canonical Xcode release branches (i.e. clang-NNN) are indeed held in
> Apple-internal repositories, those branches are continually and automatically 
> merged
> from the open-source release branches in the github repositories (i.e. 
> swift-X.Y-branch).
> When we want to ensure that an open-source LLVM or Clang commit ends up in an 
> Xcode
> release, we don't cherry-pick it directly into our internal release branches, 
> we cherry-pick it
> into the github repositories and let it get auto-merged.  There are just so 
> many advantages
> to doing it this way that, frankly, we would do it even if we were actively 
> hostile to open-source. :)
> So the github release branches should always be a reliable point of truth for 
> whether an
> LLVM/clang commit will be present in the release.
> 
> The clang binary in a toolchain is built from the same source as the clang 
> components of the
> swiftc binary in that toolchain.
> 
>> I am also feel a bit frustrated due to the lack of correspondence with
>> usual Clang, which is currently at 4.0.1 and has browsable tags
>> corresponding to releases at https://llvm.org/svn/llvm-project/cfe/tags/.
> 
> The swift-4.0-branch is actually ultimately based on the LLVM's project 4.0 
> branch, although
> the numbering is just a coincidence.  This is something we've done for (I 
> think) the last two
> releases and plan to continue doing going forward.  Since the Swift branch is 
> usually targeted for
> a significantly later release and does require a substantial amount of 
> specific Clang support, we
> do cherry-pick a fair amount into our release that LLVM does not cherry-pick 
> into their release.
> 
> John.
> ___
> 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: OSS - Swift Package - Ubuntu 16.10 (master) #1419

[Bob Wilson via swift-dev]

Unfortunately that wasn’t good enough. Without lldb building, there was a test 
failing on Linux. I tried disabling that test 
(https://github.com/apple/swift/pull/11345 
) but other things still failed. We 
could completely skip PR testing for Linux but that would be a pretty drastic 
step.

Jim, any progress on getting lldb to work again?

> On Aug 3, 2017, at 7:54 PM, Xi Ge  wrote:
> 
> Thank you, Bob!
> 
>> On Aug 3, 2017, at 7:22 PM, Bob Wilson > > wrote:
>> 
>> We’ll temporarily remove lldb from the PR testing.
>> 
>>> On Aug 3, 2017, at 7:04 PM, Xi Ge >> > wrote:
>>> 
>>> Do we a radar to keep track of this? the build error seems to be blocking 
>>> our PR testing.
>>> 
>>> Xi
 On Aug 3, 2017, at 4:11 PM, Mishal Shah via swift-dev >>> > wrote:
 
 Hi,
 
 /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/lldb/source/Commands/CommandObjectArgs.cpp:226:75:
  error: 'Index' is a private member of 
 'llvm::detail::result_pair >'
 result.GetOutputStream().Printf("%" PRIu64 " (%s): ", 
 (uint64_t)entry.Index,
   ^
 /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/llvm/include/llvm/ADT/STLExtras.h:1030:15:
  note: declared private here
   std::size_t Index;
   ^
 /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/lldb/source/Commands/CommandObjectArgs.cpp:227:43:
  error: no member named 'Value' in 
 'llvm::detail::result_pair >'
 entry.Value.c_str());
 ~ ^
 /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/lldb/source/Commands/CommandObjectArgs.cpp:228:38:
  error: 'Index' is a private member of 
 'llvm::detail::result_pair >'
 
 value_list.GetValueAtIndex(entry.Index)->Dump(&result.GetOutputStream());
  ^
 /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/llvm/include/llvm/ADT/STLExtras.h:1030:15:
  note: declared private here
   std::size_t Index;
   ^
 3 errors generated.
 
>>> 
>> 
> 

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

[Bob Wilson via swift-dev]

We’ll temporarily remove lldb from the PR testing.

> On Aug 3, 2017, at 7:04 PM, Xi Ge  wrote:
> 
> Do we a radar to keep track of this? the build error seems to be blocking our 
> PR testing.
> 
> Xi
>> On Aug 3, 2017, at 4:11 PM, Mishal Shah via swift-dev > > wrote:
>> 
>> Hi,
>> 
>> /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/lldb/source/Commands/CommandObjectArgs.cpp:226:75:
>>  error: 'Index' is a private member of 
>> 'llvm::detail::result_pair >'
>> result.GetOutputStream().Printf("%" PRIu64 " (%s): ", 
>> (uint64_t)entry.Index,
>>   ^
>> /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/llvm/include/llvm/ADT/STLExtras.h:1030:15:
>>  note: declared private here
>>   std::size_t Index;
>>   ^
>> /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/lldb/source/Commands/CommandObjectArgs.cpp:227:43:
>>  error: no member named 'Value' in 
>> 'llvm::detail::result_pair >'
>> entry.Value.c_str());
>> ~ ^
>> /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/lldb/source/Commands/CommandObjectArgs.cpp:228:38:
>>  error: 'Index' is a private member of 
>> 'llvm::detail::result_pair >'
>> value_list.GetValueAtIndex(entry.Index)->Dump(&result.GetOutputStream());
>>  ^
>> /home/buildnode/disk1/workspace/oss-swift-package-linux-ubuntu-16_10/llvm/include/llvm/ADT/STLExtras.h:1030:15:
>>  note: declared private here
>>   std::size_t Index;
>>   ^
>> 3 errors generated.
>> 
> 

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

Re: [swift-dev] Updating stable branch to swift-4.1-branch: scheduled for Thursday, Aug. 3

[Bob Wilson via swift-dev]

This is done now. It might take a little while for the bots to catch up.

Reminder: You should completely remove your entire build directory, including 
LLVM, when you pick up these changes. Incremental builds will almost certainly 
not go well.

> On Aug 3, 2017, at 9:22 AM, Bob Wilson via swift-dev  
> wrote:
> 
> Reminder: This is still on track to happen today.
> 
>> On Jul 31, 2017, at 5:34 PM, Bob Wilson via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> We now have a swift-4.1-branch of Clang/LLVM, and it is time to update our 
>> “stable” branch to use that. This transition will merge in changes to the 
>> Swift master branch from the master-next branch that we maintain to work 
>> with upstream LLVM.
>> 
>> We are planning to make the change this Thursday, Aug. 3, around 2:00 pm 
>> (PDT).
>> 
>> When this happens, you will need to do a clean build of Clang/LLVM along 
>> with Swift. Do not just build the “clean” target — you should completely 
>> remove your entire build directory and then rebuild from scratch. There may 
>> be some instability after this transition as uncommon problems with the new 
>> version of LLVM are discovered.
>> 
>> I’ll send a reminder on Thursday. Let me know if you have any questions or 
>> concerns.
>> ___
>> 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] Updating stable branch to swift-4.1-branch: scheduled for Thursday, Aug. 3

[Bob Wilson via swift-dev]

Reminder: This is still on track to happen today.

> On Jul 31, 2017, at 5:34 PM, Bob Wilson via swift-dev  
> wrote:
> 
> We now have a swift-4.1-branch of Clang/LLVM, and it is time to update our 
> “stable” branch to use that. This transition will merge in changes to the 
> Swift master branch from the master-next branch that we maintain to work with 
> upstream LLVM.
> 
> We are planning to make the change this Thursday, Aug. 3, around 2:00 pm 
> (PDT).
> 
> When this happens, you will need to do a clean build of Clang/LLVM along with 
> Swift. Do not just build the “clean” target — you should completely remove 
> your entire build directory and then rebuild from scratch. There may be some 
> instability after this transition as uncommon problems with the new version 
> of LLVM are discovered.
> 
> I’ll send a reminder on Thursday. Let me know if you have any questions or 
> concerns.
> ___
> 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] Updating stable branch to swift-4.1-branch: scheduled for Thursday, Aug. 3

[Bob Wilson via swift-dev]

We now have a swift-4.1-branch of Clang/LLVM, and it is time to update our 
“stable” branch to use that. This transition will merge in changes to the Swift 
master branch from the master-next branch that we maintain to work with 
upstream LLVM.

We are planning to make the change this Thursday, Aug. 3, around 2:00 pm (PDT).

When this happens, you will need to do a clean build of Clang/LLVM along with 
Swift. Do not just build the “clean” target — you should completely remove your 
entire build directory and then rebuild from scratch. There may be some 
instability after this transition as uncommon problems with the new version of 
LLVM are discovered.

I’ll send a reminder on Thursday. Let me know if you have any questions or 
concerns.___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] State of Semantic ARC?

[Bob Wilson via swift-dev]

> On Jul 8, 2017, at 10:36 AM, Johannes Weiß via swift-dev 
>  wrote:
> 
> Hi swift-dev,
> 
> I haven't heard anything about semantic ARC and couldn't really find much 
> documentation besides 
> https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html . 
> So I wanted to ask how much of it is implemented and what the plan for Swift 
> 4/5 regarding Semantic ARC is.
> 
> — Johannes

During the course of Swift 4 development, we realized that there were other 
changes that we wanted to make for SIL to preserve semantic information, 
besides the changes initially proposed for improving ARC optimizations. In 
particular, there were some important changes for memory ownership and the 
handling of opaque “address-only” values. Thus, we renamed the project to 
“Semantic SIL” instead of “Semantic ARC”. But that’s just the project name….

Michael may want to chime in here with more details, but the basic status is 
that the planned changes for high-level memory operations and ownership are 
done and included in Swift 4. There is a verifier that detects violations of 
the model and has already caught a number of serious bugs. However, the new 
form of SIL is transformed back to the old form early in the SIL optimizer 
pipeline (see the sil-ownership-model-eliminator pass). We will be gradually 
updating more of the optimizer to work with the new form of SIL, and moving the 
sil-ownership-model-eliminator pass later in the pipeline. Michael is currently 
working to get all the mandatory passes updated. These changes will not be in 
Swift 4. Revising the ARC optimizer to take advantage of the new information 
will be one of the later steps and it is unclear when that work will be done — 
it may end up being split into some incremental steps.

The other big part of Semantic SIL is changing to represent opaque 
“address-only” values as SSA values in SIL. Much of the groundwork for that is 
done (e.g., the address-lowering SIL pass) but it is disabled for Swift 4. 
We’re hoping to resume work on this soon.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] swift.org nightlies are old

[Bob Wilson via swift-dev]

Update: we’re still working on this. We got some LLDB test failures resolved 
yesterday and are now looking at a SwiftPM failure. Hopefully that will be the 
last one….

> On May 9, 2017, at 1:19 AM, Karl Wagner  wrote:
> 
> Great, thanks!
> 
> 
>> On May 8, 2017 at 6:55 am, mailto:bob.wil...@apple.com>> wrote:
>> 
>> There was a problem with some test failures blocking the build. We should at 
>> least be able to xfail those tests to get things unblocked tomorrow.
>> 
>> 
>> 
>> > On May 7, 2017, at 8:49 PM, Karl Wagner via swift-dev 
>> >  wrote:
>> 
>> >  
>> 
>> > It looks like the nightlies on swift.org haven’t been uploading properly 
>> > for some time now. The latest toolchain from master is dated April 26th.
>> 
>> >  
>> 
>> > Could somebody look in to it?
>> 
>> >  
>> 
>> > Thanks
>> 
>> >  
>> 
>> > - Karl
>> 
>> > ___
>> 
>> > 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.org nightlies are old

[Bob Wilson via swift-dev]

There was a problem with some test failures blocking the build. We should at 
least be able to xfail those tests to get things unblocked tomorrow.

> On May 7, 2017, at 8:49 PM, Karl Wagner via swift-dev  
> wrote:
> 
> It looks like the nightlies on swift.org haven’t been uploading properly for 
> some time now. The latest toolchain from master is dated April 26th.
> 
> Could somebody look in to it?
> 
> Thanks
> 
> - Karl
> ___
> 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] Renaming SILSuccessor -> SILCFGEdge

[Bob Wilson via swift-dev]

> On Apr 26, 2017, at 6:43 PM, John McCall via swift-dev  
> wrote:
> 
>> On Apr 26, 2017, at 6:11 PM, Michael Gottesman  wrote:
>>> On Apr 26, 2017, at 1:44 PM, John McCall  wrote:
>>> 
 On Apr 26, 2017, at 4:24 PM, Michael Gottesman via swift-dev 
  wrote:
 Hey everyone.
 
 I am currently doing some small fixes to SILSuccessor (adding some 
 comments and fixing some issues exposed by LLVM upstream). As I read the 
 code it became pretty apparent that the name is a misnomer... SILSuccessor 
 is not just representing a successor, rather it is representing a whole 
 CFG edge. This can be seen in how SILSuccessor is used to iterate over the 
 predecessors of the block.
 
 With that in mind, I would like to rename SILSuccessor to SILCFGEdge. It 
 will make it much clearer without knowing any context what this data 
 structure is used for.
 
 Any objections, disagreements, flames, etc?
>>> 
>>> It seems a little unnecessary to me.  The successor relationship is an 
>>> edge, and all the edges of the local CFG are successor relationships.  I 
>>> guess it looks a little funny that the edges into a block are represented 
>>> by "successors", but I think when you think about it it makes sense.
>> 
>> IMO this is more of an issue than something "looking funny". Using code 
>> named "successor" to look up the "predecessors" of a block is misleading and 
>> results in unnecessary cognitive overhead for the reader who has to "think 
>> about it" for it to make sense.
> 
> Uh, sure, but this is also not something most people have to deal with a ton, 
> and it's a learn-once-and-remember sort of thing.
> 
>>> "SILCFGEdge" is also not a very attractive name because of the two 
>>> abbreviations.  If you had a nice alternative to "CFGEdge" that was less 
>>> biased to the beginning/end (like Successor/Predecessor are), I probably 
>>> wouldn't object.
>> 
>> Ok. Maybe SILControlFlowEdge?
> 
> A bit elaborate, but it could work.  Honestly, this is not a type I have to 
> write out much.

How about just SILEdge?

(Honestly I’d prefer to keep it as SILSuccessor and avoid the churn from this, 
but if it is important to you, I won’t object to changing it.)___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Renaming SILSuccessor -> SILCFGEdge

[Bob Wilson via swift-dev]

> On Apr 26, 2017, at 3:11 PM, Michael Gottesman via swift-dev 
>  wrote:
> 
> 
>> On Apr 26, 2017, at 1:44 PM, John McCall  wrote:
>> 
>>> On Apr 26, 2017, at 4:24 PM, Michael Gottesman via swift-dev 
>>>  wrote:
>>> Hey everyone.
>>> 
>>> I am currently doing some small fixes to SILSuccessor (adding some comments 
>>> and fixing some issues exposed by LLVM upstream). As I read the code it 
>>> became pretty apparent that the name is a misnomer... SILSuccessor is not 
>>> just representing a successor, rather it is representing a whole CFG edge. 
>>> This can be seen in how SILSuccessor is used to iterate over the 
>>> predecessors of the block.
>>> 
>>> With that in mind, I would like to rename SILSuccessor to SILCFGEdge. It 
>>> will make it much clearer without knowing any context what this data 
>>> structure is used for.
>>> 
>>> Any objections, disagreements, flames, etc?
>> 
>> It seems a little unnecessary to me.  The successor relationship is an edge, 
>> and all the edges of the local CFG are successor relationships.  I guess it 
>> looks a little funny that the edges into a block are represented by 
>> "successors", but I think when you think about it it makes sense.
> 
> IMO this is more of an issue than something "looking funny". Using code named 
> "successor" to look up the "predecessors" of a block is misleading and 
> results in unnecessary cognitive overhead for the reader who has to "think 
> about it" for it to make sense.
> 
>> 
>> "SILCFGEdge" is also not a very attractive name because of the two 
>> abbreviations.  If you had a nice alternative to "CFGEdge" that was less 
>> biased to the beginning/end (like Successor/Predecessor are), I probably 
>> wouldn't object.
> 
> Ok. Maybe SILControlFlowEdge?

I can see your point here, but a big renaming change like this is disruptive. 
With all the other things we’re trying to get done now, is this really the 
right time to pay the cost of that?
___
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 - Long Test (master) #2126

[Bob Wilson via swift-dev]

Wrong group. Sorry, you’ll have to live without these awesome features for now.

> On Apr 14, 2017, at 9:49 PM, Bob Wilson via swift-dev  
> wrote:
> 
> The hope is that the “SkyNet” project that Marc Shifer’s team is developing 
> will be able to help with things like that. The “emoji hashes” in our new 
> Jenkins 2 bots are the first step in that direction….
> 
>> On Apr 14, 2017, at 9:08 PM, Andrew Trick > <mailto:atr...@apple.com>> wrote:
>> 
>> > runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED
>> 
>> This is unrelated to my commit and recovered on the next build. Is it 
>> spurious? Can CI be taught to recognize known spurious asserts?
>> 
>> -Andy
>> 
>> 
>>> On Apr 14, 2017, at 7:51 PM, no-re...@swift.org <mailto:no-re...@swift.org> 
>>> wrote:
>>> 
>>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#2126]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/2126/
>>>  
>>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/2126/>
>>> Project:oss-swift-incremental-RA-linux-ubuntu-14_04-long-test
>>> Date of build:  Fri, 14 Apr 2017 19:18:26 -0700
>>> Build duration: 33 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 
>>> <https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/2126/consoleFull#-1960388827fca400bf-2f4a-462e-b517-e058d770b2d7>
>>> Changes
>>> 
>>> Commit 915b3198107fb1f0c200e433227dcca7c9943343 by Andrew Trick:
>>> [AccessEnforce] must handle `undef` before diagnostics.
>>> 
>>> edit: lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp
>>> edit: test/SILOptimizer/access_enforcement_selection.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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 - Long Test (master) #2126

[Bob Wilson via swift-dev]

The hope is that the “SkyNet” project that Marc Shifer’s team is developing 
will be able to help with things like that. The “emoji hashes” in our new 
Jenkins 2 bots are the first step in that direction….

> On Apr 14, 2017, at 9:08 PM, Andrew Trick  wrote:
> 
> > runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED
> 
> This is unrelated to my commit and recovered on the next build. Is it 
> spurious? Can CI be taught to recognize known spurious asserts?
> 
> -Andy
> 
> 
>> On Apr 14, 2017, at 7:51 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#2126]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/2126/
>>  
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04-long-test
>> Date of build:   Fri, 14 Apr 2017 19:18:26 -0700
>> Build duration:  33 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 915b3198107fb1f0c200e433227dcca7c9943343 by Andrew Trick:
>> [AccessEnforce] must handle `undef` before diagnostics.
>> 
>> edit: lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp
>> edit: test/SILOptimizer/access_enforcement_selection.swift
> 

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

[swift-dev] heads-up: need to rebuild LLVM

[Bob Wilson via swift-dev]

I’m planning to merge this PR tomorrow:

https://github.com/apple/swift/pull/7469 


It requires a change in LLVM from about 2 weeks ago. I’ve been holding the 
Swift side of the change for a while to increase the chances that people will 
not run into problems from using an old copy of LLVM. So, if you haven’t 
updated and rebuilt LLVM in the last few weeks, this would be a good time to do 
that.___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] proposed change for master-next merges

[Bob Wilson via swift-dev]

> On Feb 9, 2017, at 5:49 PM, Bob Wilson via swift-dev  
> wrote:
> 
> Since the feedback on this was all positive, we’re moving ahead with this 
> change. It seems like a good time for a status update.
> 
> Some changes are already done:
> 
> * We test up a test bot to build against the upstream-with-swift branches of 
> LLVM/Clang 
> (https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next-upstream-with-swift/
>  
> <https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next-upstream-with-swift/>).
>  This has been working well.

I think we can remove this test bot now, so don’t be surprised if it goes away 
soon.

> 
> * Mishal set up an automerger to continuously update the Swift master-next 
> branch with changes from master.
> 
> * I audited the master-next branches in the other repos (e.g., swiftpm, etc.) 
> and found that none of them have any changes from master. For now, we will 
> simply stop using those branches, and once we’re done with this transition 
> and things are settled, we can remove them.
> 
> * We’ve had some discussions about how LLDB will fit into this plan. See the 
> recent thread on “Changes to LLDB Branch Management” for details on that.
> 
> Here is what is left to do:
> 
> * Update all of our master-next bots to build against the “new” branches 
> (e.g., upstream-with-swift instead of stable-next).

New update: Mishal switched all the master-next bots to build against 
Clang/LLVM upstream-with-swift, so this step is done now.

The bad news is that things are in kind of bad shape. Beginning on Wednesday, 
the build stopped working — it is getting killed by timeouts, so maybe 
something is hanging.

> 
> * Update documentation.
> 
> * Remove unused branches.
> 
>> On Dec 8, 2016, at 10:54 AM, Michael Gottesman > <mailto:mgottes...@apple.com>> wrote:
>> 
>>> 
>>> On Dec 8, 2016, at 7:43 AM, Saleem Abdulrasool via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Having been involved in the update process for the next branches, I'm 
>>> really excited to see this type of change.
>>> 
>>> I think that the "simple" approach is both better to work and collaborate 
>>> in as well as closer to the llvm development model which makes it easier to 
>>> cross pollinate.
>>> 
>>> The one thing that I think could be more strongly called out is that normal 
>>> PR CI shouldn't be gated on master next passing.
>>> 
>>> Beyond that, I think that this proposal should ease collaboration and 
>>> maintenance pains in the current process.
>> 
>> I agree with everything said here. The collaboration issue is the high order 
>> bit that needs to be fixed. Any other issues that come up can be fixed 
>> incrementally if necessary based on experience (for instance using the "back 
>> up" alternative). This is even more true since it is clear that that 
>> infrastructure would take time to develop and an incremental solution now 
>> that improves the collaboration will not make it more difficult to develop 
>> such a solution.
>> 
>> My only strong feeling here is that I think we need documentation of this 
>> process in ./docs in addition to this proposal.
>> 
>> Michael
>> 
>>> 
>>> On Wed, Dec 7, 2016 at 7:30 PM Bob Wilson via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> I would like to make a change in the way we handle the master-next branch.
>>> 
>>> Summary: I’d like to switch to a model where we continuously test against 
>>> the latest upstream LLVM changes. The goal is to simplify the process and 
>>> make it easier to collaborate on maintaining master-next.
>>> 
>>> Background: We develop Swift against “stable” branches of LLVM (which I am 
>>> using here to refer to the llvm, clang, and compiler-rt repositories) that 
>>> are typically rebranched from trunk once for each release, with other 
>>> commits individually cherry-picked for specific bug fixes and other 
>>> changes. This insulates Swift development from the churn of changes in 
>>> LLVM. At the same time, we maintain the “master-next” branches of Swift 
>>> repos to keep up to date with trunk LLVM. For Swift, our “trunk” comes from 
>>> the “upstream-with-swift” branches in our GitHub LLVM repos. We have 
>>> existing automation to continuously merge changes from llvm.org 
>>> <http://llvm.org/> into those upstream-with-swift branches.
>>> 
>>> We curr

Re: [swift-dev] proposed change for master-next merges

[Bob Wilson via swift-dev]

Since the feedback on this was all positive, we’re moving ahead with this 
change. It seems like a good time for a status update.

Some changes are already done:

* We test up a test bot to build against the upstream-with-swift branches of 
LLVM/Clang 
(https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next-upstream-with-swift/
 
<https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-osx-master-next-upstream-with-swift/>).
 This has been working well.

* Mishal set up an automerger to continuously update the Swift master-next 
branch with changes from master.

* I audited the master-next branches in the other repos (e.g., swiftpm, etc.) 
and found that none of them have any changes from master. For now, we will 
simply stop using those branches, and once we’re done with this transition and 
things are settled, we can remove them.

* We’ve had some discussions about how LLDB will fit into this plan. See the 
recent thread on “Changes to LLDB Branch Management” for details on that.

Here is what is left to do:

* Update all of our master-next bots to build against the “new” branches (e.g., 
upstream-with-swift instead of stable-next).

* Update documentation.

* Remove unused branches.

> On Dec 8, 2016, at 10:54 AM, Michael Gottesman  wrote:
> 
>> 
>> On Dec 8, 2016, at 7:43 AM, Saleem Abdulrasool via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Having been involved in the update process for the next branches, I'm really 
>> excited to see this type of change.
>> 
>> I think that the "simple" approach is both better to work and collaborate in 
>> as well as closer to the llvm development model which makes it easier to 
>> cross pollinate.
>> 
>> The one thing that I think could be more strongly called out is that normal 
>> PR CI shouldn't be gated on master next passing.
>> 
>> Beyond that, I think that this proposal should ease collaboration and 
>> maintenance pains in the current process.
> 
> I agree with everything said here. The collaboration issue is the high order 
> bit that needs to be fixed. Any other issues that come up can be fixed 
> incrementally if necessary based on experience (for instance using the "back 
> up" alternative). This is even more true since it is clear that that 
> infrastructure would take time to develop and an incremental solution now 
> that improves the collaboration will not make it more difficult to develop 
> such a solution.
> 
> My only strong feeling here is that I think we need documentation of this 
> process in ./docs in addition to this proposal.
> 
> Michael
> 
>> 
>> On Wed, Dec 7, 2016 at 7:30 PM Bob Wilson via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> I would like to make a change in the way we handle the master-next branch.
>> 
>> Summary: I’d like to switch to a model where we continuously test against 
>> the latest upstream LLVM changes. The goal is to simplify the process and 
>> make it easier to collaborate on maintaining master-next.
>> 
>> Background: We develop Swift against “stable” branches of LLVM (which I am 
>> using here to refer to the llvm, clang, and compiler-rt repositories) that 
>> are typically rebranched from trunk once for each release, with other 
>> commits individually cherry-picked for specific bug fixes and other changes. 
>> This insulates Swift development from the churn of changes in LLVM. At the 
>> same time, we maintain the “master-next” branches of Swift repos to keep up 
>> to date with trunk LLVM. For Swift, our “trunk” comes from the 
>> “upstream-with-swift” branches in our GitHub LLVM repos. We have existing 
>> automation to continuously merge changes from llvm.org <http://llvm.org/> 
>> into those upstream-with-swift branches.
>> 
>> We currently use a manual process to update master-next. Someone on the 
>> Swift team is designated as the "merge czar" and is responsible for this. 
>> This merge typically happens once every few weeks. Michael Gottesman 
>> developed some internal tools to help automate the process, but someone 
>> still needs to drive those tools manually. The process involves merging 
>> “master” to “master-next” for all the Swift repos and updating the 
>> “stable-next” branches of the GitHub LLVM repos for Swift. The “stable-next” 
>> branches are basically snapshots of the LLVM upstream-with-swift branches at 
>> the point where master-next was most recently merged.
>> 
>> Swift CI includes a set of Jenkins bots to test master-next building with 
>> the stable-next branches of LLVM 
>> (https://ci.swift.org/view/swi

Re: [swift-dev] [swift-lldb-dev] Changes to LLDB Branch Management

[Bob Wilson via swift-dev]

> On Feb 9, 2017, at 1:43 PM, Chris Bieneman via swift-dev 
>  wrote:
> 
>> 
>> On Feb 9, 2017, at 12:09 PM, Jordan Rose via swift-dev > > wrote:
>> 
>> Hi, Chris. I’m a bit confused by these changes. Swift’s master-next isn’t 
>> paired with upstream-with-swift; it’s paired with stable-next, which is 
>> resync’d to upstream-with-swift on a fairly regular cadence. Have you 
>> discussed this with the “merge czars” on the Swift side, who maintain 
>> master-next and stable-next?
> 
> This has been discussed with the “merge czars”, and we may end up creating a 
> stable-next branch, but Bob Wilson suggested that they were considering 
> changes to the merge process that would eliminate the need for that branch.

Yes, I sent a proposal to swift-dev about this on Dec. 7. The feedback was 
positive so we are moving forward with this plan. I’ll reply on that other 
thread with an update on the status.


> 
>> 
>> “upstream-with-trunk” is redundant; the “upstream” referred to in 
>> “upstream-with-swift” is LLVM trunk. “upstream-plus-swift-support” might 
>> have been a better name for the LLVM branch.
> 
> I mis-wrote that. It is “upstream-with-swift” not trunk. The LLDB “upstream” 
> branch will be going away because it is unnecessary to maintain a branch that 
> matches LLVM.org .
> 
>> 
>> What happens on the LLDB “stable" branch? No development happens on LLVM or 
>> Clang’s “stable” branch; they’re essentially just aliases for the latest 
>> release branch. Does the LLDB “stable” branch build against Swift master or 
>> Swift’s latest release branch?
> 
> LLDB’s stable branch will be maintained in exactly the same way LLVM & 
> Clang’s stable branches are. So it is currently identical to the 
> swift-4.0-branch.
> 
>> 
>> When I change something on Swift master that affects LLDB, where do I send a 
>> pull request going forward? It would be very painful for Swift developers to 
>> have a master-next/stable-next build set up just to submit changes to LLDB; 
>> today, most Swift developers don’t even need to think about master-next 
>> unless something breaks.
> 
> Patches to LLDB for swift-related functionality should go into the most 
> current release branch, in the same way we handle LLVM & Clang changes.
> 
> -Chris
> 
>> 
>> Concerned,
>> Jordan
>> 
>> 
>>> On Feb 9, 2017, at 10:50, Chris Bieneman via swift-lldb-dev 
>>> mailto:swift-lldb-...@swift.org>> wrote:
>>> 
>>> Hello Swift-Dev and Swift-LLDB-Dev,
>>> 
>>> Over the last couple weeks we’ve been working on some changes to the branch 
>>> management strategy for the Swift-LLDB repository. The goal is to have LLDB 
>>> more closely align with the other projects forked from LLVM.org 
>>> . We believe that making this change will simplify the 
>>> contribution process for LLDB’s Swift support.
>>> 
>>> To this end, we are making the following changes:
>>> 
>>> LLDB has gained an upstream-with-trunk branch which will be auto-merged 
>>> from LLVM.org ’s LLDB/trunk. This branch will contain the 
>>> best of both worlds. The latest and greatest from LLVM.org 
>>> , and Swift support. This branch will pair to LLVM & 
>>> Clang’s upstream-with-swift branches and Swift’s master-next.
>>> 
>>> LLDB has also gained a stable branch which will behave the same way as the 
>>> LLVM & Clang stable branches, and should be used for most Swift compiler 
>>> development. Additionally we have made the swift-lldb/stable branch the 
>>> default branch on the GitHub repository, which matches the behavior of LLVM 
>>> & Clang.
>>> 
>>> LLDB’s master and master-next branches will be going away. Later today we 
>>> will lock the branches, and in a few days we’ll delete them. For most users 
>>> you’ll want to migrate from Swift-LLDB/master to Swift-LLDB/stable.
>>> 
>>> The new branches are already created, and the tooling will be coming online 
>>> over the next few days. Additionally, the Swift contributing page 
>>> (https://swift.org/contributing/#llvm-and-swift 
>>> ) has been updated to 
>>> reflect the alignment of the LLDB process with the other LLVM.org 
>>>  projects.
>>> 
>>> If you have any questions about the new process or the transition please 
>>> let me know.
>>> 
>>> Thank you,
>>> -Chris
>>> ___
>>> swift-lldb-dev mailing list
>>> swift-lldb-...@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-lldb-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/mai

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

[Bob Wilson via swift-dev]

 use gated merges from LLVM swift-*-branch to stable

> On Jan 31, 2017, at 1:20 PM, Frédéric Riss  wrote:
> 
> 
>> On Jan 31, 2017, at 1:17 PM, Michael Ilseman > > wrote:
>> 
>> Thanks, could you file a radar with the details?
> 
> I’m pretty sure there’s already one lying around. +Michael G, +Bob with whom 
> this was discussed in the past (this is about gating merges 
> swift-x.x-branch->stable on some kind of automatic PR testing).
> 
> Fred
> 
>> 
>> 
>>> On Jan 31, 2017, at 12:54 PM, Frédéric Riss >> > wrote:
>>> 
>>> 
 On Jan 31, 2017, at 12:03 PM, Michael Ilseman >>> > wrote:
 
 Fred, do you know why this wasn’t caught by PR testing?
>>> 
>>> This commit went to the clang stable branch. There’s no PR testing there. 
>>> I’ve been sloppy, the change was so simple that I decided no to test it. Of 
>>> course I typoed.
>>> 
>>> The plan was to get merges from swift-x.x-branch -> stable merges on some 
>>> kind of automates PR testing. This would have prevented my sloppiness from 
>>> breaking Swift. This really needs to be implemented.
>>> 
>>> Fred  
>>> 
 
> On Jan 31, 2017, at 11:16 AM, Michael Ilseman  > wrote:
> 
> Thank you!
> 
>> On Jan 31, 2017, at 11:15 AM, Frédéric Riss > > wrote:
>> 
>> Yes, I already pushed a fix. Sorry about that.
>> 
>> Fred
>>  
>>> On Jan 31, 2017, at 11:13 AM, Michael Ilseman >> > wrote:
>>> 
>>> Fred, probably you?
>>> 
>>> CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
>>>   Syntax error in cmake code at
>>> 
>>> 
>>> /Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79
>>> 
>>>   when parsing string
>>> 
>>> ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH
>>> 
>>>   There is an unterminated variable reference.
>>> 
>>> 
>>> -- Configuring incomplete, errors occurred!
>>> See also 
>>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
>>> See also 
>>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
>>> FAILED: build.ninja 
>>> /Applications/CMake.app/Contents/bin/cmake 
>>> -H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm
>>>  
>>> -B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
>>>  <>
>>> 
>>> 
>>> 
 On Jan 31, 2017, at 10:50 AM, no-re...@swift.org 
  wrote:
 
 [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
 
 Build URL: 
 https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
 
 Project:   oss-lldb-swift-3.1-incremental-osx
 Date of build: Tue, 31 Jan 2017 10:50:27 -0800
 Build duration:26 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 e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
 [CMake] Fixing variable names that were mistyped
 
 edit: tools/driver/CMakeLists.txt
 
 Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
 Add the patch version to the embedded Info.plist.
 
 edit: tools/driver/CMakeLists.txt
>>> 
>> 
> 
 
>>> 
>> 
> 

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

Re: [swift-dev] problem with compiler_crashers/28616-swift-parser-parseexprsequence-swift-diag-bool-bool.swift

[Bob Wilson via swift-dev]

OK, I’m still curious why the stack size is bigger when running via the test 
harness, but I agree with your conclusion. Here’s a PR to change the “REQUIRES” 
line to mention “deterministic-behavior”:

https://github.com/apple/swift/pull/6951 
<https://github.com/apple/swift/pull/6951>

> On Jan 19, 2017, at 8:16 PM, Slava Pestov  wrote:
> 
> I think this is fine.
> 
> We have a bunch of compiler_crashers which are non-deterministic because they 
> trigger undefined behavior at runtime, such as dangling pointers, stack 
> overflow, etc.
> 
> Disabling this is OK for now (it is still in compiler_crashers/ so it is 
> understood it is not yet fixed). In this case, the stack overflow won’t 
> really be addressed properly until we rework the parser to maintain its own 
> counter of nesting depth and bail out if its too deep.
> 
> Alternatively we could up the number of { in the test until it crashes 
> reliably on all of our test machines…
> 
> Slava
> 
>> On Jan 19, 2017, at 6:38 PM, Bob Wilson via swift-dev  
>> wrote:
>> 
>> As part of the move to reset the Clang/LLVM stable branches to their new 
>> versions, I disabled the 
>> compiler_crashers/28616-swift-parser-parseexprsequence-swift-diag-bool-bool.swift
>>  test because it was consistently failing to crash when I ran the tests 
>> locally. (It is expected to crash, so the test fails when it does not crash 
>> the compiler.) This is very strange because the test system prints out the 
>> failing command, and when I run that directly, I always get a crash. I can 
>> run it in a debugger and see that it is overflowing the stack.
>> 
>> For some reason, when the test runs from the test harness, it does not 
>> crash. Of course I get a ton of diagnostics because the input is invalid, 
>> but there is no crash. I tried doubling the number of braces in the test, 
>> but that did not help. I also tried to increase my stack size in case the 
>> test harness does that, but ulimit had no effect.
>> 
>> I don’t want to leave this test in limbo, but I’m kind of stuck figuring out 
>> why it is behaving inconsistently. Any ideas?
>> ___
>> 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] problem with compiler_crashers/28616-swift-parser-parseexprsequence-swift-diag-bool-bool.swift

[Bob Wilson via swift-dev]

As part of the move to reset the Clang/LLVM stable branches to their new 
versions, I disabled the 
compiler_crashers/28616-swift-parser-parseexprsequence-swift-diag-bool-bool.swift
 test because it was consistently failing to crash when I ran the tests 
locally. (It is expected to crash, so the test fails when it does not crash the 
compiler.) This is very strange because the test system prints out the failing 
command, and when I run that directly, I always get a crash. I can run it in a 
debugger and see that it is overflowing the stack.

For some reason, when the test runs from the test harness, it does not crash. 
Of course I get a ton of diagnostics because the input is invalid, but there is 
no crash. I tried doubling the number of braces in the test, but that did not 
help. I also tried to increase my stack size in case the test harness does 
that, but ulimit had no effect.

I don’t want to leave this test in limbo, but I’m kind of stuck figuring out 
why it is behaving inconsistently. Any ideas?
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] updating Clang/LLVM stable branches

[Bob Wilson via swift-dev]

> On Jan 17, 2017, at 1:41 PM, Bob Wilson via swift-dev  
> wrote:
> 
> As I mentioned yesterday, once the last swift-3.1 merge is done, we are 
> planning to update the stable branches for Clang/LLVM to use the new 
> swift-4.0 branches that are aligned with LLVM 4.0. I was expecting we would 
> do that today, but we’re going to wait until tomorrow (Wednesday) morning 
> instead. That will give us time to get all the master-next bots passing and 
> should also be less disruptive than making the switch in the middle of the 
> day.

This is done now. You will need to rebuild Clang and LLVM.

I am also about to push a new swift-4.0-branch in the Swift repo. Please do not 
make changes there. All development for Swift 4 should continue on the master 
branch. The point of this new branch is to have a version of Swift that is 
aligned with Swift 3.1 but builds against the newer version of Clang/LLVM 
(i.e., the swift-4.0-branch version). As in the past, for the Swift repos we’ll 
rebranch swift-4.0-branch repeatedly over the course of Swift 4 development, 
but for the clang, llvm, and compiler-rt repos, we will only be cherry-picking 
individual commits to swift-4.0-branch.

If you need to make changes to Clang/LLVM for Swift, please make pull requests 
to get those changes into swift-4.0-branch. If the changes are appropriate for 
upstream Clang/LLVM, please get the changes there first; otherwise, they should 
first go to the upstream-with-swift branch on our GitHub repos.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] updating Clang/LLVM stable branches

[Bob Wilson via swift-dev]

As I mentioned yesterday, once the last swift-3.1 merge is done, we are 
planning to update the stable branches for Clang/LLVM to use the new swift-4.0 
branches that are aligned with LLVM 4.0. I was expecting we would do that 
today, but we’re going to wait until tomorrow (Wednesday) morning instead. That 
will give us time to get all the master-next bots passing and should also be 
less disruptive than making the switch in the middle of the day.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Final merge from master to swift-3.1-branch

[Bob Wilson via swift-dev]

> On Jan 13, 2017, at 6:49 AM, Nicole Jacque via swift-dev 
>  wrote:
> 
> Hello Swift Developers-
> 
> As outlined in Ted’s Swift 3.1 Release Process blog post, for the past month, 
> we’ve been periodically merging master to the swift-3.1-branch branch.  We 
> will be doing one final merge of master to the swift-3.1-branch on January 17 
> at noon (Pacific). Note that we’ve pushed this back a day due to the MLK Jr. 
> Day holiday.   Any changes landed after that time will require approval via a 
> pull request against the swift-3.1-branch branch in order to include them in 
> the Swift 3.1 release.  After this final merge, development on master will be 
> targeted for Swift 4.

In association with this change, we’re also planning to update the “stable” 
branches of Clang/LLVM to be used for Swift 4. Since the LLVM project just 
branched for LLVM 4.0, we’re going to align with that version for Swift 4. This 
update to the stable branch is planned for tomorrow after the final merge for 
Swift 3.1.

> 
> Snapshots of the swift-3.1-branch will be made available on the downloads 
> page (https://swift.org/download/ ).  Snapshots 
> will be made available daily, if all package generation CI tests are passing.
___
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) #7501

[Bob Wilson via swift-dev]

Yes, he renamed sil-extract to sil-func-extractor 
(https://github.com/apple/swift/pull/6155/files 
) and missed updating some 
places. This should fix it: https://github.com/apple/swift/pull/6159 


(FWIW, I much preferred the old name. I don’t know why he changed it.)

> On Dec 8, 2016, at 8:08 PM, mishal_shah  wrote:
> 
> Hi Michael,
> 
> Is this related to your changes? 
> 
> ninja: error: 'bin/sil-extract', needed by 
> 'test/CMakeFiles/check-swift-validation-macosx-x86_64', missing and no known 
> rule to make it
> *** Failed while running tests for swift 
> (check-swift-validation-macosx-x86_64)
> 
> Thanks,
> Mishal Shah
>> On Dec 8, 2016, at 7:52 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#7501]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-RA-osx/7501/ 
>> 
>> Project: oss-swift-incremental-RA-osx
>> Date of build:   Thu, 08 Dec 2016 19:29:59 -0800
>> 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 
>> 
>> Changes
>> 
>> Commit 0bfda96ace06c95fd7b8ab5c0a08ef828940f873 by mgottesman:
>> [sil-func-extractor] Teach sil-extract to extract a list of functions
>> 
>> delete: test/sil-extract/basic.sil
>> delete: test/sil-extract/basic.swift
>> edit: test/ClangImporter/serialization-sil.swift
>> add: test/sil-func-extractor/basic.swift
>> delete: test/sil-extract/load-serialized-sil.swift
>> edit: include/swift/Basic/STLExtras.h
>> delete: tools/sil-extract/CMakeLists.txt
>> add: test/sil-func-extractor/load-serialized-sil.swift
>> edit: test/lit.cfg
>> add: test/sil-func-extractor/basic.sil
>> add: tools/sil-func-extractor/CMakeLists.txt
>> add: tools/sil-func-extractor/SILFunctionExtractor.cpp
>> edit: tools/CMakeLists.txt
>> delete: tools/sil-extract/SILExtract.cpp
>> add: test/sil-func-extractor/multiple-functions.sil
>> 
>> Commit 8972b43abbfb1773b2997da06873ec5fc2c94e6f by mgottesman:
>> [sil-tooling] Rename sil-sort-output => emit-sorted-sil.
>> 
>> edit: tools/sil-opt/SILOpt.cpp
>> edit: test/SIL/Serialization/semanticsattr.sil
>> edit: test/SILOptimizer/inlinecaches_arc.sil
>> edit: test/SILOptimizer/loop-region-analysis.sil
>> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
>> 
>> Commit c12aeabd90a71e512618fdcc7d0e32adbbe1c462 by mgottesman:
>> [sil-func-extractor] Add support for emitting sib files.
>> 
>> edit: tools/sil-func-extractor/SILFunctionExtractor.cpp
>> edit: test/sil-func-extractor/basic.sil
>> 
>> Commit c2e63dcbc17a21ab07850a2ae151728eea8f48da by bob.wilson:
>> Disable sanitizers for the runtime with
>> 
>> edit: stdlib/CMakeLists.txt
>> 
>> Commit 49e6c06eef75f2b6050876840bb3aeb978282be1 by jordan_rose:
>> [validation-test] Remove "REQUIRES: asserts" from /fixed/ crash cases.
>> 
>> edit: 
>> validation-test/compiler_crashers_fixed/28423-swift-typechecker-validatedecl.swift
>> edit: validation-test/SIL/crashers_fixed/003-swift-parser-parsetypesimple.sil
>> edit: 
>> validation-test/IDE/crashers_fixed/078-swift-iterativetypechecker-processtypechecksuperclass.swift
>> edit: 
>> validation-test/SIL/crashers_fixed/008-swift-genericparamlist-getasgenericsignatureelements.sil
>> edit: 
>> validation-test/compiler_crashers_fixed/28370-swift-decomposeparamtype.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28306-swift-lookupvisibledecls.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28410-swift-typechecker-typecheckdecl.swift
>> edit: 
>> validation-test/IDE/crashers_fixed/087-swift-declcontext-getparentmodule.swift
>> edit: validation-test/compiler_crashers_fixed/28454-hasval-failed.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/10659-swift-printingdiagnosticconsumer-handlediagnostic.timeout.swift
>> edit: 
>> validation-test/SIL/crashers_fixed/007-swift-abstractstoragedecl-makecomputed.sil
>> edit: 
>> validation-test/compiler_crashers_fixed/28249-swift-typechecker-validategenericfuncsignature.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28291-swift-constraints-constraintsystem-comparesolutions.swift
>> edit: 
>> validation-test/IDE/crashers_fixed/015-swift-typechecker-lookupunqualified.swift
>> edit: 
>> validation-test/IDE/crashers_fixed/056-swift-archetypebuilder-getallarchetypes.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28298-swift-namealiastype-getsinglydesugaredtype.swift
>> edit: validation-test/Sema/type_checker_crashers_fixed/rdar27575060.swift
>> edit: 
>> validation-test/compiler_crashers_fixed/28207-swift-dependentgenerictyperesolver-resolveselfassociatedtype.swift
>> edit: 
>> validation-test/IDE/cr

[swift-dev] proposed change for master-next merges

[Bob Wilson via swift-dev]

I would like to make a change in the way we handle the master-next branch.

Summary: I’d like to switch to a model where we continuously test against the 
latest upstream LLVM changes. The goal is to simplify the process and make it 
easier to collaborate on maintaining master-next.

Background: We develop Swift against “stable” branches of LLVM (which I am 
using here to refer to the llvm, clang, and compiler-rt repositories) that are 
typically rebranched from trunk once for each release, with other commits 
individually cherry-picked for specific bug fixes and other changes. This 
insulates Swift development from the churn of changes in LLVM. At the same 
time, we maintain the “master-next” branches of Swift repos to keep up to date 
with trunk LLVM. For Swift, our “trunk” comes from the “upstream-with-swift” 
branches in our GitHub LLVM repos. We have existing automation to continuously 
merge changes from llvm.org  into those upstream-with-swift 
branches.

We currently use a manual process to update master-next. Someone on the Swift 
team is designated as the "merge czar" and is responsible for this. This merge 
typically happens once every few weeks. Michael Gottesman developed some 
internal tools to help automate the process, but someone still needs to drive 
those tools manually. The process involves merging “master” to “master-next” 
for all the Swift repos and updating the “stable-next” branches of the GitHub 
LLVM repos for Swift. The “stable-next” branches are basically snapshots of the 
LLVM upstream-with-swift branches at the point where master-next was most 
recently merged.

Swift CI includes a set of Jenkins bots to test master-next building with the 
stable-next branches of LLVM (https://ci.swift.org/view/swift-master-next 
). The merge czar can use these 
bots to confirm that everything is working after a merge.

Reasons to change: The current process has the advantage that the merge czar 
can choose when to do a merge and can schedule that around other work, but it 
has some significant problems.

- It is difficult for multiple people to collaborate on updating master-next. 
The changes involved are often rev-locked between Swift and the LLVM repos, so 
there is no good way for someone to fix a problem without doing the whole merge 
process.

- The current system is hard to understand. I’ve been serving as the merge czar 
for the last few months, and it took me a while to figure out how to do it well.

- It requires extra “stable-next” branches in our GitHub LLVM repos, further 
adding to the complexity.

- The tools we have to help automate the process are currently internal to 
Apple and require ongoing maintenance. They could be cleaned up to release 
publicly but that would take more work.

Proposal: We already have Jenkins bots testing master-next. I would like to add 
a job to continuously merge master to master-next and change the existing bots 
to build against the “upstream-with-swift” branches in our GitHub LLVM repos. 
The bots would then detect any new problems soon after they are introduced. 
Anyone could fix those problems, whether they are merge conflicts, build 
failures, or test issues. A partial fix could be applied directly without 
needing to resolve all of the outstanding issues.

This would avoid the need for our current internal merging tools. We already 
have automatic merging bots, so adding another one would not be difficult.

The biggest advantage is that it provides a straightforward model that anyone 
can understand: master-next becomes just another branch that anyone can modify, 
build and test in the usual way. Collaboration is no more difficult than for 
other branches.

The cost of this simpler approach is that we would need to be willing to let 
the master-next branch break occasionally. An LLVM change might break things in 
a way that takes some time to fix, and the master-next bots would continue to 
fail during that time. Someone might want to apply a partial fix that does not 
resolve all the issues, and we would want to allow that even if the bots still 
fail. That would mean we would have to relax (or override) the requirement for 
PR testing for commits in that kind of situation. In the worst case, if new 
problems are introduced more quickly than we can fix them, this approach could 
fall apart. My experience as merge czar over the last few months suggests that 
is unlikely. Usually there are no more than a few problems per week and most of 
them are easy to fix.

I propose to roll this out in steps. First, we can add a new Jenkins bot that 
tests master-next building against upstream-with-swift. If that goes well, and 
if there are no objections to this proposal, we can add the automerger to merge 
master into master-next. At the same time, we would update the other 
master-next bots to use upstream-with-swift instead of stable-next for the LLVM 
repos.

Alternative: We can achiev

Re: [swift-dev] why are we accepting switch statements with duplicate conditions?

[Bob Wilson via swift-dev]

> On Sep 14, 2016, at 10:32 AM, John McCall via swift-dev  
> wrote:
> 
>> On Sep 14, 2016, at 10:25 AM, Ted Kremenek via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Hi everyone,
>> 
>> Joe Shajrawi nominated an optimizer fix for Swift 3.0.1 where the optimizer 
>> was crashing due to duplicate conditions in aswitchstatement:
>> 
>> https://bugs.swift.org/browse/SR-2512 
>> https://github.com/apple/swift/pull/4747 
>> 
>> Here’s an example:
>> 
>> public enum DemoEnum {
>> case firstCase
>> case secondCase
>> 
>> public static func performSwitch(with value: Int) -> DemoEnum {
>> switch value {
>> case 0:
>> return DemoEnum.firstCase
>> case 0:
>> return DemoEnum.firstCase
>> default:
>> return DemoEnum.secondCase
>> }
>> }
>> }
>> I can’t remember why the frontend even accepts this code. Is this intended, 
>> or just a defect in the compiler’s validity checking ofswitch statements?
>> 
>> 
> 
> It would be legitimate with, say, a condition on the first case.  But yeah, 
> this is undoubtedly just a defect in the compiler's checking.
> 
> Recall that a switch in Swift doesn't necessarily compile to a primitive 
> switch; it's more like a series of ifs that's a bit more straightforward to 
> optimize matching for.  So the validity checking you'd expect as a matter of 
> course in C doesn't just fall out automatically.
> 
> Also, of course, the compiler does not have primitive knowledge of Int or how 
> it forms literals.
> 
> John.

Joe filed a radar to improve the checking:
 reject duplicate conditions when optimizing switch 
statement
>> Thanks,
>> Ted
>> 
>> ___
>> 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] compiler-rt...Wait wat?

[Bob Wilson via swift-dev]

> On Aug 17, 2016, at 5:48 AM, Ryan Lovelett via swift-dev 
>  wrote:
> 
> I just noticed that if you do `utils/update-checkout --clone` it pulls
> down `compiler-rt`. I have been building Swift from source on Linux for
> awhile now. I've never once checked out compiler-rt. Which makes me
> wonder if that repository is even in use.
> 
> Here is the question: what is the compiler-rt repository used for? Is my
> build not working as expected without compiler-rt?

At least one reason is that the runtime support for code coverage testing is in 
compiler-rt. We want to be able to test Swift’s support for code coverage and 
we need the runtime library to be able to run those tests.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] new code owner for the SIL optimizer

[Bob Wilson via swift-dev]

CODE_OWNERS.TXT still shows Nadav as the owner of the SIL optimizer, even 
though he is no longer working on Swift. We should have a new code owner, and I 
would like to nominate Erik Eckstein. There are a lot of different components 
to the SIL optimizer and no single person is an expert in all of them, but Erik 
has made significant contributions across many parts of the optimizer. I think 
he would be a good choice to serve as the code owner.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[Bob Wilson via swift-dev]

+ Dave

> On Jul 18, 2016, at 4:55 PM, Mark Lacey  wrote:
> 
>> 
>> On Jul 18, 2016, at 4:43 PM, Bob Wilson via swift-dev > <mailto:swift-dev@swift.org>> wrote:
>> 
>> I’m composing this by hand because I don’t see any notification that was 
>> sent to swift-dev.
>> 
>> https://ci.swift.org/job/oss-swift-incremental-RA-osx/5294/ 
>> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/5294/>
>> 
>> The failure is:
>> 
>> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swift/stdlib/private/StdlibUnittestFoundationExtras/StdlibUnittestFoundationExtras.swift:71:19:
>>  error: missing argument label 'invoking:' in call
>> 
>>   autoreleasepool(body)
>>   ^
>>   invoking: 
>> 
>> I’m not sure what change might have caused that.
> 
> I believe it’s from this PR: https://github.com/apple/swift/pull/3589 
> <https://github.com/apple/swift/pull/3589>
> 
> Mark
> 
>> ___
>> 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

[swift-dev] [Swift CI] Build Failing: OSS - Swift Incremental RA - OS X (master) #5294

[Bob Wilson via swift-dev]

I’m composing this by hand because I don’t see any notification that was sent 
to swift-dev.

https://ci.swift.org/job/oss-swift-incremental-RA-osx/5294/ 


The failure is:

/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swift/stdlib/private/StdlibUnittestFoundationExtras/StdlibUnittestFoundationExtras.swift:71:19:
 error: missing argument label 'invoking:' in call

  autoreleasepool(body)
  ^
  invoking: 

I’m not sure what change might have caused that.___
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 14.04 (master) #1442

[Bob Wilson via swift-dev]

Slava fixed that in c9cd33bb. Hopefully the next run will succeed. Thanks, 
Slava!

> On Jun 2, 2016, at 7:17 PM, Douglas Gregor via swift-dev 
>  wrote:
> 
> Looks like a great that should require the Objjective-C runtime. 
> 
> Sent from my iPhone
> 
> On Jun 2, 2016, at 7:01 PM, no-re...@swift.org  
> wrote:
> 
>> [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#1442]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/1442/ 
>> 
>> Project: oss-swift-package-linux-ubuntu-14_04
>> Date of build:   Thu, 02 Jun 2016 18:13:51 -0700
>> Build duration:  48 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 
>> 
>> Changes
>> 
>> Commit 6a507d631154a2b3ab51bb45ae6c8f43e0428545 by gribozavr:
>> Runtime: give each source file a unique basename
>> 
>> delete: stdlib/public/runtime/Reflection.cpp
>> delete: stdlib/public/runtime/SwiftObject.cpp
>> add: stdlib/public/runtime/SwiftObjectNative.cpp
>> delete: stdlib/public/runtime/ErrorObject.cpp
>> add: stdlib/public/runtime/ErrorObjectNative.cpp
>> add: stdlib/public/runtime/ReflectionNative.cpp
>> edit: stdlib/public/runtime/CMakeLists.txt
>> 
>> Commit 66626baa882acb537668f03c4ed610b91fb3108d by gribozavr:
>> CMake: set the 'header' property on .def and .td files
>> 
>> edit: cmake/modules/AddSwift.cmake
>> 
>> Commit 83b9815c52126b83cad828240c9f197c977e8ef2 by gribozavr:
>> CMake: Xcode: add a dummy source file to standard library dylib as well
>> 
>> edit: cmake/modules/AddSwift.cmake
>> add: cmake/dummy.cpp
>> delete: cmake/dummy.c
>> 
>> Commit b76630735a78be81077201f1ebac4497211ca520 by nmersethcook:
>> [stdlib] Add tests for FloatingPoint's nextUp and nextDown
>> 
>> edit: test/1_stdlib/FloatingPoint.swift.gyb
>> edit: stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb
>> 
>> Commit 73811d625d65d0a50df62f7ad69311f973347b06 by nmersethcook:
>> [stdlib] Fix for nextUp and nextDown
>> 
>> edit: stdlib/public/core/FloatingPointTypes.swift.gyb
>> 
>> Commit 586aefd7850523e222f4fdc5217f0dcafa9c6932 by devteam.codafi:
>> Resolve SR-1397
>> 
>> edit: lib/AST/Decl.cpp
>> add: test/decl/class/constructor_search_outer.swift
>> 
>> Commit 1b458c8fb890e5fd34ce1660cc7d1f5e94e7843e by jgroff:
>> Augment test/SILGen/objc_imported_generic.swift to ensure it gets
>> 
>> edit: test/SILGen/objc_imported_generic.swift
>> 
>> Commit 3753d779bc13d13b2a2d9ccf828938938fb7f3a1 by dgregor:
>> [Type checker] Be more rigorous about extracting argument labels from
>> 
>> edit: lib/Sema/CSGen.cpp
>> edit: lib/Sema/CodeSynthesis.cpp
>> edit: lib/Sema/TypeCheckREPL.cpp
>> edit: lib/AST/Expr.cpp
>> edit: lib/Sema/CSApply.cpp
>> edit: lib/ClangImporter/ImportDecl.cpp
>> edit: lib/Sema/PlaygroundTransform.cpp
>> edit: include/swift/AST/Expr.h
>> edit: lib/Sema/CSSimplify.cpp
>> edit: lib/Sema/MiscDiagnostics.cpp
>> edit: lib/Sema/ConstraintSystem.h
>> edit: lib/Sema/TypeCheckConstraints.cpp
>> 
>> Commit 492a26bf40d83cd05b52d9af8ec6c70197e2144c by dfarler:
>> [SwiftRemoteMirror] Consider ObjCClass field descriptors when converting
>> 
>> add: validation-test/Reflection/inherits_NSObject.swift
>> edit: stdlib/public/Reflection/TypeLowering.cpp
>> 
>> Commit 641cd6e8b25a6082c4b5d7abd1e1a4bda52af0fe by aprantl:
>> PR26055: Speed up LiveDebugValues by replacing lists with bitvectors.
>> 
>> edit: test/DebugInfo/MIR/X86/live-debug-values-3preds.mir
>> edit: lib/CodeGen/LiveDebugValues.cpp
>> 
>> Commit ffb33a39f19fc5e7e3cee26c173566ec7f32927b by aprantl:
>> Work around an MSVC compiler issue in r270776.
>> 
>> edit: lib/CodeGen/LiveDebugValues.cpp
>> 
>> Commit 7731adc8f116ad472fd05b67e6836f806525bc0a by aprantl:
>> Undo a suboptimal clang-format decision. NFC
>> 
>> edit: lib/CodeGen/LiveDebugValues.cpp
>> 
>> Commit a339423518088eb95ae52030606cfc574cbcaf76 by aprantl:
>> PR26055: Speed up LiveDebugValues::transferDebugValue()
>> 
>> edit: lib/CodeGen/LiveDebugValues.cpp
>> 
>> Commit c69799f7820db72669b57194b880c922a0b41977 by scallanan:
>> Fixed a problem where we couldn't call extern "C" functions.
>> 
>> edit: source/Expression/IRExecutionUnit.cpp
>> add: packages/Python/lldbsuite/test/lang/cpp/extern_c/main.cpp
>> add: packages/Python/lldbsuite/test/lang/cpp/extern_c/TestExternCSymbols.py
>> edit: include/lldb/Expression/IRExecutionUnit.h
>> add: packages/Python/lldbsuite/test/lang/cpp/extern_c/Makefile
>> 
> ___

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

[Bob Wilson via swift-dev]

John, this is yours, right?

> On May 11, 2016, at 3:38 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#3999]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/3999/ 
> 
> Project:  oss-swift-incremental-RA-osx
> Date of build:Wed, 11 May 2016 15:11:50 -0700
> Build duration:   26 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
> Failed: 1 test(s), Passed: 7898 test(s), Total: 7899 test(s)
> Failed: Swift.stdlib.FixedPointDiagnostics.swift.gyb 
> 
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 351 test(s), Total: 351 test(s)
> 
> Changes
> 
> Commit 35ba809fd0665eba2bbe5d0f1cca2f37d00ae620 by rjmccall:
> Don't diagnose failures to call symmetrically-typed binary operators as
> 
> edit: test/NameBinding/multi-file-with-main.swift
> edit: test/stmt/foreach.swift
> edit: test/1_stdlib/UnicodeScalarDiagnostics.swift
> edit: test/expr/expressions.swift
> edit: test/Constraints/patterns.swift
> edit: test/Misc/misc_diagnostics.swift
> edit: test/Constraints/bridging.swift
> edit: test/expr/closure/closures.swift
> edit: lib/Sema/CSDiag.cpp
> edit: test/Parse/recovery.swift
> edit: include/swift/AST/DiagnosticsSema.def
> edit: test/Constraints/diagnostics.swift

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