Skip to content

Support the dev compiler #414

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.

Sign up for GitHub

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

Jump to bottom
Closed
nex3 opened this issue Mar 28, 2016 · 11 comments
Closed

Support the dev compiler #414

nex3 opened this issue Mar 28, 2016 · 11 comments
Labels
status-blocked Blocked from making progress by another (referenced) issue type-enhancement A request for a change that isn't a bug

Comments

@nex3
Copy link
Member

nex3 commented Mar 28, 2016 •
edited
Loading

We should eventually support compiling tests using the dev compiler—it will be faster, less monolithic, and hopefully more cacheable than dart2js.

This is currently blocked on getting test and all of its dependencies strong-mode clean.

Note that this issue is only tracking basic support—the only hard requirement is that test runs code compiled by the dev compiler. Once this lands, speed or modularity goals will be tracked elsewhere.
@nex3 nex3 added type-enhancement A request for a change that isn't a bug status-blocked Blocked from making progress by another (referenced) issue labels Mar 28, 2016
@nex3 nex3 added this to the 1.0.0 milestone Mar 28, 2016
@nex3 nex3 modified the milestones: Q2 2016, 1.0.0 Apr 13, 2016
@nex3 nex3 mentioned this issue May 6, 2016
Closed
@nex3
Copy link
Member Author

nex3 commented Jun 24, 2016

All the dependencies that get transitively imported by tests are now strong-mode clean, so this is unblocked.

@nex3 nex3 removed the status-blocked Blocked from making progress by another (referenced) issue label Jun 24, 2016
This was referenced Jul 27, 2016
Closed
Closed
@nex3 nex3 added the status-blocked Blocked from making progress by another (referenced) issue label Jul 27, 2016
This was referenced Jul 27, 2016
Closed
Closed
Closed
@nex3
Copy link
Member Author

nex3 commented Jul 28, 2016 •
edited
Loading

Blocking issues (updated 28 June 2017):

@nex3 nex3 mentioned this issue Aug 2, 2016
Closed
@nex3 nex3 modified the milestone: Q2 2016 Sep 1, 2016
This was referenced Sep 6, 2016
Closed
Closed
Closed
Closed
Closed
@nex3
Copy link
Member Author

nex3 commented Sep 30, 2016

FYI, I could probably begin work on this with just dart-lang/sdk#27267, dart-lang/sdk#27264, and dart-lang/sdk#27001. I wouldn't be able to release that work, but I could probably get something committed outside of the UI.

@dgrove
Copy link
Contributor

dgrove commented Oct 6, 2016

@vsmenon what are your thoughts on those issues?

@vsmenon
Copy link
Member

vsmenon commented Oct 6, 2016

What's our package:test goal for this Q?

  • Support DDC via bazel?
  • Support DDC without bazel?
  • Support both?

If only the former, are we blocked on anything? All the hooks we're using internally should just apply.

@dgrove
Copy link
Contributor

dgrove commented Oct 6, 2016

both, but we could start with bazel.

On Thu, Oct 6, 2016 at 8:39 AM, vsmenon [email protected] wrote:

What's our package:test goal for this Q?

  • Support DDC via bazel?
  • Support DDC without bazel?
  • Support both?

If only the former, are we blocked on anything? All the hooks we're using
internally should just apply.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#414 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACAsW0hnkPNYgmEfN4oNqK65k_kedrfYks5qxRYVgaJpZM4H6Pc0
.

@vsmenon
Copy link
Member

vsmenon commented Oct 6, 2016

Looking @nex3 's list above, DDC relies on the analyzer to resolve URI, load sources. We might get some of that for free with the refactoring @bwilkerson is looking into here:

dart-lang/sdk#27511

@bwilkerson - does analyzer support general URIs?

The last three issues are DDC though - we could use some help on that if it needs to get done soon.

@nex3
Copy link
Member Author

nex3 commented Oct 6, 2016

My intention was to start on non-Bazel support. I don't think we have a clear enough Bazel story yet to make it practical to work on it.

@skybrian
Copy link

I'm curious about why http or data URI's are needed. It seems unlikely that any tests are using those URI's?

@nex3
Copy link
Member Author

nex3 commented Dec 15, 2016 •
edited
Loading

The test package uses them as part of its compilation process (and also part of the language spec).

@nex3 nex3 mentioned this issue Jun 20, 2017
Closed
@nex3 nex3 mentioned this issue Sep 21, 2017
Merged
nex3 added a commit to dart-archive/async that referenced this issue Sep 21, 2017
@nex3
Skip typed_wrapper/stream_test
e39e4be 
We can't test this in 2.0 runtime semantics until test supports a
2.0-compatible platform (dart-lang/test#414).

Closes #35
nex3 added a commit to dart-archive/async that referenced this issue Sep 22, 2017
@nex3
Skip typed_wrapper/stream_test (#38)
b4f3a98 
We can't test this in 2.0 runtime semantics until test supports a
2.0-compatible platform (dart-lang/test#414).

Closes #35
@natebosch
Copy link
Member

The supported way to use DDC is build_runner. We don't have plans to invoke DDC directly from test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status-blocked Blocked from making progress by another (referenced) issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@nex3 @skybrian @dgrove @vsmenon @natebosch