microsoft / TypeScript Public
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
Deprecated as warning #40607
Deprecated as warning #40607
Conversation
|
Perfect. Thank you! |
|
/cc @amcasey - I think we've talked about warnings before, and I'm not certain about how that affects VS |
|
@orta VS has no problem with warnings. I think the bigger issue is that we've repeatedly discussed giving some diagnostics warning severity and decided against it. I cannot, unfortunately, recall our most recent line of reasoning. @DanielRosenwasser? |
src/compiler/diagnosticMessages.json
Outdated
| @@ -4729,6 +4729,10 @@ | |||
| "category": "Message", | |||
| "code": 6800 | |||
| }, | |||
| "Issue an warning if declaration is deprecated": { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: should be "Issue a warning if the declaration is deprecated"
I don't like this change as-is since it adds a flag, but maybe it's time we had the warnings/errors/suggestions discussion again.
(Perhaps) notably, this particular bug is a non-issue in emacs since it shows suggestions in the error list. VS may be similar?
src/compiler/checker.ts
Outdated
| function wraningOrSuggestion(isWraning: boolean, location: Node, message: DiagnosticMessage | DiagnosticMessageChain, arg0?: string | number, arg1?: string | number, arg2?: string | number, arg3?: string | number): void { | ||
| const category = isWraning ? DiagnosticCategory.Warning : DiagnosticCategory.Suggestion; | ||
| addErrorOrWarningOrSuggestion(category, "message" in message ? createDiagnosticForNode(location, message, arg0, arg1, arg2, arg3) : createDiagnosticForNodeFromMessageChain(location, message)); // eslint-disable-line no-in-operator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| function wraningOrSuggestion(isWraning: boolean, location: Node, message: DiagnosticMessage | DiagnosticMessageChain, arg0?: string | number, arg1?: string | number, arg2?: string | number, arg3?: string | number): void { | |
| const category = isWraning ? DiagnosticCategory.Warning : DiagnosticCategory.Suggestion; | |
| addErrorOrWarningOrSuggestion(category, "message" in message ? createDiagnosticForNode(location, message, arg0, arg1, arg2, arg3) : createDiagnosticForNodeFromMessageChain(location, message)); // eslint-disable-line no-in-operator | |
| function warningOrSuggestion(isWarning: boolean, location: Node, message: DiagnosticMessage | DiagnosticMessageChain, arg0?: string | number, arg1?: string | number, arg2?: string | number, arg3?: string | number): void { | |
| const category = isWarning ? DiagnosticCategory.Warning : DiagnosticCategory.Suggestion; | |
| addErrorOrWarningOrSuggestion(category, "message" in message ? createDiagnosticForNode(location, message, arg0, arg1, arg2, arg3) : createDiagnosticForNodeFromMessageChain(location, message)); // eslint-disable-line no-in-operator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sandersn VS Code does not include suggestion level diagnostics in the problems view, only errors, warnings, and information messages
|
This should definitely follow unused locals scenario and be error instead of warning as we have stayed away from warning so far and matches what we do for unused locals |
|
Adding one last comment... As an everyday developer, I really don't care if these deprecations are considered errors or warnings. As long as they get listed in the Problems tab in VSCode, so we don't have to visually scan over every source file looking through strikethroughs or perform manual searches on deprecations we know to search on, that would be ideal. If controversary over how those are presented can be avoided by having a multi-state VSCode setting (List deprecations in Problems tab: Ignore, Error, Warning), then great -- everyone's happy. The main goal should be to provide a convenient list of alerts we can identify in a project and attack efficiently. Thanks. |
src/compiler/checker.ts
Outdated
| @@ -1084,12 +1084,13 @@ namespace ts { | |||
|
|
|||
| function addErrorOrSuggestion(isError: boolean, diagnostic: DiagnosticWithLocation) { | |||
| if (isError) { | |||
| diagnostics.add(diagnostic); | |||
| diagnostics.add({ ...diagnostic, category: DiagnosticCategory.Error }); | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of this you need to mark the actual error as error by default
The code looks good now, but I still have two issues:
- Does making this an error get rid of the strikethrough annotations in Code?
- If non-Code editors (emacs and VS, at least) can show suggestions in a list, then it seems like the correct fix is there, rather than in Typescript. Especially since listing suggestions would be a generally useful feature -- not just for deprecated things.
|
For 1. errorOrSuggestions has rerwrite the type as suggestion. And in the tests it's also suggestion. So i think it's ok. |
|
For 2. Is that means It's should be handle in code too? CC: @mjbvz |
| @@ -40,6 +40,7 @@ | |||
| // "noImplicitReturns": true, /* Report error when not all code paths in function return a value. */ | |||
| // "noFallthroughCasesInSwitch": true, /* Report errors for fallthrough cases in switch statement. */ | |||
| // "noUncheckedIndexedAccess": true, /* Include 'undefined' in index signature results */ | |||
| // "noDeprecated": true, /* Issue a error if declaration is deprecated */ | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency with the other comments, consider something like "Report error when referencing deprecated declaration".
|
I can't really tell how much demand there is for an error when referring to a deprecated symbol. Is there an upvoted issue or something? |
This looks good to me apart from @amcasey suggestion about the text of the option
|
I moved #40604 to TypeScript to track having tsc generate warnings for deprecated symbol usage. On the VS Code side, we can fairly easily change the level of deprecated diagnostics, taking them from |
|
The TypeScript team hasn't accepted the linked issue #40604. If you can get it accepted, this PR will have a better chance of being reviewed. |
|
Up |
|
After thinking about this again, I dislike it more. I'd much rather see editors handle suggestions as suggestions, and perhaps have |
|
Okay, Never mind. |


Fixes #40604
IMO. That should not an error but an warning because it's just suggestions.
The text was updated successfully, but these errors were encountered: