Re: [swift-dev] Metadata Representation

> On Sep 25, 2017, at 1:30 AM, John McCall via swift-dev > wrote: > > >> On Sep 22, 2017, at 8:39 PM, Saleem Abdulrasool > > wrote: >> >> On Thu, Sep 21, 2017 at 10:28 PM, John McCall >

Re: [swift-dev] Metadata Representation

> On Sep 22, 2017, at 8:39 PM, Saleem Abdulrasool wrote: > > On Thu, Sep 21, 2017 at 10:28 PM, John McCall > wrote: > >> On Sep 21, 2017, at 10:10 PM, Saleem Abdulrasool >

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

> On Sep 24, 2017, at 1:13 AM, David Zarzycki via swift-dev > wrote: > Hi Robert, > > As a prerequisite to some other hacking I’m doing, I have an experimental > implementation of value semantics; where (among other details), all functions > have a bit in ExtInfo that

Re: [swift-dev] libdispatch switched to CMake

On Sat, Sep 23, 2017 at 5:02 AM, David P Grove wrote: > With autotools, the first time libdispatch was built (for SourceKit), it > just did the C build of libdispatch. That had to be blown away and rebuilt > a second time later (once swiftc, etc was available) so that we could

Re: [swift-dev] Function overload resolution

If either function had the correct signature and was being properly disambiguated there would not be a diagnostic popped. Can you provide an example of this? ~Robert Widmann > On Sep 24, 2017, at 8:58 PM, Nevin Brackett-Rozinsky > wrote: > > The new

Re: [swift-dev] Function overload resolution

The new diagnostic is fine, the problem is that there should not be an error at all. If there is only one function with the proper signature, the compiler should not invent a non-existent ambiguity. The situation I encountered involves functions of different arities, so it should be

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

I don't think this is related to my commit. All the slaves appear to be in a `detached` state. On Sun, Sep 24, 2017 at 2:44 PM, no-reply--- via swift-dev < swift-dev@swift.org> wrote: > [FAILURE] oss-swift-package-osx [#348] > Build URL: https://ci.swift.org/job/oss-swift-package-osx/348/ >

Re: [swift-dev] Function overload resolution

This appears to be resolved (in fact, I remember improving this some time ago). I get a much better diagnostic now > error: repl.swift:4:16: error: use of 'min' refers to instance method 'min()' > rather than global function 'min' in module 'Swift' > return min(1,2) >^

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

Then the split you want isn’t at the level of the ClosureExpr, it’s at the level of the ApplyExpr. You should take a look at CSRanking and penalize/remove overloads that have arguments whose “I have value semantics” bits don’t match. ~Robert Widmann > On Sep 24, 2017, at 8:01 AM, David

[swift-dev] Function overload resolution

I recently got bit by SR-2450 , and I’d like to try to fix it. However, I’ve never worked on the compiler before and I have some questions: 1. Is this a reasonable first bug to tackle? 2. What resources are available for newcomers to the Swift project? 3.

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

Well, for starters, a function with zero arguments/parameters can be value semantic. For example: func getMagicNumber() -> UInt64 { return 0x3A4B1C7539DA4922 } Dave > On Sep 24, 2017, at 01:36, Robert Widmann via swift-dev > wrote: > > Why is the arrow carrying the