-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[flow] Extract and store global info in type sig
Summary: ## Intro For motivation, see D68740497. This diff mainly implements the support for `declare global {...}` from type sig. There are two major parts: 1. type_sig_parse: which mostly focuses on scoping rules 2. everything else: mostly boring information propagation: from parsed form to packed form and then to types. I will focus on 1 in the diff summary. ## Restrictions and Limitations First, `declare module {...}` will only be supported in toplevel of declare module or a module. If it appears anywhere else, it will be ignored, because it will be treated as a `Ast.Statement.Block`. This is easy to enforce: we only do something about `declare global {...}` if the parent scope is `Module` or `DeclareModule`. Secondly, I will state some limitations: only types-only declarations will be bind to the environment. The goal is to give us flexibility of interpreting these `declare global {...}` later. If we also bind values, then we have to make the effect of global-modifying modules transitive, because that's what's happening at runtime for importing modules with side effect. This can potentially be a disaster for performance given that we allow cyclic modules. However, if it's type only, then we retain the right to say you get what you get. Conceptually, we can think of the following code ``` // a.js declare global { type T = string; } // b.js import 'global'; type T1 = T; ``` as ``` // a.js declare export namespace $secret$globals { type T = string; } // b.js import {type $secret$globals} 'global'; type T1 = $secret$globals.T; ``` ## Scoping Rules Finally let's define the scoping rules. Without losing generality, I will use `declare global` within `declare module` as an example. Given: ``` declare module foo { declare global { // global decl 1 } // module decl1 declare global { // global decl 2 } // module decl2 } ``` It will be conceptually treated as ``` declare module foo { module_globals { // global decl 1 // global decl 2 regular_module_stuff { // module decl1 // module decl2 } } } ``` This implies that the named defined in the `declare global` block can be shadowed by the same name within `regular_module_stuff`, and more importantly, code within `regular_module_stuff` can refer to these globals. It might look weird first, but if you think it over, you will find that it's just a replacement of the following in global libdef ``` // global decl 1 // global decl 2 declare module foo { // module decl1 // module decl2 } ``` In terms of implementation, the above rules are implemented as follows within type sig: - Normal module stuff binds as usual - Within `declare global {...}` - We will push a `DeclareGlobal` scope that only tracks it's parent. - Value bindings are ignored - On type bindings, we will trace back to the parent, and add it to the `global_types` field in the `exports` field of `Module` or `DeclareModule` - On lookup within `declare global {...}`, we will trace back to the parent, and lookup from the `global_types` field in the `exports` field of `Module` or `DeclareModule` first, before falling back to parents - On lookup within module or declare module, we will first lookup normal module bindings, and if not found, try look up from the `global_types` field in the `exports` field. Changelog: [internal] Reviewed By: panagosg7 Differential Revision: D68246824 fbshipit-source-id: f7d4a58908e56f5175d036a508575e79fea5faf6
- Loading branch information
1 parent
60cfefd
commit d890dfa
Showing
14 changed files
with
830 additions
and
320 deletions.
There are no files selected for viewing
This file contains 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
801 changes: 530 additions & 271 deletions
801
src/parser_utils/type_sig/__tests__/type_sig_tests.ml
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.