Currently, "sideways casts" -- type errors where one type is assigned
to an unrelated type -- are reported by both ErrorVerifier and strong
mode's Checker. This leads to duplicate errors that the user can see.
ErrorVerifier's errors are generally better: they give the user more
contextual information and are easier to read. So this CL eliminates
Checker's reporting of these errors and only uses ErrorVerifier's.
However, in strong mode, type errors like this are fatal: DDC can't
generate correct code. So this also automatically upgrades all static
type warnings to errors when strong mode is enabled.
R=brianwilkerson@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1780783002 .
This gets us roughly half+ way there. We should defintely consider automating this to speed up the rest. (Even with the quick-fix it's VERY tedious and slow going.)
Once we've done this in bulk, I'd like to add the `annotate_overrides` lint to analyzer and server `.analysis_options`.
BUG=
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1749143003 .
1.13 stable builds of the SDK contain a version of server that fails catastrophically when analyzing source that imports packages that define embedded libraries. Since we can't pragmatically require more recent SDKs for flutter development we have been prevented from landing embedded libs in the flutter engine. By renaming the key we use to identify contributed libraries, this change avoids the issue. Old versions of server will simply ignore the new key and new ones will process it properly. Win-win!
BUG=
R=danrubel@google.com
Review URL: https://codereview.chromium.org/1643023002 .
- If a package has an '_embedder.yaml' file with an 'embedder_libs' key two things happen:
1) We do not use the DartUriResolver to resolve dart: libraries.
2) We use the EmbedderUriResolver to resolve all dart: libraries
- If multiple packages have an '_embedder.yaml' file we merge them.
- This might not be the final behaviour that we want but I'm not sure how to surface errors to the end user.
- The '_embedder.yaml' file has a top level key 'embedder_libs' which is a map from dart: library uri to source path. Other keys are ignored by the EmbedderUriResolver.
- Unit tests for analyzer
- Integration test for analysis_server.
R=pquitslund@google.com
Review URL: https://codereview.chromium.org/1437893003 .
Basic YAML map merging suitable for merging a default map with an overriding one.
The semantics favor the overrider with a twist to support a short-hand for lists that stand-in for maps of scalars to booleans. Specifically, lint rules can be enumerated as a list or as a map. To make this work, lists can be "promoted" to maps. In particular, if
linter:
rules:
- camel_case_types
- one_member_abstracts
is merged with
linter:
rules:
one_member_abstracts: false
always_specify_return_types: true
the right thing is done to get us to:
linter:
rules:
camel_case_types: true
one_member_abstracts: false
always_specify_return_types: true
R=brianwilkerson@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1425393002 .
Commit 24189ea4f9 modified the
PathFilter constructor signature in a backwards-incompatible way, and
made corresponding changes to analysis_server, causing warnings to
show up in analysis_server when analyzed using the version of analyzer
in its pubspec.
This CL switches to a backwards-compatible signature and updates the
analyzer pubspec in preparation for publishing. Once the new version
of analyzer is published I will update analysis_server's pubspec to
point to it, which should fix the warnings.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1278823002 .
Commit f8ce36df55 introduced an SDK
class called "Resource", causing warnings to appear in any files that
reference the analyzer class with the same name. (Fortunately there
was no regression in functionality since the spec requires the name
conflict to be resolved in favor of the definition that is outside the
SDK).
As a short term workaround to avoid the warnings, we are explicitly
importing 'dart:core' and hiding the new Resource class. In a future
CL, we plan to rework analyzer's Resource class in order to make some
changes necessary for ".packages" file support; when that happens we
will probably rename the class to avoid the name conflict.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1215753003.
Brian Wilkerson