spelling fixes (round 1)#6932
Conversation
|
Hi @jsoref, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! The agreement was validated by Microsoft and real humans are currently evaluating your PR. TTYL, MSBOT; |
| const localTypeParameters = getLocalTypeParametersOfClassOrInterfaceOrTypeAlias(symbol); | ||
| // A class or interface is generic if it has type parameters or a "this" type. We always give classes a "this" type | ||
| // because it is not feasible to analyze all members to determine if the "this" type escapes the class (in particular, | ||
| // because it is not feasible to analyse all members to determine if the "this" type escapes the class (in particular, |
There was a problem hiding this comment.
This project is run from the United States so analyze is correct 😉
There was a problem hiding this comment.
I normally would use z, but there were more instances of s, so I favored it against my own preference. I'll gladly switch :-)
|
Looks like you'll have to also run some of the fixes in |
|
Offhand, it looks like all of the changes in types.ts are either related or comments, tentatively, I'll include the whole file. |
|
You'll have to take care of the downstream effects as well. If |
| // Stores a mapping 'external module reference text' -> 'resolved file name' | undefined | ||
| // It is used to resolve module names in the checker. | ||
| // Content of this fiels should never be used directly - use getResolvedModuleFileName/setResolvedModuleFileName functions instead | ||
| // Content of this fields should never be used directly - use getResolvedModuleFileName/setResolvedModuleFileName functions instead |
|
i don't see 'analyse' in the diff. Why is it on the list of corrections in the PR description? |
|
@sandersn the correction was from "analyze" to "analyse", but was reverted. |
|
So it was in the previous PR? There's only one commit on this one. |
|
Presumably there was a force push |
jsoref
changed the title
|
@RyanCavanaugh : the tests now pass, hopefully this is closer to what you want. |
|
@jsoref can you keep commits in the future so I can diff before vs after? It makes reviewing much easier. |
|
Looks good to me except for the incorrect fix "fields" |
|
👍 |
* accessibility * accessor * annotate * anything * apply * assignability * collection * conservatively * constituent * constructor * containing * contextual * contributed * declaration * excessively * exclusion * field * indistinguishable * initializer * intrinsic * knowing * noisiness * occurred * overridden * parameter * perspective * properties * property * prototype * rewritten * specifies * symbolFromSymbolTable
|
@sandersn : I've preserved it as https://github.com/jsoref/TypeScript/tree/spelling-1-1 which should hopefully keep it from going away. |
|
👍 |
|
Awesome - thanks @jsoref! |
spelling fixes (round 1)
|
Yep, go ahead. Looking forward to seeing more spelling fixes. :) |
| }); | ||
|
|
||
| // ECMA-262 11.1.5 Object Initialiser | ||
| // ECMA-262 11.1.5 Object Initializer |
There was a problem hiding this comment.
Is it 11.1.5?
It's not, according to the ECMA web site
12.2.6 Object Initializer
NOTE 1 An object initializer is an expression describing the initialization of an Object, written in a form resembling a literal. It is a list of zero or more pairs of property keys and associated values, enclosed in curly brackets. The values need not be literals; they are evaluated each time the object initializer is evaluated.
There was a problem hiding this comment.
Happy to fix that, but it's not a spelling mistake. And amusingly, I've at least (accidentally) fixed the spelling to match the spec... (I wonder how it got out of sync...)
7 participants
(see commit message for list of changes)