- Regenerate tasks.dot
- Mark a test as passing that previously failed
(fail_finalPropertyInducingVariable_classMember_instance_unprefixed)
Note that there are three other tests that I would have expected to
start passing as well (see
fail_finalPropertyInducingVariable_classMember_instance_*), but they
still fail.
TBR=scheglov@google.com
Review URL: https://codereview.chromium.org/1469093002 .
- 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 .
The big change here is to ensure FunctionTypeImpl.typeArguments is always initialized to match the parameters. This was previously the case, because we'd explicitly use the class's type parameters. With generic methods, we can no longer rely exclusively on that source of type parameters.
We take advantage of enclosingElement to compute typeParameters from all containing scopes that can have them. By tracking all of the typeParameters, this allows substitution to work later.
Adds a few very basic tests. Please note that generic methods are not ready to use yet.
In particular this doesn't yet do the correct substitutions in StaticTypeAnalyzer. It also doesn't include (mostly done) inference to infer type parameters from the argument types. Further, discovered a missing feature from the previous parser CL. And finally, it doesn't include the kind of ErrorVerifier checks we'll likely need.
R=brianwilkerson@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1434983006 .
it looks like some old code was hanging around that tried to substitute generic type parameters by name. This is unnecessary because we already have a substituted type at this point, and the type variable we were substituting had no relationship at all with the parameter. After removing the code, all tests seem to be passing.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1409143009 .
Previously, we had a mixin class PotentiallyConstVariableElement to
represent variables which might be constant. This left some holes in
the type hierarchy which didn't implement
PotentiallyConstVariableElement but nonetheless could be reached by
constant evaluation code in the event of errors in the code being
analyzed, resulting in an invalid cast exception.
This CL drops PotentiallyConstVariableElement and moves its one getter
to VariableElementImpl so that it will be available to all variable
elements. This allows us to avoid a lot of casts, including the one
that previously caused the exception.
Fixes#24645.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1416873003 .
We need this to improve code completion, and to *not* suggest method/keywords/etc
in cases like "main() {String s^}". Currently it is parsed as "main() {String; s^;}",
so completion cannot distinguish the variable name "s" from a of start a new expression.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1413773003 .
Previously, when attempting to figure out the type of the synthetic
field associated with a getter (or setter),
TypeResolverVisitor.visitMethodDeclaration() used the getters
FunctionTypeImpl.returnType (or FunctionTypeImpl.normalParameterTypes)
to extract the appropriate type. But those getters are only safe to
use after types have been fully constructed (because they may try to
perform type substitution). Fortunately, type substitution isn't
needed here, so we can simply use FunctionTypeImpl.baseReturnType (or
FunctionTypeImpl.baseParameters) instead.
Fixes#24539.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1397193002 .
Paul Berry