Removes dartc reliance on its own libraries, now can be targeted at any implementation's libraries

Removes dartc reliance on its own libraries, now can be targeted at any implementation's libraries 

Adds a new cmdline flags

--dart-sdk to point it at a directory where the dart library files are staged 
--platform the name of the platform {dartium, vm, frog, dart2js} 
to target with the analyzer

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

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

[zundel, 2012-03-26 22:59:56]

No renaming of dartc in this CL.  This CL is essentially limited to removing the
dartc private system libraries, and migrating the Editor's way of mapping
dart:urls via a properties file into the static analyzer.

Peter and I discussed moving these properties files to another format that could
be shared by all implementations - maybe Dart?  He's already proposed a mapping
for dart2js.  We can iterate on this later.

@dgrove: This change touches the create_sdk.py script and adds some files to the
SDK.  The 'import_<platform>.config' files describe the mapping for each
platform.  Could you please review those changes?

@brianwilkerson: could you look at the editor changes?

@scheglov: could you look at the dartc changes?

[dgrove, 2012-03-26 23:21:56]

https://chromiumcodereview.appspot.com/9860009/diff/4001/lib/import_any.config
File lib/import_any.config (left):

https://chromiumcodereview.appspot.com/9860009/diff/4001/lib/import_any.confi...
lib/import_any.config:39: dart\:isolate  =
dart-sdk/lib/isolate/isolate_compiler.dart
Can we please put these configs in their own directory inside lib? (e.g.
lib/config/...)

https://chromiumcodereview.appspot.com/9860009/diff/4001/lib/isolate/isolate_...
File lib/isolate/isolate_runtime.dart (right):

https://chromiumcodereview.appspot.com/9860009/diff/4001/lib/isolate/isolate_...
lib/isolate/isolate_runtime.dart:5: #source("isolate_api.dart");
The rename above (from lib/implementation/object.js to
lib/isolate/isolate_runtime.dart) doesn't make sense.

https://chromiumcodereview.appspot.com/9860009/diff/4001/tools/create_sdk.py
File tools/create_sdk.py (right):

https://chromiumcodereview.appspot.com/9860009/diff/4001/tools/create_sdk.py#...
tools/create_sdk.py:51: # ....analysis/
I don't believe this is the right place for this. analysis is not parallel to
bin/lib/util.  Can you please put this into either bin or util?

https://chromiumcodereview.appspot.com/9860009/diff/4001/tools/create_sdk.py#...
tools/create_sdk.py:310: isolate_runtime_src = join('runtime', 'lib',
'isolate.dart')
I think you want join(HOME, 'runtime', 'lib' , ...)

https://chromiumcodereview.appspot.com/9860009/diff/4001/tools/create_sdk.py#...
tools/create_sdk.py:312: copyfile(isolate_runtime_src, isolate_runtime_dest)
Why is this needed? All of the classes in isolate.dart are private. In general,
I hope that we can simplify create_sdk.py, rather than making it do more magic.

[zundel, 2012-03-27 00:38:11]

http://codereview.chromium.org/9860009/diff/4001/lib/import_any.config
File lib/import_any.config (left):

http://codereview.chromium.org/9860009/diff/4001/lib/import_any.config#oldcode39
lib/import_any.config:39: dart\:isolate  =
dart-sdk/lib/isolate/isolate_compiler.dart
On 2012/03/26 23:21:56, dgrove wrote:
> Can we please put these configs in their own directory inside lib? (e.g.
> lib/config/...)

Done.

http://codereview.chromium.org/9860009/diff/4001/lib/isolate/isolate_runtime....
File lib/isolate/isolate_runtime.dart (right):

http://codereview.chromium.org/9860009/diff/4001/lib/isolate/isolate_runtime....
lib/isolate/isolate_runtime.dart:5: #source("isolate_api.dart");
On 2012/03/26 23:21:56, dgrove wrote:
> The rename above (from lib/implementation/object.js to
> lib/isolate/isolate_runtime.dart) doesn't make sense.

The 'object.js' is just the revision control system trying to be smarter than it
really is.  Its a new file, not a copy.

I created this file meant to be the main import for the vm platform  for the
dart:isolate import.  There was no vm implementation in the sdk before.

http://codereview.chromium.org/9860009/diff/4001/tools/create_sdk.py
File tools/create_sdk.py (right):

http://codereview.chromium.org/9860009/diff/4001/tools/create_sdk.py#newcode51
tools/create_sdk.py:51: # ....analysis/
On 2012/03/26 23:21:56, dgrove wrote:
> I don't believe this is the right place for this. analysis is not parallel to
> bin/lib/util.  Can you please put this into either bin or util?

Oops, this was from another CL before our latest discussions.  Removed.

http://codereview.chromium.org/9860009/diff/4001/tools/create_sdk.py#newcode310
tools/create_sdk.py:310: isolate_runtime_src = join('runtime', 'lib',
'isolate.dart')
On 2012/03/26 23:21:56, dgrove wrote:
> I think you want join(HOME, 'runtime', 'lib' , ...)

Done.

http://codereview.chromium.org/9860009/diff/4001/tools/create_sdk.py#newcode312
tools/create_sdk.py:312: copyfile(isolate_runtime_src, isolate_runtime_dest)
On 2012/03/26 23:21:56, dgrove wrote:
> Why is this needed? All of the classes in isolate.dart are private. In
general,
> I hope that we can simplify create_sdk.py, rather than making it do more
magic.

I think we need this file to resolve the VM version of the isolate API.  We
didn't have one that worked for the VM before so the editor was using frog's
version.  If you look you'll see all of frog's private laundry under
lib/isolate/frog/

The file isolate_api.dart defines an interface with 'default' clauses that are
the implementation classes.  Those classes are found in this file
(runtime/isolate.dart) for the VM.

[dgrove, 2012-03-27 04:29:27]

http://codereview.chromium.org/9860009/diff/4001/tools/create_sdk.py
File tools/create_sdk.py (right):

http://codereview.chromium.org/9860009/diff/4001/tools/create_sdk.py#newcode312
tools/create_sdk.py:312: copyfile(isolate_runtime_src, isolate_runtime_dest)
Got it. 
On 2012/03/27 00:38:12, zundel wrote:
> On 2012/03/26 23:21:56, dgrove wrote:
> > Why is this needed? All of the classes in isolate.dart are private. In
> general,
> > I hope that we can simplify create_sdk.py, rather than making it do more
> magic.
> 
> I think we need this file to resolve the VM version of the isolate API.  We
> didn't have one that worked for the VM before so the editor was using frog's
> version.  If you look you'll see all of frog's private laundry under
> lib/isolate/frog/
> 
> The file isolate_api.dart defines an interface with 'default' clauses that are
> the implementation classes.  Those classes are found in this file
> (runtime/isolate.dart) for the VM.

http://codereview.chromium.org/9860009/diff/2003/lib/configs/import_vm.config
File lib/configs/import_vm.config (left):

http://codereview.chromium.org/9860009/diff/2003/lib/configs/import_vm.config...
lib/configs/import_vm.config:32: dart\:         = dart-sdk/lib
Can these be in lib/config (rather than configs)? We've stayed with singular
names for other directories in the SDK (lib, util).

[scheglov, 2012-03-27 06:06:06]

LGTM for DArtC changes

https://chromiumcodereview.appspot.com/9860009/diff/2003/compiler/java/com/go...
File compiler/java/com/google/dart/compiler/SystemLibraryManager.java (right):

https://chromiumcodereview.appspot.com/9860009/diff/2003/compiler/java/com/go...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:179: * to
either a "file:" or "jar:" URI (e.g.
"jar:file:/some/install/director/dom.jar!/dom.dart")
Do we still support "jar:"?

https://chromiumcodereview.appspot.com/9860009/diff/2003/compiler/java/com/go...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:249: continue;
Good for safety, but addLib() already checks libFile.isFile().

https://chromiumcodereview.appspot.com/9860009/diff/2003/compiler/java/com/go...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:251:
//longToShortUriMap.put(shortUri, dartFile.toURI());
do you need this?

[zundel, 2012-03-27 14:00:53]

PTAL.

http://codereview.chromium.org/9860009/diff/2003/compiler/java/com/google/dar...
File compiler/java/com/google/dart/compiler/SystemLibraryManager.java (right):

http://codereview.chromium.org/9860009/diff/2003/compiler/java/com/google/dar...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:179: * to
either a "file:" or "jar:" URI (e.g.
"jar:file:/some/install/director/dom.jar!/dom.dart")
On 2012/03/27 06:06:06, scheglov wrote:
> Do we still support "jar:"?

No. Updated comment.

http://codereview.chromium.org/9860009/diff/2003/compiler/java/com/google/dar...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:249: continue;
On 2012/03/27 06:06:06, scheglov wrote:
> Good for safety, but addLib() already checks libFile.isFile().
Thanks for pointing this out.  I left it in place, but modified addLib()

In this case, we are scanning the directory for libraries, I think its OK to
skip it silently.  In the other case, where an explicit mapping is supposed to
be there, I wanted a warning, so I added an exception.

http://codereview.chromium.org/9860009/diff/2003/compiler/java/com/google/dar...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:251:
//longToShortUriMap.put(shortUri, dartFile.toURI());
On 2012/03/27 06:06:06, scheglov wrote:
> do you need this?
Removed.

http://codereview.chromium.org/9860009/diff/2003/lib/configs/import_vm.config
File lib/configs/import_vm.config (left):

http://codereview.chromium.org/9860009/diff/2003/lib/configs/import_vm.config...
lib/configs/import_vm.config:32: dart\:         = dart-sdk/lib
On 2012/03/27 04:29:27, dgrove wrote:
> Can these be in lib/config (rather than configs)? We've stayed with singular
> names for other directories in the SDK (lib, util).

Done.

[Brian Wilkerson, 2012-03-27 14:10:30]

LGTM

https://chromiumcodereview.appspot.com/9860009/diff/5066/editor/tools/plugins...
File
editor/tools/plugins/com.google.dart.tools.core/src/com/google/dart/tools/core/internal/model/EditorLibraryManager.java
(right):

https://chromiumcodereview.appspot.com/9860009/diff/5066/editor/tools/plugins...
editor/tools/plugins/com.google.dart.tools.core/src/com/google/dart/tools/core/internal/model/EditorLibraryManager.java:27:
public class EditorLibraryManager extends SystemLibraryManager {
Is there a reason for keeping this class, or will we get rid of it in a future
CL?

https://chromiumcodereview.appspot.com/9860009/diff/5066/editor/tools/plugins...
File
editor/tools/plugins/com.google.dart.tools.core_test/src/com/google/dart/tools/core/internal/model/SystemLibraryManagerProviderDartCTest.java
(right):

https://chromiumcodereview.appspot.com/9860009/diff/5066/editor/tools/plugins...
editor/tools/plugins/com.google.dart.tools.core_test/src/com/google/dart/tools/core/internal/model/SystemLibraryManagerProviderDartCTest.java:2:
* Copyright 2011 Dart project authors.
nit: copyright

https://chromiumcodereview.appspot.com/9860009/diff/5066/editor/tools/plugins...
File
editor/tools/plugins/com.google.dart.tools.core_test/src/com/google/dart/tools/core/internal/model/SystemLibraryManagerProviderVmTest.java
(right):

https://chromiumcodereview.appspot.com/9860009/diff/5066/editor/tools/plugins...
editor/tools/plugins/com.google.dart.tools.core_test/src/com/google/dart/tools/core/internal/model/SystemLibraryManagerProviderVmTest.java:2:
* Copyright 2011 Dart project authors.
nit: copyright

[scheglov, 2012-03-27 14:19:54]

LGTM

[dgrove, 2012-03-27 15:18:56]

lgtm

[zundel, 2012-03-27 19:39:28]

I tried to land this change and had to back out.  The issue is that this uses
some targets not currently run on the dartc buildbots, so I'm working with the
build team to switch the configuration over.

[zundel, 2012-03-27 19:39:28]

I tried to land this change and had to back out.  The issue is that this uses
some targets not currently run on the dartc buildbots, so I'm working with the
build team to switch the configuration over.

[danrubel, 2012-03-28 16:40:59]

https://chromiumcodereview.appspot.com/9860009/diff/5066/compiler/java/com/go...
File compiler/java/com/google/dart/compiler/SystemLibraryManager.java (right):

https://chromiumcodereview.appspot.com/9860009/diff/5066/compiler/java/com/go...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:69: private
final File sdkLibPath;
Perhaps rename to sdkLibDir?
I saw the "Path" suffix and assumed it was a string not a file.

https://chromiumcodereview.appspot.com/9860009/diff/5066/compiler/java/com/go...
File
compiler/java/com/google/dart/compiler/resolver/CoreTypeProviderImplementation.java
(right):

https://chromiumcodereview.appspot.com/9860009/diff/5066/compiler/java/com/go...
compiler/java/com/google/dart/compiler/resolver/CoreTypeProviderImplementation.java:52:
"ListImplementation", "GrowableObjectArray", "ListFactory"}, scope, listener);
Can we or should we push some of these into the import.config file rather than
having a hard coded list of possibilities here?

[zundel, 2012-03-28 18:13:24]

https://chromiumcodereview.appspot.com/9860009/diff/5066/compiler/java/com/go...
File compiler/java/com/google/dart/compiler/SystemLibraryManager.java (right):

https://chromiumcodereview.appspot.com/9860009/diff/5066/compiler/java/com/go...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:69: private
final File sdkLibPath;
On 2012/03/28 16:41:00, danrubel wrote:
> Perhaps rename to sdkLibDir?
> I saw the "Path" suffix and assumed it was a string not a file.

I've already committed it. Next time I'm in there I'll rename it (unless someone
else gets to it first)

https://chromiumcodereview.appspot.com/9860009/diff/5066/compiler/java/com/go...
File
compiler/java/com/google/dart/compiler/resolver/CoreTypeProviderImplementation.java
(right):

https://chromiumcodereview.appspot.com/9860009/diff/5066/compiler/java/com/go...
compiler/java/com/google/dart/compiler/resolver/CoreTypeProviderImplementation.java:52:
"ListImplementation", "GrowableObjectArray", "ListFactory"}, scope, listener);
On 2012/03/28 16:41:00, danrubel wrote:
> Can we or should we push some of these into the import.config file rather than
> having a hard coded list of possibilities here?

Possibly. We could also look at the Element for 'List' and pull out the class
listed in the 'default' clause of that interface.  I'm wondering if
'ListFactory' wouldn't just work for all of them.  

But it isn't just this type, mapLiteralType too (we just got lucky)its all of
the typed literals. Probably we can go back to using the "List", "Map", and
"String" interfaces, since we aren't using this class to generate code anymore. 
I filed a bug to investigate later.

http://code.google.com/p/dart/issues/detail?id=2335