Skip to content

F
Front-End
Switch branch/tag
  1. 13 Mar, 2024 11 commits
  3. 12 Mar, 2024 22 commits
  5. 11 Mar, 2024 7 commits
    • auto-submit[bot]'s avatar
      Reverts "Fail tests on exceptions raised after test completed (#144706)" (#144970) · 49f45d20
      auto-submit[bot] authored 
      Reverts: flutter/flutter#144706
Initiated by: gspencergoog
Reason for reverting: This has broken the tree because some tests are still failing post completion. This particular one looks like it might have to do with a gold image not existing.
Original PR Author: goderbauer

Reviewed By: {Piinks}

This change reverts the following previous change:
A test was failing silently because of this (see https://github.com/flutter/flutter/issues/144353 and fixed in https://github.com/flutter/flutter/pull/144709). The failure went undetected for months. Ideally, this should have been a regular non-silent failure. This change makes that so. `package:test` can properly handle reported exceptions outside of test cases. With this change, the test fails as follows:

```
00:03 +82: Smoke test material/color_scheme/dynamic_content_color.0.dart
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following assertion was thrown running a test (but after the test had completed):
setState() called after dispose(): _DynamicColorExampleState#1cd37(lifecycle state: defunct, not
mounted)
This error happens if you call setState() on a State object for a widget that no longer appears in
the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error
can occur when code calls setState() from a timer or an animation callback.
The preferred solution is to cancel the timer or stop listening to the animation in the dispose()
callback. Another solution is to check the "mounted" property of this object before calling
setState() to ensure the object is still in the tree.
This error might indicate a memory leak if setState() is being called because another object is
retaining a reference to this State object after it has been removed from the tree. To avoid memory
leaks, consider breaking the reference to this object during dispose().

When the exception was thrown, this was the stack:
#0      State.setState.<anonymous closure> (package:flutter/src/widgets/framework.dart:1167:9)
#1      State.setState (package:flutter/src/widgets/framework.dart:1202:6)
#2      _DynamicColorExampleState._updateImage (package:flutter_api_samples/material/color_scheme/dynamic_content_color.0.dart:191:5)
<asynchronous suspension>
════════════════════════════════════════════════════════════════════════════════════════════════════
00:03 +81 -1: Smoke test material/context_menu/context_menu_controller.0.dart
00:03 +81 -1: Smoke test material/color_scheme/dynamic_content_color.0.dart [E]
  Test failed. See exception logs above.
  The test description was: Smoke test material/color_scheme/dynamic_content_color.0.dart
  
  This test failed after it had already completed.
  Make sure to use a matching library which informs the test runner
  of pending async work.
```
      49f45d20
    • Polina Cherkasova's avatar
      Make TabController communicating creation in constructor. (#144912) · e66811ae
      Polina Cherkasova authored 
      Contributes to https://github.com/flutter/flutter/issues/144910
      e66811ae
    • Michael Goderbauer's avatar
      Fail tests on exceptions raised after test completed (#144706) · 91cccc8e
      Michael Goderbauer authored 
      A test was failing silently because of this (see
https://github.com/flutter/flutter/issues/144353 and fixed in
https://github.com/flutter/flutter/pull/144709). The failure went
undetected for months. Ideally, this should have been a regular
non-silent failure. This change makes that so. `package:test` can
properly handle reported exceptions outside of test cases. With this
change, the test fails as follows:

```
00:03 +82: Smoke test material/color_scheme/dynamic_content_color.0.dart
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following assertion was thrown running a test (but after the test had completed):
setState() called after dispose(): _DynamicColorExampleState#1cd37(lifecycle state: defunct, not
mounted)
This error happens if you call setState() on a State object for a widget that no longer appears in
the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error
can occur when code calls setState() from a timer or an animation callback.
The preferred solution is to cancel the timer or stop listening to the animation in the dispose()
callback. Another solution is to check the "mounted" property of this object before calling
setState() to ensure the object is still in the tree.
This error might indicate a memory leak if setState() is being called because another object is
retaining a reference to this State object after it has been removed from the tree. To avoid memory
leaks, consider breaking the reference to this object during dispose().

When the exception was thrown, this was the stack:
#0      State.setState.<anonymous closure> (package:flutter/src/widgets/framework.dart:1167:9)
#1      State.setState (package:flutter/src/widgets/framework.dart:1202:6)
#2      _DynamicColorExampleState._updateImage (package:flutter_api_samples/material/color_scheme/dynamic_content_color.0.dart:191:5)
<asynchronous suspension>
════════════════════════════════════════════════════════════════════════════════════════════════════
00:03 +81 -1: Smoke test material/context_menu/context_menu_controller.0.dart
00:03 +81 -1: Smoke test material/color_scheme/dynamic_content_color.0.dart [E]
  Test failed. See exception logs above.
  The test description was: Smoke test material/color_scheme/dynamic_content_color.0.dart
  
  This test failed after it had already completed.
  Make sure to use a matching library which informs the test runner
  of pending async work.
```
      91cccc8e
    • Nate's avatar
      Refactoring `if` chains into `switch` statements (#144905) · 26e379e0
      Nate authored 
      Based on issue #144903, this PR aims to bring the codebase more in line with the [Flutter repo style guide](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#avoid-using-if-chains-or--or--with-enum-values):

> #### Avoid using `if` chains or `?:` or `==` with enum values

<br>

This change unfortunately increases the total line length, but it also improves readability.
      26e379e0
    • auto-submit[bot]'s avatar
      Reverts "Expose build mode in environment of asset transformer processes (#144752)" (#144957) · 187ec75e
      auto-submit[bot] authored 
      Reverts: flutter/flutter#144752
Initiated by: andrewkolos
Reason for reverting: compilation issue has turned the tree red
Original PR Author: andrewkolos

Reviewed By: {christopherfujino}

This change reverts the following previous change:
In service of https://github.com/flutter/flutter/issues/143348

When invoking a package to transform an asset, we set `FLUTTER_BUILD_MODE` to the CLI name of the build mode being used. Inspired by https://github.com/flutter/flutter/issues/101077#issuecomment-1890379501:

> Do transformers know whether they get executed in debug or release mode? I kinda imagine that being useful. Ex: There's a transformer that optimizes the file size of images. Depending on the amount and size of the images, that could take a significant amount of time. Therefore, I might want to only execute it in release builds.

Note for the reviewer: the interesting part of this change can be found in the commit [set environment variable to build mode when running asset transformer…](https://github.com/flutter/flutter/pull/144752/commits/579912d470b6f6eb036fd6b23a128fa3942f6282). The rest of the change is updating call sites with a new argument.
      187ec75e
    • Andrew Kolos's avatar
      Expose build mode in environment of asset transformer processes (#144752) · 83fad745
      Andrew Kolos authored 
      In service of https://github.com/flutter/flutter/issues/143348

When invoking a package to transform an asset, we set `FLUTTER_BUILD_MODE` to the CLI name of the build mode being used. Inspired by https://github.com/flutter/flutter/issues/101077#issuecomment-1890379501:

> Do transformers know whether they get executed in debug or release mode? I kinda imagine that being useful. Ex: There's a transformer that optimizes the file size of images. Depending on the amount and size of the images, that could take a significant amount of time. Therefore, I might want to only execute it in release builds.

Note for the reviewer: the interesting part of this change can be found in the commit [set environment variable to build mode when running asset transformer…](https://github.com/flutter/flutter/pull/144752/commits/579912d470b6f6eb036fd6b23a128fa3942f6282). The rest of the change is updating call sites with a new argument.
      83fad745
    • engine-flutter-autoroll's avatar
      Roll Flutter Engine from 9196947bc687 to 6745955bb49e (2 revisions) (#144946) · d98d842d
      engine-flutter-autoroll authored 
      https://github.com/flutter/engine/compare/9196947bc687...6745955bb49e

2024-03-11 zanderso@users.noreply.github.com Remove flaky check from observatory/tracing_test.dart (flutter/engine#51320)
2024-03-11 skia-flutter-autoroll@skia.org Roll Skia from cb30f40eea75 to f8d5ecc7841d (4 revisions) (flutter/engine#51321)

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC rmistry@google.com,zra@google.com on the revert to ensure that a human
is aware of the problem.

To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose

To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
      d98d842d

HIAST - GitLab