<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 12, 2016 at 9:44 AM, Michael Ilseman via swift-dev <span dir="ltr"><<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hello, I'm interested in enabling finer-grained control over warning/error</div><div>reporting ala Clang. I've started to put in some infrastructure to</div><div>DiagnosticEngine, and now I'm at the point of determining categorization. </div><div><br></div><div>I'd like some input (and maybe even some bikeshedding!) on the community's</div><div>thoughts and preferences here. Here's my take on the issue:</div><div><br></div><div>When it comes to defining the categorization, I can see a few approaches: </div><div><ol><li> Categorize based on broad language-feature/compiler-area. E.g. "Availability" or “CommandLineArguments”</li><li> Categorize based on the kind of warning. E.g. "Deprecated" or “Uninitialized"</li><li> Categorize based on severity or specificity of warnings. E.g. "Pedantic" or "UnusedValue" or "NullDereference"</li></ol></div><div><br></div><div>And, of course, I think that preference should be given to how people would</div><div>actively like to use the categories to control warnings. For example, there's</div><div>a handful of warnings that makes less sense in a REPL or rapid experimentation</div><div>environment, such as variable_never_mutated.</div></div></blockquote><div><br></div><div>Since we try to keep warnings on-by-default, the primary usecase will probably be disabling warnings that are somehow inappropriate for the project.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Here's a straw-man proposal of some categorization. Of course, one developer's</div><div>annoying pedantic warning is another's life-saving code-smell detector. I am not</div><div>personally tied to these categorizations at all, I'm just interested in there</div><div>being something simple and basic. Below is a list of every warning in Swift with</div><div>an attempt to put it under a category.</div><div><br></div><div><br></div><div>Deprecated:</div><div> var_not_allowed_in_pattern</div><div> "Use of '%select{var|let}0' binding here is deprecated and will be "</div><div> "removed in a future version of Swift"</div><div> deprecated_c_style_for_stmt</div><div> "C-style for statement is deprecated and will be removed in a future "</div><div> "version of Swift"</div><div> deprecated_convention_attribute</div><div> "'@%0' attribute is deprecated; '@convention(%1)' should be used "</div><div> "instead"</div><div> availability_deprecated</div><div> "%0 %select{is|%select{is|was}3}1 deprecated"</div><div> "%select{| %select{on|in}3 %2%select{| %4}3}1"</div><div> availability_deprecated_msg</div><div> "%0 %select{is|%select{is|was}3}1 deprecated"</div><div> "%select{| %select{on|in}3 %2%select{| %4}3}1: %5"</div><div> availability_deprecated_rename</div><div> "%0 %select{is|%select{is|was}3}1 deprecated"</div><div> "%select{| %select{on|in}3 %2%select{| %4}3}1: renamed to '%5'"</div><div> parameter_curry_syntax_removed</div><div> "curried function declaration syntax will be removed in a future "</div><div> "version of Swift; use a single parameter list"</div></div></blockquote><div><br></div><div>I think there should be separate categories for deprecated language features and deprecated APIs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Unsupported:</div><div> warning_parallel_execution_not_supported</div><div> "parallel execution not supported; falling back to serial execution"</div><div> unsupported_synthesize_init_variadic</div><div> "synthesizing a variadic inherited initializer for subclass %0 is "</div><div> "unsupported"</div><div><br></div><div><br></div><div>Stylistic/Pedantic/Cleanliness:</div><div> pbd_never_used_stmtcond</div><div> "value %0 was defined but never used; consider replacing "</div><div> "with boolean test"</div><div> pbd_never_used</div><div> "initialization of %select{variable|immutable value}1 %0 was never used"</div><div> "; consider replacing with assignment to '_' or removing it"</div><div> capture_never_used</div><div> "capture %0 was never used",</div><div> variable_never_used</div><div> "%select{variable|immutable value}1 %0 was never used; "</div><div> "consider replacing with '_' or removing it"</div><div> variable_never_mutated</div><div> "%select{variable|parameter}1 %0 was never mutated; "</div><div> "consider changing to 'let' constant"</div><div> variable_never_read</div><div> "%select{variable|parameter}1 %0 was written to, but never read"</div><div> expression_unused_result</div><div> "result of call to %0 is unused"</div><div> expression_unused_init_result</div><div> "result of initializer is unused", ())</div><div> expression_unused_result_message</div><div> "result of call to %0 is unused: %1"</div><div> expression_unused_result_nonmutating</div><div> "result of call to non-mutating function %0 is unused; "</div><div> "use %1 to mutate in-place"</div><div> expression_unused_optional_try</div><div> "result of 'try?' is unused"</div><div> non_trailing_closure_before_default_args</div><div> "closure parameter prior to parameters with default arguments will "</div><div> "not be treated as a trailing closure"</div><div> parameter_extraneous_double_up</div><div> "extraneous duplicate parameter name; %0 already has an argument "</div><div> "label"</div><div> parameter_extraneous_empty_name</div><div> "extraneous '_' in parameter: %0 has no keyword argument name"</div><div> escaped_parameter_name</div><div> "keyword '%0' does not need to be escaped in argument list"</div><div><br></div><div><br></div><div>CodeSmell/StrongStylisticHints:</div><div> guard_always_succeeds</div><div> "'guard' condition is always true, body is unreachable"</div><div> warn_unqualified_access</div><div> "use of %0 treated as a reference to %1 in %2 %3"</div><div> var_pattern_didnt_bind_variables</div><div> "'%0' pattern has no effect; sub-pattern didn't bind any variables"</div><div> type_inferred_to_undesirable_type</div><div> "%select{variable|constant}2 %0 inferred to have type %1, "</div><div> "which may be unexpected"</div><div> no_throw_in_try</div><div> "no calls to throwing functions occur within 'try' expression"</div><div> no_throw_in_do_with_catch</div><div> "'catch' block is unreachable because no errors are thrown in 'do' block"</div></div></blockquote><div><br></div><div>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:</div><div><br></div><div><div>func foo() throws {}</div><div>func bar() {}</div><div><br></div><div>func baz() {</div><div> do {</div><div>#if os(OSX)</div><div> try foo()</div><div>#else</div><div> bar()</div><div>#endif</div><div> // common code.</div><div> } catch { // on non-OS X, warning: 'catch' block is unreachable because no errors are thrown in 'do' block</div><div> // ...</div><div> }</div><div>}</div></div><div><br></div><div>I definitely remember we had some similar issues in the standard library or tests, but don't remember the specifics.</div><div><br></div><div>Dmitri</div></div><div><br></div>-- <br><div class="gmail_signature">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/</div>
</div></div>