Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle block scopes in OTI #2796

Open
shicks opened this issue Jan 24, 2018 · 0 comments
Open

Handle block scopes in OTI #2796

shicks opened this issue Jan 24, 2018 · 0 comments
Assignees

Comments

@shicks
Copy link
Member

shicks commented Jan 24, 2018

Handling block scopes in OTI is a key milestone to supporting ES6 throughout the compiler.

@shicks shicks self-assigned this Jan 24, 2018
MatrixFrog pushed a commit that referenced this issue Feb 28, 2018
Background: CL 181680335 fixed/generalized the equals and hashCode behavior of Var and TypedVar, which previously only depended on the definition node, to instead depend on the name and the root node of the scope in which the name was defined.  Importantly, this preserved the property that Vars needn't share the same scope creator to be equal, but was still required to be an instance of AbstractVar, which requires a corresponding AbstractScope.  This CL loosens that requirement, in particular by providing a simple value type `ScopedName.of(name, node)` which can be used alongside (e.g.) TypedVar as keys in the same ScopedName-keyed map.  This is a step toward supporting block scopes in OTI (#2796).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187266949
MatrixFrog pushed a commit that referenced this issue Mar 3, 2018
This is a step toward teaching TypeInference to deal with ES6 block scopes correctly (#2796).  It doesn't make any functional difference yet since all the vars are currently in the same (CFG root) scope, so the comparisons might as well be strings.  The next step is to add a block scope field to LinkedFlowScope in addition to the functionScope field, which will be used by the infer and getSlot methods to map strings to variables in the relevant scope.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187412071
sebasjm pushed a commit to sebasjm/closure-compiler that referenced this issue Mar 11, 2018
Background: CL 181680335 fixed/generalized the equals and hashCode behavior of Var and TypedVar, which previously only depended on the definition node, to instead depend on the name and the root node of the scope in which the name was defined.  Importantly, this preserved the property that Vars needn't share the same scope creator to be equal, but was still required to be an instance of AbstractVar, which requires a corresponding AbstractScope.  This CL loosens that requirement, in particular by providing a simple value type `ScopedName.of(name, node)` which can be used alongside (e.g.) TypedVar as keys in the same ScopedName-keyed map.  This is a step toward supporting block scopes in OTI (google#2796).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187266949
sebasjm pushed a commit to sebasjm/closure-compiler that referenced this issue Mar 11, 2018
This is a step toward teaching TypeInference to deal with ES6 block scopes correctly (google#2796).  It doesn't make any functional difference yet since all the vars are currently in the same (CFG root) scope, so the comparisons might as well be strings.  The next step is to add a block scope field to LinkedFlowScope in addition to the functionScope field, which will be used by the infer and getSlot methods to map strings to variables in the relevant scope.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187412071
brad4d pushed a commit that referenced this issue Mar 23, 2018
…nference.

Currently the scope is pretty boring, since it's always just the function scope, but this implementation works for block scopes as well.

This is a step towards #2796.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190156977
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant