Fix parsing of f<<T>()=>S>()

Summary:
As reported [here](#8824), we parse function calls with explicit instantiation incorrectly if the type begins with `<`. In such cases, we lex `<<` as the left shift operator. We don't have similar problems with `>>` or with `<<` in type definitions because we lex those cases as types, but we lex function call explicit instantiation as regular tokens. This diff switches to parsing as types eariler.

Closes #8824

Changelog: [parser] Fixed a bug where type parameter instantiations that start with `<` (e.g., `f<<T>()=>S>()`) would be incorrectly parsed as the left shift operator.

Reviewed By: mroch

Differential Revision: D34050306

fbshipit-source-id: 0c16b393e1f8e7c0fdc8c9439d97256379e4eb66

src/parser/expression_parser.ml

@@ -761,7 +761,9 @@ module Expression
     else
       match Peek.token env with
       | T_LPAREN -> arguments env (left_to_callee env)
-      | T_LESS_THAN when should_parse_types env ->
+      | T_LSHIFT
+      | T_LESS_THAN
+        when should_parse_types env ->
         (* If we are parsing types, then f<T>(e) is a function call with a
            type application. If we aren't, it's a nested binary expression. *)
         let error_callback _ _ = raise Try.Rollback in
@@ -901,10 +903,15 @@ module Expression
         }
     in
     fun env ->
-      if Peek.token env = T_LESS_THAN then
-        Some (with_loc args env)
-      else
-        None
+      Eat.push_lex_mode env Lex_mode.TYPE;
+      let node =
+        if Peek.token env = T_LESS_THAN then
+          Some (with_loc args env)
+        else
+          None
+      in
+      Eat.pop_lex_mode env;
+      node
 
   and arguments =
     let spread_element env =

src/parser/test/flow/lshift_type_arg/example.js

@@ -0,0 +1,4 @@
+f< <T>(v: T) => T>();
+f<<T>(v: T) => T>();
+f<<T;
+f< <T;