[swift-dev] Categorization of warnings in Swift

Dmitri Gribenko gribozavr at gmail.com
Tue Jan 19 00:42:25 CST 2016

On Mon, Jan 18, 2016 at 10:34 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jan 12, 2016, at 1:24 PM, Dmitri Gribenko via swift-dev
> <swift-dev at swift.org> wrote:
>>         "%select{variable|constant}2 %0 inferred to have type %1, "
>>         "which may be unexpected"
>>     no_throw_in_try
>>         "no calls to throwing functions occur within 'try' expression"
>>     no_throw_in_do_with_catch
>>         "'catch' block is unreachable because no errors are thrown in 'do'
>> block"
> It seems like some of these can be too pedantic in cross-platform code bases
> because of #if's that are not analyzable and might need more granular
> suppression mechanisms.   For example:
> func foo() throws {}
> func bar() {}
> func baz() {
>   do {
> #if os(OSX)
>     try foo()
> #else
>     bar()
> #endif
>     // common code.
>   } catch { // on non-OS X, warning: 'catch' block is unreachable because no
> errors are thrown in 'do' block
>     // ...
>   }
> }
> I definitely remember we had some similar issues in the standard library or
> tests, but don't remember the specifics.
> FWIW, one of the reasons we build an AST for disabled #if regions is so we
> can be smart about this sort of thing.  The fact that we don’t for this
> warning is a bug in the warning, not something we should use warning
> suppression to fix.

Yes, I understand that -- the fix is very simple, we just need to find
a 'try' in disabled code.  My point is though, currently we are not
implementing this (nor fixing other false positives), and we are
producing warnings that developers in
the field can't do anything about, even as a workaround for the broken
compiler.  Another point is that especially with dataflow-based
warnings there will be edge cases that will be impractical to fix.

I think it is important to give developers in the field a tool to mark
false positives (either on a category, or a per-warning level), to
work around an imperfect compiler.  I totally agree that we should try
to fix the compiler, but engineers working with the today's imperfect
compiler need a tool to be effective with what they can use.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-dev mailing list