1. 13 Mar, 2024 13 commits
  2. 12 Mar, 2024 22 commits
  3. 11 Mar, 2024 5 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
    • 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