Skip to content

Conversation

@ghost
Copy link

@ghost ghost commented Aug 11, 2017

Fixes #11499

Adds an additional parameter to resolveName that determines whether we would count this as a use.

@ghost ghost requested a review from sheetalkamat August 11, 2017 21:57
@ghost ghost force-pushed the write-reference branch 7 times, most recently from 1440332 to a548bf9 Compare August 11, 2017 23:56
@ghost ghost force-pushed the write-reference branch from a548bf9 to bce9d1b Compare August 11, 2017 23:59
@ghost
Copy link
Author

ghost commented Aug 29, 2017

@sheetalkamat Any comments?

const links = getNodeLinks(node);
if (!links.resolvedSymbol) {
links.resolvedSymbol = !nodeIsMissing(node) && resolveName(node, node.escapedText, SymbolFlags.Value | SymbolFlags.ExportValue, Diagnostics.Cannot_find_name_0, node, Diagnostics.Cannot_find_name_0_Did_you_mean_1) || unknownSymbol;
const isReference = !isWriteAccess(node, /*writeOnly*/ true);
Copy link
Contributor

Choose a reason for hiding this comment

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

move this to the call of resolveName in case node is missing.

/**
* @param writeOnly If set, return true for `x++;` but not for `f(x++);`, which uses `x` in addition to writing to it.
*/
export function isWriteAccess(node: Node, writeOnly: boolean): boolean {
Copy link
Contributor

Choose a reason for hiding this comment

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

isWriteAccess(.., /*writeOnly*/ true) is ugly allover the place. consider splitting them into two functions, one for isWriteOnlyAccess, and one isReadAccess

@mhegazy
Copy link
Contributor

mhegazy commented Sep 6, 2017

f(++x) will be a breaking change, we will need to document this as well as the general tighter checking we have enabled in https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes

@ghost
Copy link
Author

ghost commented Sep 6, 2017

f(++x) will not be an error as of this change, because it's a read access as well as a write access. noUnusedLocals_writeOnly.ts includes a test for this.

@ghost ghost added the Breaking Change Would introduce errors in existing code label Sep 6, 2017
==== tests/cases/compiler/unusedParameterUsedInTypeOf.ts (1 errors) ====
function f1 (a: number, b: typeof a) {
~
!!! error TS6133: 'b' is declared but never used.
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 because of the intent of this test, the test aught to be modified not to trigger this diagnostic.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 6, 2017

I also wounder if we should change the error message to be more specific. instead of "used" to be "read" or something similar.

@ghost ghost added this to the TypeScript 2.6 milestone Sep 6, 2017
@ghost ghost force-pushed the write-reference branch from 2631beb to 2a535c6 Compare September 8, 2017 15:04
@ghost
Copy link
Author

ghost commented Sep 8, 2017

@weswigham @mhegazy Good to go?

@mhegazy
Copy link
Contributor

mhegazy commented Sep 11, 2017

👍

/**
* @param writeOnly If set, return true for `x++;` but not for `f(x++);`, which uses `x` in addition to writing to it.
*/
function isWriteAccessWorker(node: Node, writeOnly: boolean): boolean {
Copy link
Member

Choose a reason for hiding this comment

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

writeOnly feels like a misnomer, since, based on its usage with isWriteOnlyAccess and isReadOnlyAccess, the parameter toggles between readonly and writeonly functionality. Maybe the function should be called accessCheckWorker and isWriteAccess?

Copy link
Author

Choose a reason for hiding this comment

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

isReadOnlyAccess returns !isWriteAccessWorker(node, /*writeOnly*/ false); -- isWriteAccessWorker(node, false); is true for any write, so its negation is whether the access is read-only.
I've changed this to an enum-returning function so there are fewer negations and it's easier to read.

}

/**
* @param writeOnly If set, return true for `x++;` but not for `f(x++);`, which uses `x` in addition to writing to it.
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this comment is supposed to be here anymore; but, this is much nicer now. Would AccessKind be better than WriteKind, considering it can indicate a read?

@weswigham
Copy link
Member

Oh, and can you get a PR updating our RWC baselines with this? Considering it found unused variables in our codebase, I'm sure it'll do the same in our RWC suite.

@ghost ghost merged commit 2a70bf5 into master Sep 13, 2017
@ghost ghost deleted the write-reference branch September 13, 2017 16:02
@ghost
Copy link
Author

ghost commented Sep 14, 2017

I actually didn't see any breaks in RWC.

@weswigham
Copy link
Member

Huh. Neat.

This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Breaking Change Would introduce errors in existing code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

noUnusedLocals and noUnusedParameters should flag write-only variables

3 participants