Skip to content
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

Add support for --compiler flag #1903

Merged
merged 26 commits into from
Feb 14, 2023
Merged

Add support for --compiler flag #1903

merged 26 commits into from
Feb 14, 2023

Conversation

jakemac53
Copy link
Contributor

@jakemac53 jakemac53 commented Feb 3, 2023

Closes #1776

Overview

  • Adds a new Compiler class, similar to the Runtime class, but it doesn't support custom ones (at least for now).
    • This is exported from package:test_api/backend.dart
  • Adds required defaultCompiler and supportedCompilers fields to Runtime. This is breaking for custom runtimes.
    • Platforms will not be asked to load tests for compilers that the associated runtimes don't support.
  • Add compiler field to SuitePlatform. This is how platforms get access to compiler configuration. It means there is no API breaking change for platforms, but they do need to be updated to support the configuration.
    • This is breaking, the compiler parameter is required when creating a SuitePlatform, although it is nullable, but defaults to the default compiler for the runtime. This is mostly for convenience and up for discussion.
  • Adds support in all platforms to respect the compiler option.
    • The vm platform supports the source compiler which is roughly equivalent to --use-data-isolate-strategy. The --use-data-isolate-strategy flag is now just an alias for --compiler source and it it deprecated/hidden.
      • We would call this compiler none but we already have OS.none, so it would conflict in boolean selectors.
  • Adds a CompilerSelection class similar to RuntimeSelection, used by SuiteConfig to track the selected compiler(s).
  • Adds new compilerSelections field to SuiteConfig.
  • Adds the compilers to the valid boolean selectors, this makes them usable in TestOn etc.

Still to do

  • Consider merging the wasm support into the regular browser platform. Unclear if we want to do this now or wait. We could do it and then just call the compiler --experimental-dart2wasm?
  • Write tests
  • Update changelogs/pubpsecs
  • Write docs
  • Probably drop or deprecate --use-data-isolate-strategy

@jakemac53 jakemac53 requested a review from natebosch February 3, 2023 20:13
jakemac53 and others added 13 commits February 3, 2023 22:34
Co-authored-by: Nate Bosch <nbosch@google.com>
This updates the `--compiler` flag to support a syntax like this `--compiler [<platform-selector>:]<compiler>`.

This is quite handy because it allows for instance `-c web:dart2js` or `-c chrome:dart2wasm` etc. It ultimately does not increase the complexity a lot either.
This just fixes the existing tests in preparation for adding new tests.
@jakemac53
Copy link
Contributor Author

@natebosch I forgot to send it as a PR, but please take a look at 3748acb which updates the pubspecs and changelogs

@jakemac53
Copy link
Contributor Author

Ok, this PR is ready for a final review now. As discussed offline we decided to leave the wasm support as is for now, given that chrome requires extra special flags to run in that mode, it makes sense to be a separate platform still.

@jakemac53 jakemac53 merged commit de40c1c into master Feb 14, 2023
@jakemac53 jakemac53 deleted the compiler branch February 14, 2023 21:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for specifying a compiler separately from a platform
2 participants