On Windows, the MemoryResourceProvider.convertPath method
prefixes the path with the C: drive, but the context associated with
the MemoryResourceProvider has a drive letter based upon the underlying
current directory. Most of the time, these two drive letters are the
same, but sometimes, such as on the Windows bot, the current working
directory is on drive E:, rather than drive C:.
This causes package Uris to be mapped to drive E: rather than the
expected drive C:
This CL changes the MemoryResourceProvider constructor
to set the current working directory to C:\ when running on Windows
so that it aligns with MemoryResourceProvider.convertPath.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2714373002 .
This updates ContextBuilder to process the --lints command line option:
* --[no-]lints enables (or disables) lints
* if --lints but no lints specified in analysis options
then the default set of lints is used
* if --no-lints then lints are turned off
regardless of what is specified in the analysis options
* if neither --lints nor --no-lints are specified
then lints are turned on iff analysis options specifies lints
My next step is to update analyzer_cli to use ContextBuilder getAnalysisOptions
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2716693003 .
Analyzer summaries do not yet support generic function-typed
parameters. To avoid user confusion, generate an error if the user
tries to use a generic function-typed parameter.
The error can be worked around by using a typedef or changing generic
types to `dynamic`.
R=brianwilkerson@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2656303004 .
This implements FutureOr<T> in strong mode, otherwise it's ignored (treated as `dynamic`.
Also fixes strong mode's inference subtype function incorrectly treating `void` as a malformed type. This had the consequence of allowing `void` to be inferred as a type argument.
R=leafp@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2647833002 .
Update command line arguments processing so that any analysis options
flags specified on the command line (e.g. --supermixin) take precedence
over corresponding flags in the analysis_options.yaml file.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2598523003 .
After discussion with kmillikin@, sigmund@, and scheglov@, we decided
that specifying the patch files in libraries.dart is more complex (and
less flexible) than we'd like. This CL changes things so that the
patch files are specified in analysis options using a simple map from
library name (e.g. "dart:core") to a list of patch file paths.
Clients are now allowed to put patch files wherever they want; they
don't need to be inside the sdk directory.
Note that we no longer include the patch configuration in
encodeCrossContextOptions. This should be ok, since we don't have any
use case in which a single instance of analyzer needs to accommodate
multiple patch configurations.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2560323002 .
This CL creates top level accessor functions which may be used to map from AST data structures to their corresponding elements and types, and begins using those accessor functions throughout the SDK. It also adds empty interfaces ResolutionTarget and ResolutionType, which are implemented by Element and DartType respectively.
In a future CL, I will change the types stored in the AST to ResolutionTarget and ResolutionType, rather than specific element types; this will decouple the ASTs from the element model. The presence of the accessor functions will allow clients to continue accessing elements and types in a type-safe way.
R=asgerf@google.com, brianwilkerson@google.com, scheglov@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/2551023005 .
Instead in DeclarationResolver build these local elements in the bodies.
As you can see, the summary_common tests are quite ugly now, we decided
that we still have to serialize everything in variable initialiers,
including local functions. So, this requires repurposing the tests to
using initializers, and also keep buildLabelElements() in
DeclarationResolver.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2485043004 .
Previous to this change, ResolveUnitTypeNamesTask would set types to
`dynamic` if there was no explicit type in the source code, and
InferInstanceMembersInUnitTask would overwrite those types with
inferred types. This caused a problem if the result of
ResolveUnitTypeNamesTask got flushed due to memory pressure, but the
result of InferInstanceMembersInUnitTask did not. In that case, the
task model would come back at a later time and re-run
ResolveUnitTypeNamesTask, causing the inferred types to be set back to
`dynamic`. But it would not re-run InferInstanceMembersInUnitTask.
As a result, the inferred type would be lost. This manifested as a
sporadic failure to inferred types in analysis server. Annoyingly,
edits to the file(s) involved would frequently cover up the problem
(temporarily) since they would invalidate the cache entries, forcing
the task model to re-run both tasks.
This CL fixes the problem by adding _declaredType and
_declaredReturnType fields to the element model;
ResolveUnitTypeNamesTask writes to those.
InferInstanceMembersInUnitTask continues to write to _type and
_returnType, as it always has. When a type or return type is
requested from the element model, the getter consults _type (or
_returnType) first; only if it is null does it fall back to
_declaredType (or _declaredReturnType).
This gives us the behavior we need (inferred types override the
implied "dynamic" type stored by ResolveUnitTypeNamesTask), but since
the two tasks are now writing to different fields in the element
model, it is now safe to re-run ResolveUnitTypeNamesTask--it will no
longer overwrite the inferred types.
Fixes#27482.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2480783003 .
This CL makes the following improvements:
- When visiting an executable element, local variables and labels are
rebuilt rather than matching them up to the old element model. This
ensures that if the element model was resynthesized from an API
summary (which doesn't contain local variables or labels), these
elements are not lost.
- When matching up existing elements, if the elements did not
previously contain offsets, offsets are recorded. If they did
previously contain offsets, the offsets are compared to verify that
they match. This ensures that if the element model was
resynthesized from an API summary (which doesn't contain offsets),
the offsets will be correct.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/2435313002 .
danrubel