Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warning Waves #1580

Closed
4 tasks
gafter opened this issue Mar 25, 2015 · 19 comments
Closed
4 tasks

Warning Waves #1580

gafter opened this issue Mar 25, 2015 · 19 comments
Assignees
Labels
Area-Compilers Concept-Diagnostic Clarity The issues deals with the ease of understanding of errors and warnings. Feature Request Tenet-Compatibility Violation of forwards/backwards compatibility in a design-time piece.
Milestone

Comments

@gafter
Copy link
Member

gafter commented Mar 25, 2015

Over the course of its few years of development, the Roslyn compiler team implemented a handful of valuable new diagnostics for situations in user code that almost certainly indicate errors, and which would be very expensive to implement outside the compiler. One typical example was the comparison of a struct value against null

    void M(..., CancellationToken token)
    {
        if (token == null) { ... }
    }

The test token == null must always fail (a struct value, when boxed into an object, is never null). This almost certainly indicates an error in the user's program. And indeed, this diagnostic alerted us to dozens of real bugs in the Roslyn code base. Other new warnings similarly alerted us to other problems.

Since compiler warnings are enabled by default, any project that upgrades to the new version of the compiler may be "broken" (e.g. if configured to treat warnings as errors) by the presence of newly implemented diagnostics at a time when changing the code or the build infrastructure is inconvenient. Due to this concern previous releases of the compiler have avoided adding diagnostics for existing code scenarios. We wanted to allow Roslyn, it its first release and in subsequent releases, to add value by adding additional warnings for likely code problems that are difficult to detect outside the compiler. But how could we do it without breaking compatibility?

A few years ago we considered adding the concept of "warning waves" to the compilers. The compiler would know in which compiler version support for each warning was added. The compiler command-line would specify a version for which warnings to allow; the compiler would then report only warnings that were implemented up until the specified "warning version". We held meetings and produced a detailed design.

Two years ago we dropped the idea of adding a specific "warning waves" flag to the compiler because we "realized" that the new mechanisms to control the diagnostics (such as ruleset files) are fine-grained enough to provide the same value.

Unfortunately we did not complete the work to address the scenario. Consequently all of the new warnings implemented in Roslyn have since been removed from the compilers due to compatibility concerns.

It is time for us to revisit the issue, to design and implement a solution that addresses the original problem. Users should be able to specify a version of the compiler that represents the set of warnings they are willing to have reported.

LDM notes:

@gafter
Copy link
Member Author

gafter commented Mar 25, 2015

@gafter gafter added Feature Request Tenet-Compatibility Violation of forwards/backwards compatibility in a design-time piece. Concept-Diagnostic Clarity The issues deals with the ease of understanding of errors and warnings. labels Mar 25, 2015
@jaredpar jaredpar modified the milestones: 2.0, 1.1 Jul 31, 2015
@AnthonyDGreen
Copy link
Contributor

We discussed this offline to come up with what we feel is a sensible design and some principles for this feature:

Definitions

  • A wave is defined to be a set of new diagnostic IDs and/or new circumstances for reporting existing diagnostics. i.e. either introducing a brand new warning or correctly reporting an existing warning in a new case that we hadn't reported it before due to a bug would be gated by this feature.

Principles

  • Warning waves are not intended to be a general mechanism that applies equally to Analyzers; this is a non-goal. Analyzers have NuGet semantic versioning as their primary vehicle for controlling the introduction of new warnings.
  • Warning waves must be decoupled from language versions; customers must be able to opt into the goodness of new language features without also forcing upon themselves the pain of new diagnostics.

Design

  • There shall be a flag which can be passed to the compiler which will enable any warnings introduced up to a specified warn-version or wave.
  • The flag shall have the syntax /warnversion:
    • This flag may control errors as well but given that the vast majority of cases will be warnings it makes more sense to call it /warnversion rather than /warnorerrorversion or /diagnosticversion.
  • The format of the version string shall match what /langversion accepts—the minor version will be incremented with each update, e.g. 6.1/14.1.
  • The default in the absence of this flag shall be the latest wave.
  • MSBuild will pass the value in the project file if specified; otherwise it will pass version 6/14 to maintain back compat for existing customers.
  • There should be a NOSEATBELTS option that explicitly opts into the latest wave.

@svick
Copy link
Contributor

svick commented Sep 14, 2015

@AnthonyDGreen Since project.json is already used to version analyzers and the framework (at least for some project types), could it make sense to also use it to version the compiler and warning waves?

@gafter
Copy link
Member Author

gafter commented Sep 15, 2015

Should that be ALLSEATBELTS 😉 ?

@alrz
Copy link
Member

alrz commented Sep 9, 2018

Consider: object[] o = new C[]{}, unconditional recursive methods or explicit values for caller info params.

Should they be included in warning waves vs IDE analyzers? and why? In other words, how a warning is decided to be a part of warning waves?

btw do we have a list of considered warnings here?

which would be very expensive to implement outside the compiler

(edit) That'd be the answer to the first question but I'd like to know if there's more to it.

@jcouv
Copy link
Member

jcouv commented Sep 9, 2018

@alrz Issues marked with the "warning waves" labels are the candidates.
LDM still needs to triage them and set some guidance for what issues should qualify for warning waves. This will likely happen in the next couple weeks.

@jcouv jcouv modified the milestones: 16.0, 16.1.P1 Jan 6, 2019
@gafter gafter modified the milestones: 16.1.P1, 16.0 Jan 22, 2019
@gafter gafter modified the milestones: 16.0, 16.1 Feb 26, 2019
@jcouv jcouv modified the milestones: 16.1, 16.2 Apr 23, 2019
@gafter gafter modified the milestones: 16.2, 16.3 Jun 3, 2019
@jcouv
Copy link
Member

jcouv commented Jul 8, 2019

Moving warning waves post 8.0 RTM.

@jcouv jcouv modified the milestones: 16.3, Compiler.Next Jul 8, 2019
@gafter gafter modified the milestones: Compiler.Next, 16.8 Jul 2, 2020
@gafter
Copy link
Member Author

gafter commented Jul 6, 2020

This issue is replaced by #45701

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Concept-Diagnostic Clarity The issues deals with the ease of understanding of errors and warnings. Feature Request Tenet-Compatibility Violation of forwards/backwards compatibility in a design-time piece.
Projects
Archived in project
Development

No branches or pull requests