Tightens up some typing issues (mostly in the collections) to eliminate some casts and dynamic calls. Also adds inference through parenthesized expressions.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1122313002
This fixes all of the static errors from generating the SDK except those in the _interceptors library, and a set of errors associated with checks of the form (v is E) for generic type parameter E. Most of the fixes consist of adding missing generic parameters, or making overrides consistent. There are a few fixes to resolve issues around code that moved implicitly between hidden implementation classes and their public API classes, and some other miscellaneous fixes.
All of my changes are in the tool/input_sdk directory - the rest of the diff is generated code.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1112403004
We were tracking currentClass for no real reason.
Also attempted to discern what visitSimpleIdentifier was actually doing. It now prefers the original element (the "field" not the synthetic getter/setter) whenever possible. Previously was a mismash.
This little change tripped on the (larger, not fixed yet) issue #138 ... but I think I found a way around the issue for now, by tweaking the private TypeDataArray class.
R=jacobr@google.com
Review URL: https://codereview.chromium.org/1095563003
essentially verify the expected HTML in the test
this tripped on an interesting issue, we have two ways of computing MD5 hashes that produce different answers. I left that as a TODO.
R=jacobr@google.com
Review URL: https://codereview.chromium.org/1056613002
Now running test.sh under Travis (actually script has been renamed to
`tool/build_and_test.sh` since it built and tested :). Keeping
`test.sh` as alias to build_and_test.sh in case people are used to
using it in the test directory.
Also removed `_visitOrEmpty` to resolve the following analyzer hint (so
that tests would pass):
> [hint] The method '_visitOrEmpty' is not used
(/Users/chalin/git/dev_compiler/lib/src/codegen/js_codegen.dart, line
2028, col 16)
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
Vijay Menon