Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

Fix build #3853

Merged
merged 6 commits into from
Apr 26, 2018
Merged

Fix build #3853

merged 6 commits into from
Apr 26, 2018

Conversation

suchanlee
Copy link
Contributor

@suchanlee suchanlee commented Apr 25, 2018

PR checklist

Overview of change:

  • Fixes tests that broke due to compiler changes in TS 2.8
  • Quite a few changes in the logic for no-unused-variables rule due to changes (kind, count, text range) in what the compiler outputs for preEmitDiagnostics

Is there anything you'd like reviewers to focus on?

CHANGELOG.md entry:

Suchan Lee added 2 commits April 25, 2018 01:35
…e for TS2.8 support

Logic had to be modified because starting from TS2.8, when all imports in an import node are not used,
TS emits only 1 diagnostic object for the whole line as opposed to the previous behavior of outputting
a diagnostic with kind == 6192 (UnusedKind.VARIABLE_OR_PARAMETER) for every unused import.
@@ -337,12 +339,14 @@ function forEachImport<T>(sourceFile: ts.SourceFile, f: (i: ImportLike) => T | u
});
}

function findImport(pos: number, sourceFile: ts.SourceFile): ts.Identifier | undefined {
function findImports(pos: number, sourceFile: ts.SourceFile, kind: UnusedKind): ReadonlyArray<ts.Identifier> {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

changing to an array since in the case of kind === DECLARATION we want to return all the imports in the node

}
if (kind === UnusedKind.VARIABLE_OR_PARAMETER || kind === UnusedKind.DECLARATION) {
const importNames = findImports(diag.start, sourceFile, kind);
if (importNames.length > 0) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

logic changes to handle the array return type

@@ -66,7 +66,11 @@ export class DestructuringTests {
}

abstract class AbstractTest {
#if typescript >= 2.8.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~ [err % ('AbstractTest')]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

changes in compiler generated ranges

@@ -2,7 +2,11 @@
const fs = require("fs");

module Foo {
~~~ [err % ('Foo')]
#if typescript >= 2.8.0
Copy link
Contributor Author

Choose a reason for hiding this comment

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

changes in compiler generated ranges

//
};

function func3() {
~~~~~ [err % ('func3')]
#if typescript >= 2.8.0
Copy link
Contributor Author

Choose a reason for hiding this comment

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

changes in compiler generated ranges

@@ -42,7 +42,11 @@ $(_.xyz());
/// <reference path="../externalFormatter.test.ts" />

module S {
#if typescript >= 2.8.0
Copy link
Contributor Author

Choose a reason for hiding this comment

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

changes in compiler generated ranges

@suchanlee
Copy link
Contributor Author

Added builds for TS 2.7 and 2.8

@suchanlee suchanlee requested a review from jkillian April 25, 2018 17:59
@suchanlee
Copy link
Contributor Author

@JoshuaKGoldberg can you take a look at this?

@@ -12,8 +12,15 @@ var z;

export var abcd = 3;

// Could be a bug with 2.9-dev but getPreEmitDiagnostics isn't
Copy link
Contributor

Choose a reason for hiding this comment

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

probably should file a ticket to follow-up on this when real 2.9 is released

@@ -95,8 +95,6 @@ interface NotATuple {
declare const notATuple: NotATuple;
notATuple;

unknownName;
Copy link
Contributor

Choose a reason for hiding this comment

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

did this cause test errors?

Copy link
Contributor

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

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

LGTM! I'm not very familiar with this particular area, but it all seems reasonable.

return imports !== undefined ? imports : [];
}

function isInRange(range: ts.TextRange, pos: number): boolean {
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: might belong in some utils file somewhere? isInTextRange?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm not sure where it would belong though

// https://github.com/Microsoft/TypeScript/issues/14257
[Symbol.iterator]() {}
#if typescript >= 2.8.0
Copy link
Contributor

Choose a reason for hiding this comment

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

TIL this is possible. Is this documented anywhere? If not, should we file a followup issue for another PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

not sure if it has been documented anywhere, I found it while reading the tests. I think documenting it would be useful. Let's file a follow up issue

@@ -65,8 +65,15 @@ export class DestructuringTests {
}
}

// Could be a bug with 2.9-dev but getPreEmitDiagnostics isn't
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you link to the corresponding TypeScript issue?

Copy link
Contributor

Choose a reason for hiding this comment

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

👍 or if there isn't one, file a ticket with them and link it to this PR!

@JoshuaKGoldberg
Copy link
Contributor

FYI @amcasey (I think you've been working in this space recently?)

Copy link
Contributor

@jkillian jkillian left a comment

Choose a reason for hiding this comment

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

LGTM! I don't know all the TS internals super well so I sort of just glanced over the details of the changes for 2.8, but the test cases all look reasonable

Copy link
Contributor

@johnwiseheart johnwiseheart left a comment

Choose a reason for hiding this comment

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

LGTM so long as we file some tickets for those outstanding issues

@suchanlee
Copy link
Contributor Author

So it wasn't an issue with TS, but the diagnoses were being ignored because the diagnosis code had changed in 2.9. Made changes to the code to handle those and fixed the tests accordingly.

But this solidifies the concern that I had, which is that this rule is complex and hard to maintain with a living and changing compiler. I feel that we should deprecate this rule in the near future for the following reasons:

  • It is expensive to maintain
  • The rule is complex
  • It has many issues: https://github.com/palantir/tslint/issues?utf8=%E2%9C%93&q=is%3Aissue+no-unused-variables
  • Most importantly, TS supports it very well. What this rule actually does is take what the TS compiler outputs and process them and to construct TSLint failures and fixes which it's surprisingly complex and slow. And I believe until 2.7 the failures that TS/TSLint output were similar, but starting from 2.7, it has deviated quite a bit, both in the error messages and the erroring text range.

Deprecating the rule was discussed: #1481 but the community decided to not deprecate it for two main reasons:
(1) TSLint errors don't affect compilation while TS errors do, and sometimes you just want to fast dev ignoring warnings
(2) TSLint autofixes

(1) is in discussion in microsoft/TypeScript#13408 and is already supported via microsoft/vscode#37616
(2) I don't think is supported yet.

@suchanlee suchanlee merged commit a7be726 into master Apr 26, 2018
@suchanlee suchanlee deleted the fix-build branch April 26, 2018 07:25
@suchanlee
Copy link
Contributor Author

@jkillian @johnwiseheart @JoshuaKGoldberg ^^^ not that we should take any action now but something to keep track of in the future

@JoshuaKGoldberg
Copy link
Contributor

I'm in favor of deprecating it altogether. My team at work just switched from the TSLint rule to TypeScript's flags because the TSLint VS Code extension doesn't support typed rules and we haven't gotten around to using the language service.

Error diagnostics and messages are a big point of investment for TypeScript right now, so this doesn't feel like something worth investing in for TSLint.

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