From 0bf65e4c672d2f37f44bb41790b09d6b6690cc66 Mon Sep 17 00:00:00 2001 From: Paul van Brenk Date: Thu, 2 Apr 2015 15:36:45 -0700 Subject: [PATCH] Fix annoying spellin errors. --- src/compiler/parser.ts | 8 ++++---- src/services/navigateTo.ts | 2 +- src/services/patternMatcher.ts | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/compiler/parser.ts b/src/compiler/parser.ts index 14311ccbc52..13dbccbe4b1 100644 --- a/src/compiler/parser.ts +++ b/src/compiler/parser.ts @@ -824,7 +824,7 @@ module ts { // to reuse are already at the appropriate position in the new text. That way when we // reuse them, we don't have to figure out if they need to be adjusted. Second, it makes // it very easy to determine if we can reuse a node. If the node's position is at where - // we are in the text, then we can reuse it. Otherwise we can't. If hte node's position + // we are in the text, then we can reuse it. Otherwise we can't. If the node's position // is ahead of us, then we'll need to rescan tokens. If the node's position is behind // us, then we'll need to skip it or crumble it as appropriate // @@ -1029,7 +1029,7 @@ module ts { // that some tokens that would be considered identifiers may be considered keywords. // // When adding more parser context flags, consider which is the more common case that the - // flag will be in. This should be hte 'false' state for that flag. The reason for this is + // flag will be in. This should be the 'false' state for that flag. The reason for this is // that we don't store data in our nodes unless the value is in the *non-default* state. So, // for example, more often than code 'allows-in' (or doesn't 'disallow-in'). We opt for // 'disallow-in' set to 'false'. Otherwise, if we had 'allowsIn' set to 'true', then almost @@ -1040,7 +1040,7 @@ module ts { // // An important thing about these context concepts. By default they are effectively inherited // while parsing through every grammar production. i.e. if you don't change them, then when - // you parse a sub-production, it will have the same context values as hte parent production. + // you parse a sub-production, it will have the same context values as the parent production. // This is great most of the time. After all, consider all the 'expression' grammar productions // and how nearly all of them pass along the 'in' and 'yield' context values: // @@ -1793,7 +1793,7 @@ module ts { // some node, then we cannot get a node from the old source tree. This is because we // want to mark the next node we encounter as being unusable. // - // Note: This may be too conservative. Perhaps we could reuse hte node and set the bit + // Note: This may be too conservative. Perhaps we could reuse the node and set the bit // on it (or its leftmost child) as having the error. For now though, being conservative // is nice and likely won't ever affect perf. if (parseErrorBeforeNextFinishedNode) { diff --git a/src/services/navigateTo.ts b/src/services/navigateTo.ts index 9871a447c05..54f87d8e50b 100644 --- a/src/services/navigateTo.ts +++ b/src/services/navigateTo.ts @@ -22,7 +22,7 @@ module ts.NavigateTo { continue; } - // It was a match! If the pattern has dots in it, then also see if hte + // It was a match! If the pattern has dots in it, then also see if the // declaration container matches as well. if (patternMatcher.patternContainsDots) { let containers = getContainers(declaration); diff --git a/src/services/patternMatcher.ts b/src/services/patternMatcher.ts index 61642552cab..646782b2cf0 100644 --- a/src/services/patternMatcher.ts +++ b/src/services/patternMatcher.ts @@ -471,7 +471,7 @@ module ts { // Helper function to compare two matches to determine which is better. Matches are first // ordered by kind (so all prefix matches always beat all substring matches). Then, if the - // match is a camel case match, the relative weights of hte match are used to determine + // match is a camel case match, the relative weights of the match are used to determine // which is better (with a greater weight being better). Then if the match is of the same // type, then a case sensitive match is considered better than an insensitive one. function patternMatchCompareTo(match1: PatternMatch, match2: PatternMatch): number {