Emulate compiling a source file in the context of an existing library. Add --debugger-compile flag …

Emulate compiling a source file in the context of an existing library. Add --debugger-compile flag that performs permissive dynamic calls on private members. Polish web_command.dart adding the ability to evaluate code in the context of an existing library.

BUG=
R=brianwilkerson@google.com, jmesserly@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/4f6ce11bc8aebf3e3234aa65a8cce5fdfc12c604

[Jacob, 2016-10-18 04:21:54]

jacobr@google.com changed reviewers:
+ jmesserly@google.com

[Jacob, 2016-10-18 04:21:55]

Sorry for the extra diff in operations.dart. My code editor is set to autorun
the formatter on safe. No existing code in that file was changed. Only new
methods ending in Repl 
were added.

Summary of this cl:
Emulate compiling a source file in the context of an existing library.
Add --debugger-compile flag that performs permissive dynamic calls on
private members.
Polish web_command.dart adding the ability to evaluate code in the context
of an existing library.

[Jacob, 2016-10-18 04:45:51]

I still owe a test for this code that verifies that privates outside of the
current library can be accessed and that compile output is generated when
--repl-compile is set even when the privates are accessed from a typed context.
Got ideas on the simplest way to write that test?

[Jennifer Messerly, 2016-10-18 18:46:00]

jmesserly@google.com changed reviewers:
+ brianwilkerson@google.com

[Jennifer Messerly, 2016-10-18 18:46:01]

LGTM for dev_comiler changes, but I'd be curious what Brian thinks about the
`Scope.PRIVATE_NAME_PREFIX = -1;` hack in web_command.dart -- how bad does that
look from Analyzer perspective? Is there a better way to accomplish this?

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/lib...
File pkg/dev_compiler/lib/src/compiler/code_generator.dart (right):

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/lib...
pkg/dev_compiler/lib/src/compiler/code_generator.dart:628:
assert(options.unsafeForceCompile || options.replCompile);
nice idea splitting this out into its own flag :)

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/lib...
File pkg/dev_compiler/lib/src/compiler/compiler.dart (right):

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/lib...
pkg/dev_compiler/lib/src/compiler/compiler.dart:172: ? (e) {
style: could we pull this out into its own function?

if (!options.unsafeForceCompile && errors.any(_isFatalError)) {
  ...
}


bool _isFatalError(AnalysisError e) {
  if (errorSeverity(context, e) != ErrorSeverity.ERROR) return false;

 // These errors are not fatal in the REPL compile mode [...]
 // [...]
 return !options.replCompile ||
      e.errorCode != StaticTypeWarningCode.UNDEFINED_GETTER &&
      e.errorCode != StaticTypeWarningCode.UNDEFINED_SETTER &&
      e.errorCode != StaticTypeWarningCode.UNDEFINED_METHOD;
}

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/too...
File pkg/dev_compiler/tool/input_sdk/private/ddc_runtime/operations.dart
(right):

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/too...
pkg/dev_compiler/tool/input_sdk/private/ddc_runtime/operations.dart:224: // We
didnt find a plausible alternate private symbol so just fall back
typo: "didn't"

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/web...
File pkg/dev_compiler/web/web_command.dart (right):

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/web...
pkg/dev_compiler/web/web_command.dart:147: throw "Unable to get library
element.";
do you know in what context this actually happens? or is it just defensive?
either way a comment would be helpful. 

In general throwing strings isn't great from a style perspective. Some kind of
Error (if it indicates a programming error) or an Exception (if it indicates a
runtime failure that can happen) is better.

https://chromiumcodereview.appspot.com/2423313002/diff/1/pkg/dev_compiler/web...
pkg/dev_compiler/web/web_command.dart:158: Scope.PRIVATE_NAME_PREFIX = -1;
Interesting. It seems better to add a feature explicitly to pkg/analyzer?
Otherwise I'd worry this could get broken or have other unintended effects.

[Brian Wilkerson, 2016-10-18 19:16:44]

lgtm

https://codereview.chromium.org/2423313002/diff/1/pkg/dev_compiler/web/web_co...
File pkg/dev_compiler/web/web_command.dart (right):

https://codereview.chromium.org/2423313002/diff/1/pkg/dev_compiler/web/web_co...
pkg/dev_compiler/web/web_command.dart:158: Scope.PRIVATE_NAME_PREFIX = -1;
I agree, this seems brittle. (I can't even guarantee that all code that deals
with private names uses this constant.) Unfortunately, adding the feature
probably isn't trivial (even though it's the better way to solve this).

What are the effects of not doing this? Obviously we'll get errors generated,
but does analyzer resolve the private name to what it would have been, or does
it just not resolve it?

https://codereview.chromium.org/2423313002/diff/1/pkg/dev_compiler/web/web_co...
pkg/dev_compiler/web/web_command.dart:169: // has a different directory than the
library we are pretending to be.
It might be better to get the URI of the imported library rather than
manipulating strings. I'm thinking of something like:

  importElement.importedLibrary.definingCompilationUnit.source.uri

but it's possible that that won't work well for your use case.

[Jacob, 2016-10-18 23:34:54]

Description was changed from

==========
Emulate compiling a source file in the context of an existing library. Add
--debugger-compile flag that performs permissive dynamic calls on private
members. Polish web_command.dart adding the ability to evaluate code in the
context of an existing library.

BUG=
==========

to

==========
Emulate compiling a source file in the context of an existing library. Add
--debugger-compile flag that performs permissive dynamic calls on private
members. Polish web_command.dart adding the ability to evaluate code in the
context of an existing library.

BUG=
R=brianwilkerson@google.com, jmesserly@google.com

Committed:
https://github.com/dart-lang/dev_compiler/commit/4f6ce11bc8aebf3e3234aa65a8cc...
==========

[Jacob, 2016-10-18 23:34:56]

Committed patchset #3 (id:40001) manually as
4f6ce11bc8aebf3e3234aa65a8cce5fdfc12c604 (presubmit successful).