Doesn't currently work since we can't use js.Names and regular parameters/variables in the same JavaScript scope.
Long term - we should fix this (https://github.com/dart-lang/sdk/issues/29455)
Short term, we could generate variable strings that are named after the fields and disambiguate them manually.
BUG=
Review-Url: https://codereview.chromium.org/2837243002 .
This is a step towards making the compiler agnostic of how the element
model is created. This enables us to build support for the kernel based
front end in parallel with the existing resolver based front end.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2841583002 .
This CL hooks up enough infrastructure for doing simple top level type
inference of variables whose initializer is an int.
Additional type inference rules will be added in follow-up CLs.
R=karlklose@google.com
Review-Url: https://codereview.chromium.org/2828253003 .
Also extract more extract more methods from ClosedWorldImpl into
ClosedWorldBase.
This is a step towards creating a closed world object from kernel based
elements. This CL adds the first mock of that object.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2826673002 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2824823004 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2820143004 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2823003003 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2810223002 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2815513007 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2818463002 .
This is a step towards passing data object directly instead of accessing
data on JavaScriptBackend. This is needed to support an element switch
between resolution and codegen.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2810183002 .
- and Compiler from type_test_registry.
The CodeEmitterTask was removed from the TypeRepresentationGenerator to
break a dependency cycle between the two. An Emitter is now provided as
an argument to TypeRepresentationGenerator methods instead.
This is a step towards passing data object to the codegen/emitter
instead of pulling data directly from Compiler/JavaScriptBackend. This
is needed to support an element model switch between codegen and
resolution.
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2809203003 .
1. Simplify HPhi nodes that merge refinements of the same value.
2. Replace the condition of HIf with a constant when the HIf does nothing (no controlled statements or phis).
Together with existing optimizations, this can optimize `s?.toString()` to `s` when `s` is known to be a nullable String.
BUG=
R=efortuna@google.com
Review-Url: https://codereview.chromium.org/2823543002 .
Stephen Adams