[swift-dev] Categorization of warnings in Swift
clattner at apple.com
Tue Jan 19 01:06:37 CST 2016
On Jan 18, 2016, at 10:42 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> 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),
Uh, yes, we are fixing these things. I could find zero reports complaining about this in either radar or Jira, which is why I didn’t know that this was an issue affecting people.
I fixed this in 2f5af05, if you know of other similar issues, please let me know.
> and we are producing warnings that developers in
> the field can't do anything about, even as a workaround for the broken
I would rather that we fix the broken compiler. We do care about QoI in fact.
> Another point is that especially with dataflow-based
> warnings there will be edge cases that will be impractical to fix.
Please provide some specific details here. The design of our dataflow warnings is specifically intended to make sure they are actionable and do not have false positives that cannot be solved in a reasonable way.
> 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.
Despite my pushback, I agree with you that local control over warnings is a useful thing to have. However, I don’t find the argument of “the compiler generates bogus warnings sometimes and users should silence them instead of having us fix the compiler” to be the right motivator.
More information about the swift-dev