This includes some major internal changes that should improve performance (the AOT template compiler) and the new lookup code. The big changes noticeable for Flutter will be resolution of field formal parameters, extension method support, and more consistent disambiguation in comment reference lookups.
While a vast net improvement, this PR will change a few links to point to the wrong place. #85484 will address that after this lands, as there was no good way to specify what the user wanted unambiguously before dartdoc 1.0.0 in a few cases. That PR includes more details on the introduced regressions and link changes.
This turns on order shuffling for all tests that don't fail with it on, marking those tests that do fail with a tag so that they will be run without shuffling on.
To determine which tests fail with it on, I ran all the tests 100 times with different random shuffle seeds, and then also ran it with the date seeds from today until the end of July, and tagged all of the test suites (files) that fail, with a seed that caused them to fail.
This adds avoid_dynamic_calls to the list of lints, and fixes all instances where it was violated.
Importantly, this lint is NOT turned on for flutter/packages/test, because those changes are happening in another PR: #84478
This switches the sample analysis code to use package:flutter_lints instead of the flutter repo analysis options, so that they are compatible with a similar change to DartPad.
This is bassically reapplying #71721, but only enables it on web tests.
There are known issues that several tests under the `integration.shard`
depend on a specific platform, and as a result they require some
additional flexiblity (bots need to build more than one engine, and the
test flags should allow for secondary engines to be picked by such
tests).
By enabling this on the web-test shard, we will reduce the false
positives in the dart-flutter-HHH-web bot.
Fixing the more general problem is tracked by #72368.
This turns off the "directives_ordering" lint when analyzing samples, since it's indeterminate what the ordering will be, given that samples derive their imports both from the template and the example code.
This is temporary to avoid broken builds, but the correct solution is to reorder the output so that the imports are ordered properly so that we give the proper example for our users.
