[framework] dont null assert in _debugVerifyIllFatedPopulation

[jonahwilliams]

If you run the tests in profile mode, this will fail due to the null check. Since we don't explicitly disallow profile mode in tests, I would prefer to keep it working - and if we decided to stop supporting it that can be an intention rather than accidental decision

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[jonahwilliams]

@Hixie for lack of tests....

[Hixie]

const?

[jonahwilliams]

done

[Hixie]

If you want profile builds to be testable, I strongly recommend actually testing it. Right now they only work by pure chance (and sometimes don't work because we assume e.g. that kDebugMode matches when assert() is called). The only reason they work at all right now is that Google's internal tests rely on it in a couple of places. Several times we've broken those tests by mistake. If those tests go away (and I think that's quite possible) then the next time we break it we may not notice.

[jonahwilliams]

Fair enough - I think the plan might be (@dnfield ) to remove support for profile mode with asserts. I think the challenge with testing this configuration is that we may not have any tooling in flutter/flutter that supports building profile with asserts enabled. (at least not since I last looked at the tool..)

[dnfield]

I filed #96552 to track

[jonahwilliams]

I could write a devicelab test that asserts that it works, then @dnfield could later change it to assert failure.

[jonahwilliams]

actually I don't need devicelab, I can use a similar hack to test_release. tests added

[jonahwilliams]

Without the change to framework.dart, the test fails with:

PS C:\Users\Jonah\flutter\packages\flutter> flutter test --dart-define=dart.vm.profile=true .\test_profile\
00:05 +0: Can build widget tree in profile mode with asserts enabled
══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
════════════════════════════════════════════════════════════════════════════════════════════════════
══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
════════════════════════════════════════════════════════════════════════════════════════════════════
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
════════════════════════════════════════════════════════════════════════════════════════════════════
00:05 +0 -1: Can build widget tree in profile mode with asserts enabled [E]
  Test failed. See exception logs above.
  The test description was: Can build widget tree in profile mode with asserts enabled

[dnfield]

LGTM until we can have a better way to enforce what modes unit tests are run in.

[jonahwilliams]

Mac_android run_release_test is hitting an infra failure, known issue?

[dnfield]

@CaseyHillers or @keyonghan might know (https://ci.chromium.org/ui/p/flutter/builders/try/Mac_android%20run_release_test/18/overview). I triggered a rerun.

[CaseyHillers]

@CaseyHillers or @keyonghan might know (https://ci.chromium.org/ui/p/flutter/builders/try/Mac_android%20run_release_test/18/overview). I triggered a rerun.

I filed #96672 to the ticket queue. If you don't need Mac_android coverage, feel free to ack it and submit it to see what CI says. I'll look into getting a few extra devices added to the try pool so one device doesn't control presubmit.

[jonahwilliams]

cool, thank you @CaseyHillers !