Correct typos in comment in the parser grammar

Author: MDoerner

Rubberduck.Parsing/Grammar/VBAParser.g4

@@ -580,9 +580,9 @@ subscript : (expression whiteSpace TO whiteSpace)? expression;
 unrestrictedIdentifier : identifier | statementKeyword | markerKeyword;
 legalLabelIdentifier : { !(new[]{DOEVENTS,END,CLOSE,ELSE,LOOP,NEXT,RANDOMIZE,REM,RESUME,RETURN,STOP,WEND}).Contains(_input.La(1))}? identifier | markerKeyword;
 //The predicate in the following rule has been introduced to lessen the problem that VBA uses the same characters used as type hints in other syntactical constructs, 
-//e.g. in the bang notation (see withDictionaryAccessExpr). Generally, it is not legal to have an identifier of openeing bracket follow immediately after a type hint.
-//The first part of the predicate tries to exclude these two situations. Unfortunately, predicates have to be at the start of a rule. S, an assumprion about the number 
-//of tokens in the identifier is made. All untypedIdentifers not a foreignNames consist of exactly one token and a typedIdentifier is an untypes one followed by a typeHint,
+//e.g. in the bang notation (see withDictionaryAccessExpr). Generally, it is not legal to have an identifier or opening bracket follow immediately after a type hint.
+//The first part of the predicate tries to exclude these two situations. Unfortunately, predicates have to be at the start of a rule. So, an assumption about the number 
+//of tokens in the identifier is made. All untypedIdentifers not a foreignNames consist of exactly one token and a typedIdentifier is an untyped one followed by a typeHint,
 //again a single token. So, in the majority of situations, the third token is the token following the potential type hint. 
 //For foreignNames, no assumption can be made because they consist of a pair of brackets containing arbitrarily many tokens. 
 //That is why the second part of the predicate looks at the first character in order to determine whether the identifier is a foreignName.