<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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:<div class=""><br class=""></div><div class="">protocol P {}<br class="">protocol Q {}<br class=""><br class="">struct R : P {}<br class="">struct S : Q {}<br class=""><br class="">func g<T : P>(_: T) {}<br class=""><br class="">g(R())<br class="">g(S()) // expected-error{{does not conform}}<div class=""><br class=""></div><div class="">——</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">Slavas-MBP:swift slava$ ../build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc -typecheck -Xfrontend -verify generics.swift<br class="">Slavas-MBP:swift slava$ echo $?<br class="">0</div><div class=""><br class=""></div><div class="">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*.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 31, 2017, at 12:44 AM, José Manuel Sánchez via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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):</div><div class=""><br class=""></div><div class=""><a href="http://www.boost.org/build/doc/html/bbv2/builtins/testing.html" class="">http://www.boost.org/build/doc/html/bbv2/builtins/testing.html</a></div><div class=""><br class=""></div><div class="">Regards</div><div class="">José Manuel</div></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></blockquote></div><br class=""></div></div></body></html>