[swift-dev] Categorization of warnings in Swift

[Michael Ilseman]

> On Jan 20, 2016, at 11:23 AM, Michael Ilseman via swift-dev <swift-dev at swift.org> wrote:
> 
>> On Jan 19, 2016, at 10:21 PM, Ted kremenek <kremenek at apple.com <mailto:kremenek at apple.com>> wrote:
>> 
>> 
>> 
>>> On Jan 13, 2016, at 4:51 PM, Michael Ilseman via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>> As far as front-end options, any preferences on the command-line switches? I don’t see a need to keep consistency with GCC/Clang here, so perhaps “-suppress-warnings” and “-warnings-as-errors”?
>> 
>> There may not be a need for consistency, but there may be value in being consistent.
>> 
>> If you go with a cohesive model where there are warning categories and separate categories can be enabled, disabled, promoted to errors, etc., then there are merits to GCC/Clang's warning style that I don't think should just be dismissed out of hand.  Deviating can provide negative value because it a different scheme that is, well, just different, but conceptually similar to something many developers already know.
>> 
> 
> That’s a very good point. If we want to offer individual or categorical control in the future, we should design something consistent.
> 
>> Before dismissing -Werror and -w, consider the taxonomy that they are a part of in the GCC/Clang world:
>> 
>>  -Werror-<warning>
>>  -Wno-error-<warning>
>>  -Wno-<warning>
>> 
>> This is a very general scheme for controlling warnings.  Perhaps "-w" and "-Werror" are a bit special case, so you could always do something like:
>> 
>>  -Wno-all
>>  -Werror-all
>> 
>> And just have a warning category for "all warnings".
>> 
>> If you are going to go down the route of having any control for warnings from the command line --- which I realize is a contentious topic on this thread --- I personally believe that the flags should be simple, consistent, and generalized.  Having special case flags like "-suppress-warnings" and "-warnings-as-errors" feels more even more special case, and I just have to know what they are.
>> 
>> I'm not married to the -W flags scheme, but it is something that is understood.  If we are going to have flags, I'd prefer something that was equally (or more) understandable with a general and simple scheme for controlling warnings.
> 
> I don’t mind any particulars, just so long as it’s something reasonable and consistent, and provides a user story that is not too confusing. The -Wno-error-<warning> flags does seem confusing, in that it presupposes that a prior flag ended up treating it as an error, while it might actually be off-by-default. I would think that there are 5 potential states a diagnostic/category can be in WRT user control: “unspecified”, “default”, “error”, “explicitly on”, “explicitly off”. (Perhaps “unspecified” and “default” can be folded in together, but we might want to expose explicitly setting as default to the user).
> 

To get the ball rolling towards getting a consistent set of flags soon, here’s a proposal (the details of which I’m not particularly attached to):

-Werror=<warning/all/category/...>
-Wenable=<warning/all/category/...>
-Wdisable=<warning/all/category/...>
-Wdefault=<warning/all/category/...>

And, we add support for “all” while we figure out what we want to do for everything else. I could also consider “-Won=” and “-Woff=“ for brevity, though perhaps at the cost of some clarity. Similarly for any command-line aliases to ease brevity, e.g. “-W<warning>” expands to “-Wenable=<warning>”, etc.



> Rather than rely on order on command line, I’d rather have a very consistent order of precedence that fits intuition. See below for my proposed order of precedence.
> 
> The main things I’m trying to avoid in all this is:
> Complicating compiler maintenance without sufficient benefit
> Complicating the user story
> Painting ourselves into a compatibility corner
> Categorization merely as an exercise (taxonomy without use case)
>> 
>> Perhaps I'm the outlier here, but I personally think that "warning flags result in style dialects" is not an anathema.  There is some code where stylistic enforcements need to be stricter for a variety of reasons.  While I think we should aim for a common set of warnings that are enabled to establish good hygiene in Swift code, I do think there will be cases where more warnings/errors are desired beyond what the core language defines.
>> 
>> I agree we don't need to eagerly classify warnings, but I'd also like to understand your criteria for why -W flags are bad thing in general and what you'd prefer to see as a better direction.  I certainly don't see it that way.  My fear is that if we are overly conservative about not having precise control over warnings is that we may hold back on adding useful warnings to the compiler because they will not be appropriate for everyone.
>> 
>> I also don't see #if as a solution for warning control, as you indicated in another message, as I see legitimate cases where more aggressive warnings may be desirable to enable in certain contexts.  There is also Chris's comments about other contents, like Playgrounds, where some pedantic warnings that may be on by default provide less value.
> 
> I would propose the following precedence, which matches basic intuition:
> Individual control
> Use case control
> Categorical control
> Global control
> E.g. If someone bothered to single out a warning, that should take precedence over others. If there’s a conflict at a precedence level, we error.
> 
> By “use case” control, for lack of a better name off the top of my head (please suggest one!), I mean situations in which diagnostics are not grouped by kind or any other logical grouping. Rather, they appear together in situations that commonly might want to be controlled. These are often diagnostics which would be cross-cutting of any hierarchical categorization by kind. Some examples:
> Warnings about features that are currently in transition, which many users don’t want to see if they want to be able to compile warning-free on multiple compiler minor versions. 
> Opting into extra-stringent stylistic warnings that we wouldn’t normally want to thrust upon normal users (but, not style dialects, just a spectrum of stringency).
> The kinds of diagnostics that users like Playgrounds just shouldn’t care about, e.g. unused definitions.
> The aim being that there’s a specific user or use-case in mind when defining one, as opposed to having them as an organizational grouping. I don’t feel like these would naturally tend to have much, if any, overlap with each other and perhaps we can treat them as non-overlapping. They may, of course, crosscut categories, should we ever decide to implement categories.
> 
> Clang’s categories are sometimes “use case” here, e.g. “c++98-compat”, but often are categorical, e.g. "duplicate-decl-specifier”. I think that for the current state of Swift and Swift for the near future, it makes sense to tackle “use case” soon and categorical later if at all. I feel like the more categorical approach is also more likely to be a source of stylistic dialect splitting and of limited value to the user. Power users can use individual control.
> 
> I’d prefer to tackle unique-identifiers before tackling individual control, to help with maintenance and not face a compatibility problem. If this is seems very valuable to Swift, we can also pursue automatic and hyperlinked documentation produced from the diagnostic definitions, etc.
> 
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160121/4095ccbd/attachment.html>