-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Fix latest tslint errors #13006
Fix latest tslint errors #13006
Conversation
A benchmark shows for-of loop is much slower on Chrome (and thus node.js), does this mean we shouldn't use for-of? |
|
Already done the upgrade for obvious cases but many of them are using indices so I couldn't do it for them. |
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.
I would inline the collection.length
check instead of adding a new variable for it. There is not much perf difference on modern engines anyways.
@@ -5118,7 +5119,8 @@ namespace ts { | |||
function getSignaturesOfSymbol(symbol: Symbol): Signature[] { | |||
if (!symbol) return emptyArray; | |||
const result: Signature[] = []; | |||
for (let i = 0, len = symbol.declarations.length; i < len; i++) { | |||
const len = symbol.declarations.length; | |||
for (let i = 0; i < len; i++) { |
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.
switch to for..of
?
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.
Inner lines of code use i
for some purpose. It seems I can still switch to for-of in this case but should I do it?
@@ -5019,7 +5019,8 @@ namespace ts { | |||
// If this is a JSDoc construct signature, then skip the first parameter in the | |||
// parameter list. The first parameter represents the return type of the construct | |||
// signature. | |||
for (let i = isJSConstructSignature ? 1 : 0, n = declaration.parameters.length; i < n; i++) { | |||
const n = declaration.parameters.length; | |||
for (let i = isJSConstructSignature ? 1 : 0; i < n; i++) { | |||
const param = declaration.parameters[i]; |
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 (let i = isJSConstructSignature ? 1 : 0; i < declaration.parameters.length; i++) {
@saschanaz i have merged a change to move tslint back to |
It still won't pass because of some bugs, which should be fixed on tslint side. |
do you have a list of the issues? |
@mhegazy See first post and palantir/tslint#1898. I actually fixed one of them yesterday. The other one is also a legitimate issue, but could be fixed on our end by moving the declaration ( |
@Andy-MS I'm still seeing destructuring issue on Travis, should I do something to get the merged fix? |
|
I'd prefer not to change our code to workaround bugs in the toolchain hence palantir/tslint#1908 |
@nchen63 any news about palantir/tslint#1908? |
it's merged and included in a new release, v4.2.0 |
It seems |
should be fixed now |
Except this type of errors:
I think they are tslint bugs rather than actual code problem. (palantir/tslint#1898)
BTW I feel fairly painful to create a new constant for every for-loop, I hope there is a better way to keep high performance...