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

Suppress no implicit any errors #1418

Merged
merged 5 commits into from
Dec 11, 2014
Merged

Conversation

mhegazy
Copy link
Contributor

@mhegazy mhegazy commented Dec 9, 2014

…e of thier type e.g. File, Version, etc.., that was changed in the defintion to paramName, without changing the use site, changing it back to paramType.
@danquirk
Copy link
Member

danquirk commented Dec 9, 2014

Why does --suppress take specific terms we have to define rather than a list of error codes?

@mhegazy
Copy link
Contributor Author

mhegazy commented Dec 9, 2014

Looking at a build file, with --suppress 7052 says absolutely nothing. specially that these error numbers are not documented anywhere. basically your best bet is cracking open the compiler source and searching fro "7052" to know what the author of the build file intended.

Allowing only specific set of checks to emit, allows us to optimize the process by not querying for the errors if the user is not interested in them, instead of filtering a list after the fact.

It also limits the usage matrix by designating a specific set of errors to suppress.

In general error codes are just hard to remember, hard to maintain, and really no one wants to do unless they have to. At the essence of this issue, what users want is just disabling a specific check. a human readable name seems much suited to this end. Even in the original issue, @johnnyreilly asks for explicit names.

@danquirk
Copy link
Member

I don't really buy all of these arguments. I would prefer if users still had the ability to provide error codes in addition to blessed names (which is ultimately what was requested in those threads) but if we want to consider doing that later if/when it's asked for then we can go that route.

I don't think we need to throw out the generalized form (error codes) in order to provide human readable ones. I totally get that users don't want to deal with error codes unless they have to, but this blocks the 'unless they have to' case. By only supporting blessed names we're feeling like we're only adding 1 new compiler flag but it's essentially the same as adding N new ones where N is the number of blessed names.

@mhegazy
Copy link
Contributor Author

mhegazy commented Dec 10, 2014

By only supporting blessed names we're feeling like we're only adding 1 new compiler flag but it's essentially the same as adding N new ones where N is the number of blessed names.

That is pretty much the intent. in the future if we need to suppress another error X, instead of adding a new --suppressX, we will use --suppress X. the benifit here is you do not have --suppresX --suppressY --suppressZ, instead --suppress X,Y,Z,

@@ -1643,6 +1643,10 @@
"category": "Error",
"code": 6054
},
"Suppress noImplicitAny errors for indexing into objects lacking index signatures.": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would might be better as "Suppress noImplicitAny errors for indexing objects lacking index signatures."

@DanielRosenwasser
Copy link
Member

LGTM 👍

mhegazy added a commit that referenced this pull request Dec 11, 2014
@mhegazy mhegazy merged commit b4082ce into release-1.4 Dec 11, 2014
@mhegazy mhegazy deleted the suppressNoImplicitAnyErrors branch December 11, 2014 02:46
@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants