VM: Support bootstrapping core libraries from Kernel binaries instead of source.

VM: Support bootstrapping core libraries from Kernel binaries instead of source.

BUG=http://dartbug.com/27590
R=asiva@google.com

Committed: https://github.com/dart-lang/sdk/commit/23fd1a184b393825f29444243780f3593ce0b3c1

[Vyacheslav Egorov (Google), 2016-11-08 19:34:43]

vegorov@google.com changed reviewers:
+ asiva@google.com, hausner@google.com, kmillikin@google.com,
kustermann@google.com

[Vyacheslav Egorov (Google), 2016-11-08 19:34:44]

Please take a look. 

This brings last major changes from kernel_sdk fork with some modifications by
me.

These changes implement bootstrapping of core libraries from Kernel binaries.

Original implementation done by Kevin and Martin.

[Florian Schneider, 2016-11-08 20:41:39]

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

[Florian Schneider, 2016-11-08 20:41:40]

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc
File runtime/vm/bootstrap.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc...
runtime/vm/bootstrap.cc:42: #define MAKE_PROPERTIES(CamelName, hacker_name)     
                          \
I do like reducing boilerplate code, but I don't like mixing refactorings into
this CL.

Please factor out any changes that don't add functionality, but only refactor
the code into separate CLs. It makes this CL smaller, and clear what is needed
for functionality-wise.

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc...
runtime/vm/bootstrap.cc:44: "dart:" #hacker_name,                               
                      \
What's a hacker_name? Why not just use "name"?

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc...
runtime/vm/bootstrap.cc:50: static BootstrapLibProps bootstrap_libraries[] = {
static const?

[hausner, 2016-11-09 00:42:49]

A few comments and questions. I haven't looked at the whole CL yet.

Why was the change in UnresolvedClass to library_or_library_prefix necessary?

Thanks

https://codereview.chromium.org/2485993002/diff/20001/runtime/bin/main.cc
File runtime/bin/main.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/bin/main.cc#new...
runtime/bin/main.cc:808: TryReadKernel(script_uri, &kernel_file,
&kernel_length);
What if the uri scheme is not a file?

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/class_finali...
File runtime/vm/class_finalizer.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/class_finali...
runtime/vm/class_finalizer.cc:154: // since we will not revisit them).
Why? Would be nice to have a brief explanation.

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/intrinsifier...
File runtime/vm/intrinsifier_mips.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/intrinsifier...
runtime/vm/intrinsifier_mips.cc:1647: if (a_value.raw() ==
Object::sentinel().raw() ||
Why is this additional check needed now?

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:1138: //   1. Running a Dart Kernel IL.  This function will
bootstrap from the KERNEL
IL -> IR ?

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/object_store.h
File runtime/vm/object_store.h (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/object_store...
runtime/vm/object_store.h:19: #define FOR_EACH_PRODUCT_LIBRARY(M)               
                            \
Similar to Florian's comment, I would prefer to have refactoring done in
separate CLs.

[Vyacheslav Egorov (Google), 2016-11-09 14:43:16]

https://codereview.chromium.org/2485993002/diff/20001/runtime/bin/main.cc
File runtime/bin/main.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/bin/main.cc#new...
runtime/bin/main.cc:808: TryReadKernel(script_uri, &kernel_file,
&kernel_length);
On 2016/11/09 00:42:49, hausner wrote:
> What if the uri scheme is not a file?

We don't support loading kernel from non local URI's for now.

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc
File runtime/vm/bootstrap.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc...
runtime/vm/bootstrap.cc:42: #define MAKE_PROPERTIES(CamelName, hacker_name)     
                          \
On 2016/11/08 20:41:39, Florian Schneider wrote:
> I do like reducing boilerplate code, but I don't like mixing refactorings into
> this CL.
> 
> Please factor out any changes that don't add functionality, but only refactor
> the code into separate CLs. It makes this CL smaller, and clear what is needed
> for functionality-wise.

Moved to a separate CL: https://codereview.chromium.org/2493473002/

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc...
runtime/vm/bootstrap.cc:44: "dart:" #hacker_name,                               
                      \
On 2016/11/08 20:41:39, Florian Schneider wrote:
> What's a hacker_name? Why not just use "name"?

I guess hacker_name is name_with_underscores. Renamed it to name.

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc...
runtime/vm/bootstrap.cc:50: static BootstrapLibProps bootstrap_libraries[] = {
On 2016/11/08 20:41:39, Florian Schneider wrote:
> static const?

Done.

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/class_finali...
File runtime/vm/class_finalizer.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/class_finali...
runtime/vm/class_finalizer.cc:154: // since we will not revisit them).
On 2016/11/09 00:42:49, hausner wrote:
> Why? Would be nice to have a brief explanation.

The original idea behind Kernel was to be an AOT representation. There is no
reason to finalize AOT representation lazily. 

It's similar to how VM eagerly parses and finalizes top level classes.

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/intrinsifier...
File runtime/vm/intrinsifier_mips.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/intrinsifier...
runtime/vm/intrinsifier_mips.cc:1647: if (a_value.raw() ==
Object::sentinel().raw() ||
On 2016/11/09 00:42:49, hausner wrote:
> Why is this additional check needed now?

Due to front-end differences issues we might arrive here without evaluating the
initializer first (it's a pure coincidence that the field is initialized in the
source based front-end - we essentially rely on the fact that this field is
eagerly initialized which is not guaranteed in any way).

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:1138: //   1. Running a Dart Kernel IL.  This function will
bootstrap from the KERNEL
On 2016/11/09 00:42:49, hausner wrote:
> IL -> IR ?

Done.

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/object_store.h
File runtime/vm/object_store.h (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/object_store...
runtime/vm/object_store.h:19: #define FOR_EACH_PRODUCT_LIBRARY(M)               
                            \
On 2016/11/09 00:42:49, hausner wrote:
> Similar to Florian's comment, I would prefer to have refactoring done in
> separate CLs.

It's in separate CL now: https://codereview.chromium.org/2493473002/

[Kevin Millikin (Google), 2016-11-09 15:17:32]

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc
File runtime/vm/bootstrap.cc (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/bootstrap.cc...
runtime/vm/bootstrap.cc:44: "dart:" #hacker_name,                               
                      \
On 2016/11/08 20:41:39, Florian Schneider wrote:
> What's a hacker_name? Why not just use "name"?

Because the other parameter is also a name.

[hausner, 2016-11-09 18:21:37]

One more Q

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/raw_object.h
File runtime/vm/raw_object.h (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/raw_object.h...
runtime/vm/raw_object.h:740: RawObject* library_or_library_prefix_;  // Library
or library prefix qualifier
I don't see where the CL makes use of this change. Why is it necessary?

[Vyacheslav Egorov (Google), 2016-11-09 18:44:52]

Bootstrap libraries refactoring has now landed and CL is rebased against that to
make review easier.

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/raw_object.h
File runtime/vm/raw_object.h (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/raw_object.h...
runtime/vm/raw_object.h:740: RawObject* library_or_library_prefix_;  // Library
or library prefix qualifier
On 2016/11/09 18:21:36, hausner wrote:
> I don't see where the CL makes use of this change. Why is it necessary?

Sorry, I missed this question. 

See kernel_to_il.cc ->
https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/kernel_to_il...

In short we would like to reuse some of the (type) finalization machinery (most
importantly given type like X<T> get a properly expanded list of type
arguments). To reuse this machinery as is we need to be able to create
unresolved types - which requires creating unresolved classes. However to create
unresolved classes we need LibraryPrefix - and we don't have such thing in
Kernel because kernel is completely resolved. 

Hence this change. 

In some sense it's a gross hack - however an alternative seems to be to
duplicate parts of class finalizer - which seems to be a considerably bigger
change.

[hausner, 2016-11-09 19:07:01]

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/raw_object.h
File runtime/vm/raw_object.h (right):

https://codereview.chromium.org/2485993002/diff/20001/runtime/vm/raw_object.h...
runtime/vm/raw_object.h:740: RawObject* library_or_library_prefix_;  // Library
or library prefix qualifier
On 2016/11/09 18:44:52, Vyacheslav Egorov (Google) wrote:
> On 2016/11/09 18:21:36, hausner wrote:
> > I don't see where the CL makes use of this change. Why is it necessary?
> 
> Sorry, I missed this question. 
> 
> See kernel_to_il.cc ->
>
https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/kernel_to_il...
> 
> In short we would like to reuse some of the (type) finalization machinery
(most
> importantly given type like X<T> get a properly expanded list of type
> arguments). To reuse this machinery as is we need to be able to create
> unresolved types - which requires creating unresolved classes. However to
create
> unresolved classes we need LibraryPrefix - and we don't have such thing in
> Kernel because kernel is completely resolved. 
> 
> Hence this change. 
> 
> In some sense it's a gross hack - however an alternative seems to be to
> duplicate parts of class finalizer - which seems to be a considerably bigger
> change. 

Ah, I see now.

[Vyacheslav Egorov (Google), 2016-11-11 13:42:09]

friendly ping

[Florian Schneider, 2016-11-11 14:00:12]

https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
File runtime/vm/method_recognizer.h (left):

https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
runtime/vm/method_recognizer.h:527: #if defined(DART_NO_SNAPSHOT)
Why remove this #ifdef?

Or more general: Please make sure that binary size of "dart" and
"dart_precompiled_runtime" are not negatively affected by this CL. Only
dart_bootstrap should be affected at all.

[Vyacheslav Egorov (Google), 2016-11-11 15:29:47]

https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
File runtime/vm/method_recognizer.h (left):

https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
runtime/vm/method_recognizer.h:527: #if defined(DART_NO_SNAPSHOT)
On 2016/11/11 14:00:12, Florian Schneider wrote:
> Why remove this #ifdef?
> 
> Or more general: Please make sure that binary size of "dart" and
> "dart_precompiled_runtime" are not negatively affected by this CL. Only
> dart_bootstrap should be affected at all.

It is removed because now even if you run with snapshot you still has the mode
where you bootstrap core libraries from Kernel instead of snapshot. 

I will check this up. (Maybe we need a test that checks this up automatically?)

[Florian Schneider, 2016-11-11 15:54:25]

https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
File runtime/vm/method_recognizer.h (left):

https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
runtime/vm/method_recognizer.h:527: #if defined(DART_NO_SNAPSHOT)
On 2016/11/11 15:29:47, Vyacheslav Egorov (Google) wrote:
> On 2016/11/11 14:00:12, Florian Schneider wrote:
> > Why remove this #ifdef?
> > 
> > Or more general: Please make sure that binary size of "dart" and
> > "dart_precompiled_runtime" are not negatively affected by this CL. Only
> > dart_bootstrap should be affected at all.
> 
> It is removed because now even if you run with snapshot you still has the mode
> where you bootstrap core libraries from Kernel instead of snapshot. 
> 
> I will check this up. (Maybe we need a test that checks this up
automatically?)

My comments applies to all occurrences of DART_NO_SNAPSHOT. Basically, Why
should starting from a snapshot require bootstrapping? Starting from a snapshot
should work the same way in both scenarios.

[Vyacheslav Egorov (Google), 2016-11-11 16:01:54]

On 2016/11/11 15:54:25, Florian Schneider wrote:
>
https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
> File runtime/vm/method_recognizer.h (left):
> 
>
https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
> runtime/vm/method_recognizer.h:527: #if defined(DART_NO_SNAPSHOT)
> On 2016/11/11 15:29:47, Vyacheslav Egorov (Google) wrote:
> > On 2016/11/11 14:00:12, Florian Schneider wrote:
> > > Why remove this #ifdef?
> > > 
> > > Or more general: Please make sure that binary size of "dart" and
> > > "dart_precompiled_runtime" are not negatively affected by this CL. Only
> > > dart_bootstrap should be affected at all.
> > 
> > It is removed because now even if you run with snapshot you still has the
mode
> > where you bootstrap core libraries from Kernel instead of snapshot. 
> > 
> > I will check this up. (Maybe we need a test that checks this up
> automatically?)
> 
> My comments applies to all occurrences of DART_NO_SNAPSHOT. Basically, Why
> should starting from a snapshot require bootstrapping? Starting from a
snapshot
> should work the same way in both scenarios.

Let me try to explain again. 

Before this change: if VM binary has snapshot it does not need to run some parts
of the bootstrapping process because they were already run (e.g. core libraries
were setup) and those parts come from the snapshot.

After this change: if VM binary has snapshot it still needs to be able to
bootstrap from scratch because when you run an application from Kernel you
*must* bootstrap core libraries from Kernel and *not* from the snapshot.  

Example of an application with snapshot: dart binary. 

When you do `dart xyz.dart` you take core libraries from the snapshot and the
rest from xyz.dart and run it.

When you do `dart xyz.dill` you take *both* core libraries and application code
form the xyz.dill and ignore snapshotted core libraries. 

Hence the difference.

[Florian Schneider, 2016-11-11 16:27:55]

On 2016/11/11 16:01:54, Vyacheslav Egorov (Google) wrote:
> On 2016/11/11 15:54:25, Florian Schneider wrote:
> >
>
https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
> > File runtime/vm/method_recognizer.h (left):
> > 
> >
>
https://codereview.chromium.org/2485993002/diff/60001/runtime/vm/method_recog...
> > runtime/vm/method_recognizer.h:527: #if defined(DART_NO_SNAPSHOT)
> > On 2016/11/11 15:29:47, Vyacheslav Egorov (Google) wrote:
> > > On 2016/11/11 14:00:12, Florian Schneider wrote:
> > > > Why remove this #ifdef?
> > > > 
> > > > Or more general: Please make sure that binary size of "dart" and
> > > > "dart_precompiled_runtime" are not negatively affected by this CL. Only
> > > > dart_bootstrap should be affected at all.
> > > 
> > > It is removed because now even if you run with snapshot you still has the
> mode
> > > where you bootstrap core libraries from Kernel instead of snapshot. 
> > > 
> > > I will check this up. (Maybe we need a test that checks this up
> > automatically?)
> > 
> > My comments applies to all occurrences of DART_NO_SNAPSHOT. Basically, Why
> > should starting from a snapshot require bootstrapping? Starting from a
> snapshot
> > should work the same way in both scenarios.
> 
> Let me try to explain again. 
> 
> Before this change: if VM binary has snapshot it does not need to run some
parts
> of the bootstrapping process because they were already run (e.g. core
libraries
> were setup) and those parts come from the snapshot.
> 
> After this change: if VM binary has snapshot it still needs to be able to
> bootstrap from scratch because when you run an application from Kernel you
> *must* bootstrap core libraries from Kernel and *not* from the snapshot.  
> 
> Example of an application with snapshot: dart binary. 
> 
> When you do `dart xyz.dart` you take core libraries from the snapshot and the
> rest from xyz.dart and run it.
> 
> When you do `dart xyz.dill` you take *both* core libraries and application
code
> form the xyz.dill and ignore snapshotted core libraries. 
> 
> Hence the difference.

I understand how it works. It does not make sense to start up from a snapshot
and then ignore the core libraries and bootstrap again.
If the snapshot is ignored, shouldn't the command should be "dart_bootstrap
xyz.dill"?

[Vyacheslav Egorov (Google), 2016-11-11 18:33:23]

I restored compilation guards in such a way that bootstrapping parts don't get
pulled into dart_precompiled_runtime.

[Vyacheslav Egorov (Google), 2016-11-11 18:51:33]

I sprinkled more ifdef's on the code to reduce amount of stuff pulled into
dart_precompiled_runtime futher.

I think we need to wrap the whole compiler into #if
!defined(DART_PRECOMPILED_RUNTIME) instead of relying on linker.

[Vyacheslav Egorov (Google), 2016-11-15 11:11:50]

friendly ping.

this is blocking the decomissioning of the fork

[siva, 2016-11-16 05:49:34]

lgtm

https://codereview.chromium.org/2485993002/diff/120001/runtime/bin/gen_snapsh...
File runtime/bin/gen_snapshot.cc (right):

https://codereview.chromium.org/2485993002/diff/120001/runtime/bin/gen_snapsh...
runtime/bin/gen_snapshot.cc:1270: const uint8_t* payload = NULL;
Maybe names like kernel_length and kernel would be more consistent with other
places.

https://codereview.chromium.org/2485993002/diff/120001/runtime/bin/main.cc
File runtime/bin/main.cc (right):

https://codereview.chromium.org/2485993002/diff/120001/runtime/bin/main.cc#ne...
runtime/bin/main.cc:838: Dart_Handle result = Dart_LoadKernel(kernel_file,
kernel_length);
The TODO says do not read the kernel file again, does that also include
not having to do a Dat_LoadKernel here, i.e. I am wondering if the
isolate can be created with the kernel file similar to how we create
an isolate from an application snapshot.

https://codereview.chromium.org/2485993002/diff/120001/runtime/vm/bootstrap_n...
File runtime/vm/bootstrap_nocore.cc (right):

https://codereview.chromium.org/2485993002/diff/120001/runtime/vm/bootstrap_n...
runtime/vm/bootstrap_nocore.cc:15: #include "vm/object_store.h"
could object_store.h also go under !defined(DART_PRECOMPILER_RUNTIME) ? I guess
you did not want to add another #ifdef just for this one file.

Maybe
#if !defined(DART_PREC....)
#include "vm/class_finalizer.h"
#include ....
#include ....
#include "vm/object.h"
#include "vm/object_store.h"
#else
#include "vm/object.h"
#endif

might work if you want to eliminate object_store.h

[Vyacheslav Egorov (Google), 2016-11-16 12:47:46]

Thank you!

Landing

https://codereview.chromium.org/2485993002/diff/120001/runtime/bin/gen_snapsh...
File runtime/bin/gen_snapshot.cc (right):

https://codereview.chromium.org/2485993002/diff/120001/runtime/bin/gen_snapsh...
runtime/bin/gen_snapshot.cc:1270: const uint8_t* payload = NULL;
On 2016/11/16 05:49:34, siva wrote:
> Maybe names like kernel_length and kernel would be more consistent with other
> places.

Done.

https://codereview.chromium.org/2485993002/diff/120001/runtime/bin/main.cc
File runtime/bin/main.cc (right):

https://codereview.chromium.org/2485993002/diff/120001/runtime/bin/main.cc#ne...
runtime/bin/main.cc:838: Dart_Handle result = Dart_LoadKernel(kernel_file,
kernel_length);
On 2016/11/16 05:49:34, siva wrote:
> The TODO says do not read the kernel file again, does that also include
> not having to do a Dat_LoadKernel here, i.e. I am wondering if the
> isolate can be created with the kernel file similar to how we create
> an isolate from an application snapshot.

There is a difference between snapshots we have and Kernel in a sense that
Kernel is simultaneously application snapshot *and* isolate snapshot. That's why
it ends up loaded twice. 

We will fix it after landing.

https://codereview.chromium.org/2485993002/diff/120001/runtime/vm/bootstrap_n...
File runtime/vm/bootstrap_nocore.cc (right):

https://codereview.chromium.org/2485993002/diff/120001/runtime/vm/bootstrap_n...
runtime/vm/bootstrap_nocore.cc:15: #include "vm/object_store.h"
On 2016/11/16 05:49:34, siva wrote:
> could object_store.h also go under !defined(DART_PRECOMPILER_RUNTIME) ? I
guess
> you did not want to add another #ifdef just for this one file.
> 
> Maybe
> #if !defined(DART_PREC....)
> #include "vm/class_finalizer.h"
> #include ....
> #include ....
> #include "vm/object.h"
> #include "vm/object_store.h"
> #else
> #include "vm/object.h"
> #endif
> 
> might work if you want to eliminate object_store.h

Done.

[Vyacheslav Egorov (Google), 2016-11-16 12:56:24]

Description was changed from

==========
VM: Support bootstrapping core libraries from Kernel binaries instead of source.

BUG=http://dartbug.com/27590
==========

to

==========
VM: Support bootstrapping core libraries from Kernel binaries instead of source.

BUG=http://dartbug.com/27590
R=asiva@google.com

Committed:
https://github.com/dart-lang/sdk/commit/23fd1a184b393825f29444243780f3593ce0b3c1
==========

[Vyacheslav Egorov (Google), 2016-11-16 12:56:25]

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

[jeffbrown, 2016-11-16 14:50:39]

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

[jeffbrown, 2016-11-16 14:50:40]

I believe this change has broken the Dart build in Fuchsia.

FAILED:
obj/dart/runtime/vm/libdart_lib_nosnapshot_precompiled_runtime.bootstrap.o 
../../buildtools/toolchain/clang+llvm-x86_64-linux/bin/clang++ -MMD -MF
obj/dart/runtime/vm/libdart_lib_nosnapshot_precompiled_runtime.bootstrap.o.d
-DSYSROOT_VERSION=aefe73263dc37a2166e2686523eef4d804a39467 -DNDEBUG
-DDART_PRECOMPILED_RUNTIME -I../../dart/runtime -I../.. -Igen -g
--sysroot=../sysroot/x86_64-fuchsia --target=x86_64-fuchsia -Werror -Wall
-Wextra -Wno-unused-parameter -g -O0 -Werror -Wall -Wextra -Wno-unused-parameter
-Wnon-virtual-dtor -Wvla -Wno-conversion-null -Woverloaded-virtual -g3 -ggdb3
-fno-rtti -fno-exceptions -O3 -fvisibility-inlines-hidden -std=c++14
-fno-exceptions -fno-rtti -c ../../dart/runtime/vm/bootstrap.cc -o
obj/dart/runtime/vm/libdart_lib_nosnapshot_precompiled_runtime.bootstrap.o
../../dart/runtime/vm/bootstrap.cc:321:3: error: use of undeclared identifier
'kernel'
  kernel::Program* program =
  ^
../../dart/runtime/vm/bootstrap.cc:322:7: error: use of undeclared identifier
'ReadPrecompiledKernelFromBuffer'
      ReadPrecompiledKernelFromBuffer(buffer, buffer_size);
      ^
../../dart/runtime/vm/bootstrap.cc:343:3: error: use of undeclared identifier
'kernel'
  kernel::KernelReader reader(NULL, -1, true);
  ^
../../dart/runtime/vm/bootstrap.cc:349:7: error: use of undeclared identifier
'kernel'
      kernel::Library* kernel_library = program->libraries()[j];
      ^
../../dart/runtime/vm/bootstrap.cc:350:7: error: use of undeclared identifier
'kernel'
      kernel::String* uri = kernel_library->import_uri();
      ^
../../dart/runtime/vm/bootstrap.cc:353:9: error: use of undeclared identifier
'reader'; did you mean 'read'?
        reader.ReadLibrary(kernel_library);
        ^~~~~~
        read
../sysroot/x86_64-fuchsia/include/unistd.h:45:9: note: 'read' declared here
ssize_t read(int, void*, size_t);
        ^
../../dart/runtime/vm/bootstrap.cc:353:15: error: member reference base type
'ssize_t (int, void *, size_t)' (aka 'long (int, void *, unsigned long)') is not
a structure or union
        reader.ReadLibrary(kernel_library);
        ~~~~~~^~~~~~~~~~~~
7 errors generated.
[48/2016] CXX obj/dart/runtime/vm/libdart_vm.code_generator.o

[Cutch, 2016-11-17 23:05:36]

This broke Flutter.