Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.24.6 to 3.24.7.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/github/codeql-action/blob/main/CHANGELOG.md">github/codeql-action's changelog</a>.</em></p>
<blockquote>
<h1>CodeQL Action Changelog</h1>
<p>See the <a href="https://github.com/github/codeql-action/releases">releases page</a> for the relevant changes to the CodeQL CLI and language packs.</p>
<p>Note that the only difference between <code>v2</code> and <code>v3</code> of the CodeQL Action is the node version they support, with <code>v3</code> running on node 20 while we continue to release <code>v2</code> to support running on node 16. For example <code>3.22.11</code> was the first <code>v3</code> release and is functionally identical to <code>2.22.11</code>. This approach ensures an easy way to track exactly which features are included in different versions, indicated by the minor and patch version numbers.</p>
<h2>[UNRELEASED]</h2>
<p>No user facing changes.</p>
<h2>3.24.7 - 12 Mar 2024</h2>
<ul>
<li>Update default CodeQL bundle version to 2.16.4. <a href="https://redirect.github.com/github/codeql-action/pull/2185">#2185</a></li>
</ul>
<h2>3.24.6 - 29 Feb 2024</h2>
<p>No user facing changes.</p>
<h2>3.24.5 - 23 Feb 2024</h2>
<ul>
<li>Update default CodeQL bundle version to 2.16.3. <a href="https://redirect.github.com/github/codeql-action/pull/2156">#2156</a></li>
</ul>
<h2>3.24.4 - 21 Feb 2024</h2>
<ul>
<li>Fix an issue where an existing, but empty, <code>/sys/fs/cgroup/cpuset.cpus</code> file always resulted in a single-threaded run. <a href="https://redirect.github.com/github/codeql-action/pull/2151">#2151</a></li>
</ul>
<h2>3.24.3 - 15 Feb 2024</h2>
<ul>
<li>Fix an issue where the CodeQL Action would fail to load a configuration specified by the <code>config</code> input to the <code>init</code> Action. <a href="https://redirect.github.com/github/codeql-action/pull/2147">#2147</a></li>
</ul>
<h2>3.24.2 - 15 Feb 2024</h2>
<ul>
<li>Enable improved multi-threaded performance on larger runners for GitHub Enterprise Server users. This feature is already available to GitHub.com users. <a href="https://redirect.github.com/github/codeql-action/pull/2141">#2141</a></li>
</ul>
<h2>3.24.1 - 13 Feb 2024</h2>
<ul>
<li>Update default CodeQL bundle version to 2.16.2. <a href="https://redirect.github.com/github/codeql-action/pull/2124">#2124</a></li>
<li>The CodeQL action no longer fails if it can't write to the telemetry api endpoint. <a href="https://redirect.github.com/github/codeql-action/pull/2121">#2121</a></li>
</ul>
<h2>3.24.0 - 02 Feb 2024</h2>
<ul>
<li>CodeQL Python analysis will no longer install dependencies on GitHub Enterprise Server, as is already the case for GitHub.com. See <a href="https://github.com/github/codeql-action/blob/main/#3230---08-jan-2024">release notes for 3.23.0</a> for more details. <a href="https://redirect.github.com/github/codeql-action/pull/2106">#2106</a></li>
</ul>
<h2>3.23.2 - 26 Jan 2024</h2>
<ul>
<li>On Linux, the maximum possible value for the <code>--threads</code> option now respects the CPU count as specified in <code>cgroup</code> files to more accurately reflect the number of available cores when running in containers. <a href="https://redirect.github.com/github/codeql-action/pull/2083">#2083</a></li>
<li>Update default CodeQL bundle version to 2.16.1. <a href="https://redirect.github.com/github/codeql-action/pull/2096">#2096</a></li>
</ul>
<h2>3.23.1 - 17 Jan 2024</h2>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="3ab4101902"><code>3ab4101</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/2192">#2192</a> from github/update-v3.24.7-5e882999f</li>
<li><a href="a006adfa77"><code>a006adf</code></a> Update changelog for v3.24.7</li>
<li><a href="5e882999f1"><code>5e88299</code></a> Bump the npm group with 2 updates (<a href="https://redirect.github.com/github/codeql-action/issues/2190">#2190</a>)</li>
<li><a href="69e120d747"><code>69e120d</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/2191">#2191</a> from github/henrymercer/use-include-query-help-flag</li>
<li><a href="5ec06c71f0"><code>5ec06c7</code></a> Use the <code>--sarif-include-query-help</code> option when supported</li>
<li><a href="caf377935a"><code>caf3779</code></a> Update default bundle to 2.16.4 (<a href="https://redirect.github.com/github/codeql-action/issues/2185">#2185</a>)</li>
<li><a href="532ca5486e"><code>532ca54</code></a> Fail <code>analyze</code> step by passing an invalid option to <code>database finalize</code> (<a href="https://redirect.github.com/github/codeql-action/issues/2189">#2189</a>)</li>
<li><a href="2fa207a8b7"><code>2fa207a</code></a> Merge pull request <a href="https://redirect.github.com/github/codeql-action/issues/2188">#2188</a> from github/henrymercer/prepare-build-mode-help</li>
<li><a href="24c3eda0e3"><code>24c3eda</code></a> Escape named value in input description</li>
<li><a href="27a6cd0a11"><code>27a6cd0</code></a> Remove experimental qualifiers from build mode input</li>
<li>Additional commits viewable in <a href="8a470fddaf...3ab4101902">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
For https://github.com/flutter/flutter/pull/144577. There's no promise that the performance will be great when `IntrinsicHeight/IntrinsicWidth` is used extensively but it's not that uncommon of a widget.
The pub roller is blocked on
```
error � The argument type 'JSArray<JSAny?>' can't be assigned to the parameter type 'JSArray<JSNumber>'. � dev/benchmarks/macrobenchmarks/lib/web_benchmarks.dart:309:22 � argument_type_not_assignable
```
See https://github.com/flutter/flutter/pull/144852.
The fixes the typing so the next pub roll can (hopefully) succeed.
Some tests are assuming the flutter sdk code is being checked out to flutter and checking the code to a different repository makes them fail.
Bug: https://github.com/flutter/flutter/issues/144487
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.
```
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.
```
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…](579912d470). The rest of the change is updating call sites with a new argument.
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â¦](579912d470). The rest of the change is updating call sites with a new argument.
The purpose of this PR is to temporarily skip one integration test that is blocking the changes indicated below:
(This change adds a new property in Semantics widget that would take an integer corresponding to the heading levels defined by the ARIA heading role. This is necessary in order to get proper accessibility and usability in a website for users who rely on screen readers and other assistive technologies.)
Issue fixed by this PR:
https://github.com/flutter/flutter/issues/97894
Engine part:
https://github.com/flutter/engine/pull/41435
Framework part:
https://github.com/flutter/flutter/pull/125771
This is part 4 of a broken down version of the #140101 refactor.
This PR renames isAvailableForEnvironment to isForEnvironment and replaces a regular expression with a simple function. (The latter will change the behaviour for people with branch names like `mainly_refactors` or `chess_master_experiment` or whatever, but I'm pretty sure the old behaviour was not intended.)
----
This is a reland of https://github.com/flutter/flutter/pull/143176 which was speculatively reverted in https://github.com/flutter/flutter/pull/144855 but turned out not to be the cause of the tree redness.
