dart2js: add compiler builtins to the core-runtime.

dart2js: add compiler builtins to the core-runtime.

WIP.

R=johnniwinther@google.com, sra@google.com

Committed: https://code.google.com/p/dart/source/detail?r=45176
Reverted: https://code.google.com/p/dart/source/detail?r=45177

Committed: https://code.google.com/p/dart/source/detail?r=45347

[floitsch, 2015-02-25 19:00:22]

floitsch@google.com changed reviewers:
+ herhut@google.com, johnniwinther@google.com, sra@google.com

[floitsch, 2015-02-25 19:00:22]

Not yet finished (will send out another review later).

The idea is that almost all functions in foreign_helper.dart should be
implemented as "macro".
We probably want to add a way to declare side-effects too. This way even
embedded-globals could be implemented as macros.

Wdyt?

[sra1, 2015-02-26 06:59:39]

On 2015/02/25 19:00:22, floitsch wrote:
> Not yet finished (will send out another review later).
> 
> The idea is that almost all functions in foreign_helper.dart should be
> implemented as "macro".
> We probably want to add a way to declare side-effects too. This way even
> embedded-globals could be implemented as macros.
> 
> Wdyt?

Could you add an example? I don't understand the where the macro is defined. Is
it like a generalized form of JS_NAME?

[karlklose, 2015-02-26 07:45:20]

On 2015/02/26 06:59:39, sra1 wrote:
> On 2015/02/25 19:00:22, floitsch wrote:
> > Not yet finished (will send out another review later).
> > 
> > The idea is that almost all functions in foreign_helper.dart should be
> > implemented as "macro".
> > We probably want to add a way to declare side-effects too. This way even
> > embedded-globals could be implemented as macros.
> > 
> > Wdyt?
> 
> Could you add an example? I don't understand the where the macro is defined.
Is
> it like a generalized form of JS_NAME?

'Macro' to me sounds like syntactical replacement, but these definitions (as
JS_EMBEDDED_GLOBALS) feel more like primitive/basic operations (and values)
defined by the code generator. Maybe you could find another name?

[herhut, 2015-02-26 08:50:28]

Where do you envision the macros to be defined? The builder has to get them
somewhere. Just a static mapping in the builder?

https://codereview.chromium.org/954253002/diff/1/pkg/compiler/lib/src/native/...
File pkg/compiler/lib/src/native/behavior.dart (right):

https://codereview.chromium.org/954253002/diff/1/pkg/compiler/lib/src/native/...
pkg/compiler/lib/src/native/behavior.dart:235: // We don't check the given name.
That needs to be done at a later point.
For macros, the name has to be a literal. Otherwise, we cannot instantiate the
corresponding template at compile time...

https://codereview.chromium.org/954253002/diff/1/sdk/lib/_internal/compiler/j...
File sdk/lib/_internal/compiler/js_lib/foreign_helper.dart (right):

https://codereview.chromium.org/954253002/diff/1/sdk/lib/_internal/compiler/j...
sdk/lib/_internal/compiler/js_lib/foreign_helper.dart:256:
JS_COMPILER_MACRO(String typeDescription, String macroName,
I would prefer the macros to be typed instead of the call. If only to prevent
the getters void of any semantics like those for metadata.

[floitsch, 2015-03-18 17:43:01]

Unfortunately I ran into a few issues.
I'm giving up on the idea for now :(

https://codereview.chromium.org/954253002/diff/1/pkg/compiler/lib/src/native/...
File pkg/compiler/lib/src/native/behavior.dart (right):

https://codereview.chromium.org/954253002/diff/1/pkg/compiler/lib/src/native/...
pkg/compiler/lib/src/native/behavior.dart:235: // We don't check the given name.
That needs to be done at a later point.
On 2015/02/26 08:50:28, herhut wrote:
> For macros, the name has to be a literal. Otherwise, we cannot instantiate the
> corresponding template at compile time...

We are switching to enums and shared string-literals. This means that we cannot
require a literal here.

[floitsch, 2015-04-10 23:09:08]

floitsch@google.com changed reviewers:
- johnniwinther@google.com

[floitsch, 2015-04-10 23:09:08]

I revived the CL.
In fact, after some more work it's getting really nice.

Please start reviewing, in case you want me to change direction. (The remaining
changes will just move more foreign functions to builtins).

Note: The current way of determining if a builtin has side-effects, or its type
is sub-optimal. Ideally it should be the template (or the place of the template)
that decides on it, but that would require more changes (in particular to the
type-inferrer). It should be relatively easy to change in a later CL.

[Johnni Winther, 2015-04-14 07:41:29]

johnniwinther@google.com changed reviewers:
+ johnniwinther@google.com

[Johnni Winther, 2015-04-14 07:41:30]

lgtm

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
File pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart (right):

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:8: JsBuiltin;
Bad indentation.

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:28:
NO_LOCATION_SPANNABLE;
Bad indentation.

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:39: this.namer = namer,
Bad indentation.

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:87:
namer.lazyInitializerName(element)]);
Bad indentation.

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:114:
hasBeenInstantiated ? constructorAccess(element) : typeAccess(element);
Bad indentation.

[sra1, 2015-04-14 21:02:01]

I like that this is moving code out of ssa.

You might solve the problem of having two arguments (behavior, name) by changing
JS_BUILTIN take one String, and converting the String into the enum value.
i.e. the string would be the enum value's name.
It is almost as good as the enum and allows the behavior to be moved alongside
the template generating code.

https://codereview.chromium.org/954253002/diff/60001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/js_lib/native_helper.dart (right):

https://codereview.chromium.org/954253002/diff/60001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/js_lib/native_helper.dart:93: // Some of the extra
parens here are necessary.
Parens should no longer be needed, but do no harm.

[floitsch, 2015-04-15 14:33:31]

On 2015/04/14 21:02:01, sra1 wrote:
> I like that this is moving code out of ssa.
> 
> You might solve the problem of having two arguments (behavior, name) by
changing
> JS_BUILTIN take one String, and converting the String into the enum value.
> i.e. the string would be the enum value's name.
> It is almost as good as the enum and allows the behavior to be moved alongside
> the template generating code.
That would be an option.
Another one would be to go for the string-representation of the argument:
BUILTIN(JsBuiltin.foo); -> lookup "JsBuiltin.foo").
At a later stage it is checked that the target is indeed a JsBuiltin, so the
early (during type-inference) "toString" wouldn't hurt.
I prefer to keep this CL simpler for now.

> 
>
https://codereview.chromium.org/954253002/diff/60001/sdk/lib/_internal/compil...
> File sdk/lib/_internal/compiler/js_lib/native_helper.dart (right):
> 
>
https://codereview.chromium.org/954253002/diff/60001/sdk/lib/_internal/compil...
> sdk/lib/_internal/compiler/js_lib/native_helper.dart:93: // Some of the extra
> parens here are necessary.
> Parens should no longer be needed, but do no harm.

[floitsch, 2015-04-15 14:34:36]

This CL is growing more than I thought.

I would like to commit what is done so far, and continue migrating in different
CLs.

Any objections to committing?

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
File pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart (right):

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:8: JsBuiltin;
On 2015/04/14 07:41:30, Johnni Winther wrote:
> Bad indentation.

Done.

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:28:
NO_LOCATION_SPANNABLE;
On 2015/04/14 07:41:30, Johnni Winther wrote:
> Bad indentation.

Done.

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:39: this.namer = namer,
On 2015/04/14 07:41:30, Johnni Winther wrote:
> Bad indentation.

Done.

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:87:
namer.lazyInitializerName(element)]);
On 2015/04/14 07:41:30, Johnni Winther wrote:
> Bad indentation.

Done.

https://codereview.chromium.org/954253002/diff/60001/pkg/compiler/lib/src/js_...
pkg/compiler/lib/src/js_emitter/new_emitter/emitter.dart:114:
hasBeenInstantiated ? constructorAccess(element) : typeAccess(element);
On 2015/04/14 07:41:30, Johnni Winther wrote:
> Bad indentation.

Done.

https://codereview.chromium.org/954253002/diff/60001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/js_lib/native_helper.dart (right):

https://codereview.chromium.org/954253002/diff/60001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/js_lib/native_helper.dart:93: // Some of the extra
parens here are necessary.
On 2015/04/14 21:02:01, sra1 wrote:
> Parens should no longer be needed, but do no harm.

Acknowledged.

[sra1, 2015-04-15 18:39:26]

lgtm

[floitsch, 2015-04-15 19:18:23]

Committed patchset #5 (id:80001) manually as 45176 (presubmit successful).

[floitsch, 2015-04-22 13:44:29]

I had to revert because of a bad return type.

The last patch-set fixes it.
I'm resubmitting.

[floitsch, 2015-04-22 13:45:10]

Committed patchset #7 (id:120001) manually as 45347 (presubmit successful).