Skip to content

Define "dart.library.mirrors" and "dart.library.isolate" as false in dartdevc #30540

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
munificent opened this issue Aug 24, 2017 · 6 comments
Closed
Assignees
Milestone

Comments

@munificent
Copy link
Member

Since Dart 2.0 does not support those libraries on the web (#30538), the fromEnvironment() flags for those should return false.

@jmesserly
Copy link

I discovered that dart:html and dart:io import dart:isolate.

HTML only exists in dart4web, so we can remove that dependency and refactor APIs that use it.
dart:io is importable, but throws on dart4web. I'm not sure if we want dart:isolate imports to be an error at compile time, or an error at runtime. Advice? @vsmenon

See also #32293 (disable dart:isolate in DDC)

@vsmenon
Copy link
Member

vsmenon commented Feb 24, 2018

I was thinking compile time error. @sigmundch @kevmoo is that consistent with your understanding?

@kevmoo
Copy link
Member

kevmoo commented Feb 24, 2018

🤷‍♂️

@sigmundch
Copy link
Member

Agree it should be a compile-time error.

It seems like the only API that uses dart:isolate from dart:html is spawnDomUri.

However, I don't believe we can ban importing dart:io at this time. That is currently needed to support package:http for a bit longer (we had to go out of our way to allow it in dart2js temporarily). Two ideas come to mind:

  • change the dart:io implementation entirely for dart4web to make it super lean and only expose what pacakge:http needs
  • temporarily use a whitelist to allow importing dart:isolate from dart:* libraries (practically treating it like if it were an internal dart:_isolate library).

I currently prefer the latter. We could also do the latter by introducing an actual dart:_isolate library, reexporting it from dart:isolate, and change dart:io and dart:html to import the internal. Then we can unconditionally make it invalid to import the public dart:isolate library.

Thoughts?

@jmesserly
Copy link

Yeah, dart:html is very easy to fix (change Future<SendPort> to Future for a method that throws an unimplemented error anyways :)

I think I have a fix for dart:io as well. It turned out the only usage was SendPort, for one unused field, and one private class/private method for the VM. I have removed it from the API signature of that private class in dart:io. Testing it out now. :)

@jmesserly
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants