Skip to content

Conversation

@gspencergoog
Copy link
Contributor

@gspencergoog gspencergoog commented Feb 4, 2019

Before this, we had several places where an isReleaseMode was defined, all with the same definition. This just makes it more broadly visible to allow our users to use it, as well as creating debug and profile versions, and adding a device lab test for it.

Since this is a const value, this makes it possible for a developer to easily mark blocks that can be removed at AOT compile time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (false) { dead(); } isn't tree shaking.

Copy link
Contributor Author

@gspencergoog gspencergoog Feb 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saying that in your example the code is not being removed? (and if so, why isn't it?)

Or are you saying that my use of "tree shaking" is just the incorrect term for removing blocks like that at compile time?

Also, this:

static const Foo foo = Foo(debugName: true ? null : 'Name');

would not include the string 'Name' in the compiled output, right?

@gspencergoog gspencergoog force-pushed the release_mode branch 6 times, most recently from a6a5de7 to 3e30af5 Compare February 5, 2019 17:41
@gspencergoog gspencergoog changed the title Make a kReleaseMode constant that is public. Make a kReleaseMode, kDebugMode, kProfileMode constants that are public. Feb 5, 2019
@goderbauer goderbauer added the framework flutter/packages/flutter repository. See also f: labels. label Feb 5, 2019
@jonahwilliams
Copy link
Contributor

We need a way to test that these work properly

@gspencergoog
Copy link
Contributor Author

Yeah... Do we currently have a test that builds all the different configurations (all five modes, apk and ios, and simulator/emulator)? I don't know of one. Not sure I want to be the first, but it would be helpful to have even without these variables needing testing.

@jonahwilliams
Copy link
Contributor

If we're providing a contract like "guarantee to remove code in x-mode" we need to test it.

@gspencergoog
Copy link
Contributor Author

Yeah, I agree. Kinda daunting though.

@gspencergoog
Copy link
Contributor Author

gspencergoog commented Feb 6, 2019

Actually, it wasn't too bad. I have a devicelab test that will run in all five modes. Now I just need to fix the fact that debug and both dynamic modes don't seem to pick up the -D definitions on the frontend compiler's command line.

@jonahwilliams
Copy link
Contributor

@jonahwilliams
Copy link
Contributor

Pass or not pass the flag, that is

@gspencergoog gspencergoog changed the title Make a kReleaseMode, kDebugMode, kProfileMode constants that are public. Make kReleaseMode, kDebugMode, and kProfileMode constants that are public. Feb 6, 2019
@gspencergoog
Copy link
Contributor Author

Good idea @jonahwilliams, but no, that doesn't make any difference, unfortunately.

@gspencergoog gspencergoog force-pushed the release_mode branch 4 times, most recently from a6a398b to aabe836 Compare February 6, 2019 02:56
@gspencergoog gspencergoog changed the title Make kReleaseMode, kDebugMode, and kProfileMode constants that are public. Make a kReleaseMode constant that is public. Feb 6, 2019
@gspencergoog
Copy link
Contributor Author

OK, I give up on making kDebugMode and kProfileMode work properly.

I'm just going to define kReleaseMode in terms of the existing dart.vm.product define, and remove the debug and profile ones. I kept the test, and it tests to make sure that kReleaseMode does what it should. The truth is, kReleaseMode is the one that is the most useful anyhow: you can use assert if you want to do something in debug mode, and profile mode can use the "profile()" method.

Not great, but a little cleaner than it was...

@gspencergoog gspencergoog force-pushed the release_mode branch 2 times, most recently from b3325f1 to eff0974 Compare February 6, 2019 16:26
Copy link
Member

@goderbauer goderbauer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

/// if (!const bool.fromEnvironment('dart.vm.product')) {
// // Register your service extension here.
// }
/// void myRegistrationFunction() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we include the foundation/constant.dart import in this example to make clear where the constant is coming from?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, this is already in the foundation library (which is where the constant is defined). I added a comment in the example to indicate where it is defined instead, since I'm worried that the sample analyzer will complain if I import it again.

Copy link
Contributor

@jonahwilliams jonahwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@gspencergoog gspencergoog merged commit da27f62 into flutter:master Feb 6, 2019
kangwang1988 pushed a commit to XianyuTech/flutter that referenced this pull request Feb 12, 2019
Before this, we had several places where an isReleaseMode was defined, all with the same definition. This just makes it more broadly visible to allow our users to use it, as well as creating debug and profile versions, and adding a device lab test for it.

Since this is a const value, this makes it possible for a developer to easily mark blocks that can be removed at AOT compile time.
@gspencergoog gspencergoog deleted the release_mode branch February 12, 2019 17:36
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

framework flutter/packages/flutter repository. See also f: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants