In certain cases, the test would fail before creating the (lazily created) compiler object, and then we'd
try to call shutdown() on null in those cases.
Fixes#18610
This adds the animation links for illustrations of the Transition widgets, as well as adding a cross-references to the other transition widgets in the "See also" for each of their docs.
This changes the flutter tool to just try 10 times before giving up when running "flutter upgrade". Infinite retries can hang bots, and really don't provide a lot of help: if we've failed to upgrade for for nearly a minute, trying every five seconds, then something is just not responding.
Also, changed the bot default warning level to "normal" from "all", because the solver messages are VERY verbose: several megs of output for doing packages get on Flutter. "normal" will give warnings, user messages and errors, which should be sufficient to diagnose problems on the bots without spamming the log.
I removed the retrying for building the snapshot on flutter.bat because we don't do that on the other platforms, and because I can't imagine how running it again would give a different answer.
I also fixed a problem in the whitespace detection when no files matched the type of file that it is looking for, and removed the code that waits until failure to print the logs on setup, since reducing the log output made a huge difference.
This includes the following changes :
e54bc4ea1 Fixed invalid call site of runWithEntrypointAndCallback (#5984)
764884b91 Removed callback for HeadlessDartRunner (#5983)
91537abba Revert "Temporarily add travis/analyze.sh back for Chrome bot (#5961)" (#5966)
3501acb70 Roll src/third_party/skia 9c9611fcc1bb..0d5d0659a684 (7 commits) (#5980)
Somehow I forgot to say "super.tap()" when calling "tap()" on the new
superclass, so it was just recursing infinitely but ended up actually
crashing on the first reuse of the finder.
The error was previously swallowed, I made this print it instead.
Includes the following changes :
377793180 Roll Dart to version eab492385c3f345cb2f44f3b702b0e30e4a9c107 (#5979)
8a7af11f7 Fix IsolateStart event kind. (#5978)
Includes the following changes:
78f8bcace Annotate deprecated methods with @Deprecated (#5976)
4c7e5d5a1 Roll src/third_party/skia 0c5b0b1dd692..9c9611fcc1bb (13 commits) (#5977)
4208f8404 make ios text affinity behavior match android (#5971)
69b19a5f5 Roll src/third_party/skia f5402004c4a6..0c5b0b1dd692 (11 commits) (#5975)
8137d3411 Roll src/third_party/skia 4856f5fa596d..f5402004c4a6 (1 commits) (#5974)
cbe960d90 Roll src/third_party/skia 20714bdf90f3..4856f5fa596d (1 commits) (#5973)
f05a4ccaa Roll src/third_party/skia faeef7837210..20714bdf90f3 (11 commits) (#5970)
14af0348b Complete the AndroidView resize call only after a new frame is ready. (#5968)
Resizing an AndroidView happens asynchronously (as it requires thread
hopping from the ui thread to the platform thread).
While waiting for the resize to complete the framework does exactly when
the embedded view has been resized. This leads to pretty bad jank as the
framework might paint the embedded view with a wrong size.
We're working around this by freezing the texture frame while resizing
until we are sure that the next frame has the new size. This is how it
looks with the workaround:
This is how it looks before and after the workaround:
Before (janky) | After (less janky)
:--------|---------:
 | 
This depends on flutter/engine#5938. Additionaly right now the engine completes
the resize call immediately, a following PR will change it to complete
after a frame with the new size is ready.
