Re: [swift-users] Compile time tests

2017-03-31 Thread José Manuel Sánchez via swift-users
Excellent! I hadn’t thought that you would need this to test the compiler 
itself. Would be nice to have some supported and documented way to do this at 
some point, but it works for me.

Regards
José Manuel

> El 31 mar 2017, a las 11:41, Slava Pestov  escribió:
> 
> We have an undocumented -verify flag you can use for this. Here’s some code 
> that doesn’t type check because the second call to g() is passing a type that 
> does not conform to protocol P:
> 
> protocol P {}
> protocol Q {}
> 
> struct R : P {}
> struct S : Q {}
> 
> func g(_: T) {}
> 
> g(R())
> g(S()) // expected-error{{does not conform}}
> 
> ——
> 
> When you run this file through swiftc and pass the magic incarnation 
> ‘-typecheck -Xfrontend -verify’, the compiler exits with a code of 0 
> indicating success, because a diagnostic was produced on the line with the 
> ‘expected-error’ directive, and no other errors were produced:
> 
> Slavas-MBP:swift slava$ 
> ../build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc -typecheck 
> -Xfrontend -verify generics.swift
> Slavas-MBP:swift slava$ echo $?
> 0
> 
> You’ll need to come up with some way to wire the above up into your test 
> harness, because as you correctly observed we never allow ill-typed code to 
> *execute*.
> 
> It goes without saying that anything involving -Xfrontend is 
> undocumented/unsupported/can change at any time. And of course the phrasing 
> of the diagnostics can and will change too, which would also cause your test 
> to fail. But we use this functionality extensively in our own test suite — 
> it’s how we ensure that diagnostics don’t regress and invalid code is 
> rejected in a clean way instead of crashing.
> 
> Slava
> 
>> On Mar 31, 2017, at 12:44 AM, José Manuel Sánchez via swift-users 
>> > wrote:
>> 
>> I don’t know if this has come before (I tried searching but it’s not easy 
>> with the mailing lists system); sorry in advance if that’s the case.
>> 
>> I’ve been using more generics lately, and I’ve come to a point where it 
>> would be really nice to check if my types are correctly specified so that a 
>> wrong combination isn’t possible because the compiler will not allow it. The 
>> problem is, I can’t do this using unit testing, because if everything is 
>> correct, the code won’t compile, and then the tests will fail. I’m guessing 
>> there’s currently no way to do this? I did some googling and I only found 
>> something like this for boost (compile-fail):
>> 
>> http://www.boost.org/build/doc/html/bbv2/builtins/testing.html 
>> 
>> 
>> Regards
>> José Manuel
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

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


Re: [swift-users] Compile time tests

2017-03-31 Thread Slava Pestov via swift-users
We have an undocumented -verify flag you can use for this. Here’s some code 
that doesn’t type check because the second call to g() is passing a type that 
does not conform to protocol P:

protocol P {}
protocol Q {}

struct R : P {}
struct S : Q {}

func g(_: T) {}

g(R())
g(S()) // expected-error{{does not conform}}

——

When you run this file through swiftc and pass the magic incarnation 
‘-typecheck -Xfrontend -verify’, the compiler exits with a code of 0 indicating 
success, because a diagnostic was produced on the line with the 
‘expected-error’ directive, and no other errors were produced:

Slavas-MBP:swift slava$ 
../build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc -typecheck 
-Xfrontend -verify generics.swift
Slavas-MBP:swift slava$ echo $?
0

You’ll need to come up with some way to wire the above up into your test 
harness, because as you correctly observed we never allow ill-typed code to 
*execute*.

It goes without saying that anything involving -Xfrontend is 
undocumented/unsupported/can change at any time. And of course the phrasing of 
the diagnostics can and will change too, which would also cause your test to 
fail. But we use this functionality extensively in our own test suite — it’s 
how we ensure that diagnostics don’t regress and invalid code is rejected in a 
clean way instead of crashing.

Slava

> On Mar 31, 2017, at 12:44 AM, José Manuel Sánchez via swift-users 
>  wrote:
> 
> I don’t know if this has come before (I tried searching but it’s not easy 
> with the mailing lists system); sorry in advance if that’s the case.
> 
> I’ve been using more generics lately, and I’ve come to a point where it would 
> be really nice to check if my types are correctly specified so that a wrong 
> combination isn’t possible because the compiler will not allow it. The 
> problem is, I can’t do this using unit testing, because if everything is 
> correct, the code won’t compile, and then the tests will fail. I’m guessing 
> there’s currently no way to do this? I did some googling and I only found 
> something like this for boost (compile-fail):
> 
> http://www.boost.org/build/doc/html/bbv2/builtins/testing.html 
> 
> 
> Regards
> José Manuel
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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


Re: [swift-users] Package Manager and iOS apps

2017-03-31 Thread Ankit Aggarwal via swift-users
Hi Tim,

You can read about plan for supporting iOS here

and
SwiftPM 4 roadmap here
.
You can write your package in a way that it can be used with SwiftPM,
CocoaPods and Carthage (depending on what all you want to support). This
allows using the package with SwiftPM for the command line application and
other dependency manager(s) for iOS application.

PS: Check out SwiftPlate  which
lets generates a template which can be used to support all dependency
managers. I haven't actually used it but it looks good!



On Thu, Mar 30, 2017 at 6:30 AM, Tim Dean via swift-users <
swift-users@swift.org> wrote:

> Hello Swift Users:
>
> Has the roadmap defined a timeframe for building iOS applications using
> the Swift Package Manager? I am working on a handful of modules that will
> be shared between a Mac command line utility app and a couple different iOS
> apps. I’d like to use SPM for building the shared code as individual
> modules, and then to define packages for the command line utility and each
> iOS application with dependencies on the shared code modules.
>
> All code will be Swift-only
>
> Is the SPM a good options or should I be sticking with CocoaPods or
> Carthage?
>
> Thanks
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


[swift-users] Compile time tests

2017-03-31 Thread José Manuel Sánchez via swift-users
I don’t know if this has come before (I tried searching but it’s not easy with 
the mailing lists system); sorry in advance if that’s the case.

I’ve been using more generics lately, and I’ve come to a point where it would 
be really nice to check if my types are correctly specified so that a wrong 
combination isn’t possible because the compiler will not allow it. The problem 
is, I can’t do this using unit testing, because if everything is correct, the 
code won’t compile, and then the tests will fail. I’m guessing there’s 
currently no way to do this? I did some googling and I only found something 
like this for boost (compile-fail):

http://www.boost.org/build/doc/html/bbv2/builtins/testing.html 


Regards
José Manuel___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users