Pull model for contextual types #330
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
New baselines reflect a couple of unrelated bug fixes.
Changed binder to record catch clause instead of catch variable as symbol declaration. Restructuring of getTypeOfVariableDeclaration and getTypeOfVariableOrParameterOrProperty methods. Restructuring of checkFunctionExpression method.
Previous commit fixes overly aggressive -noImplictAny reporting. In the test case the source of the error is the 'getAndSet' property that implicitly gets type any. The fact that the setter then gets type any isn't actually an error.
checkFunctionExpression only type checks function body if fullTypeCheck is true.
| @@ -250,7 +250,7 @@ module ts { | |||
|
|
|||
| function bindCatchVariableDeclaration(node: CatchBlock) { | |||
| var symbol = createSymbol(SymbolFlags.Variable, node.variable.text || "__missing"); | |||
| addDeclarationToSymbol(symbol, node.variable, SymbolFlags.Variable); | |||
| addDeclarationToSymbol(symbol, node, SymbolFlags.Variable); | |||
There was a problem hiding this comment.
I'm awfully confused - why are we binding on the catch block instead of the variable? It seems inherently wrong, and is otherwise undocumented.
There was a problem hiding this comment.
Symbols are supposed to be bound to the declaration node that contains their identifier, but a catch block was erroneously bound to the identifier itself.
checkImplicitAny now returns void.
| } | ||
|
|
||
| // Return contextual type of parameter or undefined if no contextual type is available | ||
| function getContextuallyTypedParameterType(parameter: VariableDeclaration): Type { |
There was a problem hiding this comment.
I think parameter type should be ParameterDeclaration to emphasize that node here should be parameter
|
👍 |
ahejlsberg
added a commit
that referenced
this pull request
Aug 4, 2014
Pull model for contextual types
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request switches our contextual typing logic to use a “pull model” such that you can grab any expression node or symbol and ask for its type without having to first ensure types have been “pushed” into the right places. This includes contextually typed sub-expressions and contextually typed parameters of function expressions. We need this change to deliver correct results in the language service.
The key difference is a new
getContextualTypefunction that returns the contextual type associated with an arbitrary expression node with no requirement that the node or its containing function(s) have been fully type checked first. The methods works its way up the parent chain to compute the contextual type and binds contextually typed function expressions as necessary. Also, the types of contextually typed lambda parameters are computed on demand in a pull fashion so it is now safe to ask for the type of any symbol anywhere.