it's all under input_sdk now:
lib -> the lib folder
private -> the dart:_* libs
patch -> the files with @patch
I imagine we'll try and focus changes on the last two
js_codegen.dart and patch_sdk.dart are the only human-changed files.
This also pulls in dart:isolate, which is depended on from one of the implementation libraries
This also moves dart:_* files back to `lib/_internal/compiler/js_lib/` because there's where libraries.dart points to, and hence Analyzer looks for them there. Alternatively, we could put them somewhere like `tool/input_sdk_internal` and then copy that file into the right path.
R=vsm@google.com
Review URL: https://codereview.chromium.org/955513008
There are a few examples of classes like this:
```dart
@patch
class StringBuffer {
... various @patch members ...
// no @patch here
void _writeString(str) { ... }
}
```
we need to merge in those members too
R=vsm@google.com
Review URL: https://codereview.chromium.org/955513007
Moves: test/sdk --> tool/input_sdk_src
Also moves: test/sdk/lib/_internal/js_lib --> tool/input_sdk_patch
we'll eventually need to customize that code
Adds tool/patch_sdk.dart, an offline transformation step that produces: test/generated_sdk
Essentially this merges the "external" declarations and the @patch syntactically. There's a comment in tool/patch_sdk.dart explaining the rationale behind this approach.
There's still *lots* to do in the generated code. This does none of that. The only new code is tool/patch_sdk.dart and the minimum changes to test/codegen_test.dart and js_codegen.dart to get test.sh running and debuggable.
Tracking bug for SDK is https://github.com/dart-lang/dart-dev-compiler/issues/58R=sigmund@google.com, vsm@google.com
Review URL: https://chromereviews.googleplex.com/157137013
Kevin Moore