* Adds a new extension point to allow for contributing OptionsValidators.
* Adds a new linter 'service' to server that contributes a lint-aware validator.
You'll notice that the warning code I added is NOT in `errors.dart`. I did that in anticipation of plugin-specifc warnings living elsewhere. If that's not the right angle, happy to un-do!
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1418333002 .
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 .
...instead of ensuring this separately for complete closures of every library.
This improves initial analysis performance from about 44 seconds to 39.
This also makes WorkOrder.moveNext less expensive - to about 5.6% during initial analysis.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1412273004 .
This reduces number of LibrarySpecificUnit instances from 10,000,000 to about 6,000.
Also this slightly improves the code of corresponding 'buildInputs' methods.
This saves some memory, but unfortunately does not win any performance.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1422793002 .
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 .
Previously we created this element lazily (when requested) but this
didn't work well with the new task model, because creating the element
required calling back into the context and requesting full analysis of
`dart:async` (in order to get access to the Future type), and this
could lead to reentrant task execution.
Now we explicitly create the element in ResolveLibraryTypeNamesTask,
which allows us to get the Future type from the TypeProvider, avoiding
reentrancy.
Fixes#24627.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1405963005 .
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 .
Fixes#24549.
A few notes:
* does away with registry in favor of context-associated configurations
* pulls in linter rev that does the context association
* bumps analyzer version before publishing (needed to update analyzer_cli)
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1406043002 .
It's not used yet, except by its own test.
Naturally there's a *lot* to clean up here in follow ups. I tried to keep the ported code in its own directory so it's obvious. Ideally we can remove this directory once the code has been moved out.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1402783004 .
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 .
Note the TODO to fix the extension manager interaction hijinx. Really we should ensure that we are only using the one in engine. At the moment, it's easy to get this wrong (as the initialization heroics herein testify).
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1392683003 .
The problem is that during computing RESOLVED_UNIT3 we reuse RESOLVED_UNIT2
with the previously resolved bodies. And resolver ignores already resolved
identifiers. So, this causes pointing to the stale element model, etc.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1398433004 .
This CL changes the way that the task model does strong mode inference to use the strongly connected components in the import/export graph. Library cycles are computed and inference is staged by forcing each stage of inference to happen across an entire library cycle at once, and to force all external dependencies of a library cycle to have completed inference before inference for the library cycle can begin.
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1386023002 .
this fixes https://github.com/dart-lang/dev_compiler/issues/356
The issue here is that StrongTypeSystemImpl has toType and fromType backwards from how they are defined on the base class.
The way it works is to read it as "is the first type assignable to the second type"?
(I can see how this may have happened: the base class uses "leftType" and "rightType", which refers to the parameter order, not the order they would appear in an assignment expression.)
R=leafp@google.com
Review URL: https://codereview.chromium.org//1380963004 .
pq