You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Warnings are nice, but sometimes it's useful to disable them. Either because a new warning is issued and we prefer ignore it for the moment (e.g., false positives: #12150), or because we now the invariants of our program render the warning useless, or we prefer to tackle deprecations when they really become a problem...
However, currently we only have two choices: let warnings pollute the output of our build process, or let them fail, having to fix the program even when there's no need for a fix. What I propose is to add an annotation to eliminate such warnings.
In OCaml, for instance, you can suppress warnings using an attribute (akin to an annotation) (ref):
let [@warning "-8"] foo =functionSomex -> Printf.printf "I know there's something here"
If I remove [@warning "-8"], the compiler will warn me that the case None isn't handled.
Additionally, they can be removed for an entire build with a given flag in the compiler.
Proposal
In my proposal, I would associate a name for each warning (instead of a number):
It could take several warnings @[IgnoreWarnings("a", "b").
Implementation
Luckily, most of the ingredients are already there. For local-only warnings (like in the example above), we need to extend the definition of warnings_exclude to include the block of code and which warnings to suppress. For global ones, we need to replace warnings with a Set(String) instead of an enum.
The text was updated successfully, but these errors were encountered:
Feature Request
Warnings are nice, but sometimes it's useful to disable them. Either because a new warning is issued and we prefer ignore it for the moment (e.g., false positives: #12150), or because we now the invariants of our program render the warning useless, or we prefer to tackle deprecations when they really become a problem...
However, currently we only have two choices: let warnings pollute the output of our build process, or let them fail, having to fix the program even when there's no need for a fix. What I propose is to add an annotation to eliminate such warnings.
In OCaml, for instance, you can suppress warnings using an attribute (akin to an annotation) (ref):
If I remove
[@warning "-8"]
, the compiler will warn me that the caseNone
isn't handled.Additionally, they can be removed for an entire build with a given flag in the compiler.
Proposal
In my proposal, I would associate a name for each warning (instead of a number):
It could take several warnings
@[IgnoreWarnings("a", "b")
.Implementation
Luckily, most of the ingredients are already there. For local-only warnings (like in the example above), we need to extend the definition of warnings_exclude to include the block of code and which warnings to suppress. For global ones, we need to replace warnings with a
Set(String)
instead of an enum.The text was updated successfully, but these errors were encountered: