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

Deprecated as warning #40607

Closed
wants to merge 28 commits into from
Closed

Deprecated as warning #40607

wants to merge 28 commits into from

Conversation

@Kingwl
Copy link
Contributor

@Kingwl Kingwl commented Sep 17, 2020

Fixes #40604

IMO. That should not an error but an warning because it's just suggestions.

image

@Kingwl Kingwl changed the title wip Deprecated as warning Sep 17, 2020
@Kingwl Kingwl marked this pull request as draft Sep 17, 2020
@Kingwl Kingwl marked this pull request as ready for review Sep 17, 2020
@morganwdavis
Copy link

@morganwdavis morganwdavis commented Sep 17, 2020

Perfect. Thank you!

Loading

@orta
Copy link
Member

@orta orta commented Sep 17, 2020

/cc @amcasey - I think we've talked about warnings before, and I'm not certain about how that affects VS

Loading

@amcasey
Copy link
Member

@amcasey amcasey commented Sep 17, 2020

@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?

Loading

@@ -4729,6 +4729,10 @@
"category": "Message",
"code": 6800
},
"Issue an warning if declaration is deprecated": {

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"

Loading

@sandersn sandersn added this to Not started in PR Backlog Sep 29, 2020
Copy link
Member

@sandersn sandersn left a comment

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?

Loading

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
Copy link
Member

@sandersn sandersn Sep 30, 2020

Choose a reason for hiding this comment

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

Suggested change
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

Loading

Copy link
Contributor

@mjbvz mjbvz Oct 12, 2020

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

Loading

PR Backlog automation moved this from Not started to Waiting on author Sep 30, 2020
@sandersn
Copy link
Member

@sandersn sandersn commented Sep 30, 2020

image

Loading

@sheetalkamat
Copy link
Member

@sheetalkamat sheetalkamat commented Sep 30, 2020

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

Loading

@morganwdavis
Copy link

@morganwdavis morganwdavis commented Oct 1, 2020

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.

Loading

@morganwdavis
Copy link

@morganwdavis morganwdavis commented Oct 2, 2020

Maybe flagging deprecations in VSCode as "Infos" is the solution? Notice how the Code Spelling Checker extension does it:

image

This gets the job done nicely and isolates these from warnings and errors.

Loading

@@ -1084,12 +1084,13 @@ namespace ts {

function addErrorOrSuggestion(isError: boolean, diagnostic: DiagnosticWithLocation) {
if (isError) {
diagnostics.add(diagnostic);
diagnostics.add({ ...diagnostic, category: DiagnosticCategory.Error });
Copy link
Member

@sheetalkamat sheetalkamat Oct 10, 2020

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

Loading

@Kingwl Kingwl requested review from sandersn and sheetalkamat Oct 10, 2020
Copy link
Member

@sandersn sandersn left a comment

The code looks good now, but I still have two issues:

  1. Does making this an error get rid of the strikethrough annotations in Code?
  2. 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.

Loading

@Kingwl
Copy link
Contributor Author

@Kingwl Kingwl commented Oct 12, 2020

For 1. errorOrSuggestions has rerwrite the type as suggestion. And in the tests it's also suggestion. So i think it's ok.

Loading

@Kingwl
Copy link
Contributor Author

@Kingwl Kingwl commented Oct 12, 2020

For 2. Is that means It's should be handle in code too? CC: @mjbvz

Loading

@@ -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 */
Copy link
Member

@amcasey amcasey Oct 12, 2020

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".

Loading

@amcasey
Copy link
Member

@amcasey amcasey commented Oct 12, 2020

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?

Loading

Copy link
Member

@sheetalkamat sheetalkamat left a comment

This looks good to me apart from @amcasey suggestion about the text of the option

Loading

@mjbvz
Copy link
Contributor

@mjbvz mjbvz commented Oct 12, 2020

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 suggestion to warning, without this PR. However I like the PR's proposed noDeprecated flag which I presume would control both editor errors and tsc errors

Loading

@sandersn sandersn self-assigned this Oct 27, 2020
@typescript-bot
Copy link
Collaborator

@typescript-bot typescript-bot commented Dec 31, 2020

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.

Loading

@Kingwl
Copy link
Contributor Author

@Kingwl Kingwl commented Dec 31, 2020

Up

Loading

@sandersn
Copy link
Member

@sandersn sandersn commented Mar 11, 2021

After thinking about this again, I dislike it more. I'd much rather see editors handle suggestions as suggestions, and perhaps have tsc add a flag to emit suggestions alonside errors.

Loading

@Kingwl
Copy link
Contributor Author

@Kingwl Kingwl commented Mar 11, 2021

Okay, Never mind.

Loading

@Kingwl Kingwl closed this Mar 11, 2021
PR Backlog automation moved this from Waiting on author to Done Mar 11, 2021
@Kingwl Kingwl deleted the wran_deprecated branch Mar 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
PR Backlog
  
Done
Linked issues

Successfully merging this pull request may close these issues.

9 participants