It is OK to keep default parameter elements in the cache and so keep
all the analysis results that depend on constants in the cache.
Parameters don't use their offset in their locations, so they don't
get "lost" during incremental resolution.
R=brianwilkerson@google.com, skybrian@google.com
BUG=
Review URL: https://codereview.chromium.org/1693243002 .
The two in src/mock_sdk.dart and src/context/mock_sdk.dart were almost
identical. The former was only used in one place, so I made the latter
support that case.
Also cleaned up a few other minor things I noticed along the way.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1691603002 .
A few other fixes:
* inference of generic function expressions now works. It was broken because they ignored type parameters.
* fixes subtype of generic functions in the "normal" type system. These types are only possible if generic methods support is enabled, which can be accessed via a flag. The generic methods DEP is designed to work with the normal Dart type system, too, so we try to keep these code paths working. ("normal" type equality for function types already handled this correctly.) This is also needed because strong mode delegates to normal type system for some cases, e.g. to pick warning vs error.
* also refactors structural comparison of two generic function types, along the lines of recent changes, so there is less code duplication. This was my original motivation, but reviewing the code led to the discovery of the other issues.
* refactors strong_test_helper. The existing way of matching up errors did not work with generic function expressions like: /*<T>*/(x) => x. Simplified it to just look for the right offset. This also exposed a bug in a test -- previously, it was possible to have an error that wasn't validated.
R=leafp@google.com, rnystrom@google.com
Review URL: https://codereview.chromium.org/1678313002 .
This CL makes the following changes:
- Renames _FbInt32List to _FbGenericList, and makes it able to
represent lists of entities whose size isn't 4.
- Adds Uint32ListReader and _FbUint32List classes, which are
specialized to handle lists of 32-bit unsigned ints.
- Moves common elements of all _Fb*List classes to the _FbList base
class.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1685263003 .
In the process, I fixed a bug where one version of this same lump of
code wasn't correct anymore now that you can have arbitrarily long
chains of type parameters.
DartType isn't maybe the ideal place for resolveToBound(). I wanted it
somewhere that:
1. Would be obvious enough that someone coming along later would
discover it instead of reinventing it again.
2. Had access to the various data it needs.
3. Wouldn't need a "is TypeParameterType" guard at every callsite
before it could be used.
I could put it on TypeProvider instead, since it needs access to Object,
but that felt arbitrary.
It could be a top level function, but then I don't think it would be
very discoverable.
R=brianwilkerson@google.com, jmesserly@google.com
Review URL: https://codereview.chromium.org/1686893002 .
This is necessary in order for "is" checks (e.g. `element is
ConstructorMember`) to function properly in the presence of element
handles.
To make this possible, it was necessary to lazify the `type` getter in
ExecutableMember, so that attempting to wrap an element handle inside
an ExecutableMember doesn't force the actual element to be
resynthesized.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1686283002 .
In the previous fix (4b5d30abba) I
neglected to account for the fact that
ConstructorElement.redirectedConstructor is sometimes a
ConstructorMember, not a ConstructorElementImpl.
Fixing this required properly storing the redirected constructor's
type arguments in the summary.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1683813005 .
This CL makes the following changes to UnlinkedPublicName.constMembers:
- Includes non-const constructors in it. This will allow a future CL
to make use of it for redirected constructors.
- Omits unnamed constructors from it--they were never used, and just
took up extra space.
- Renames it to UnlinkedPublicName.members to be consistent with the
fact that it no longer just stores const members.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1685713002 .
Several final fields in SDK have not valid constant expression
initializers, which is OK because the enclosing classes don't have
constant constructors. However we were throwing exceptions and failing
building SDK summaries.
Alternatively we could just ignore final field initializers in classes
without a constant constructor. But it seems to me that we need to
catch exceptions anyway, just in case of invalid code.
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1674073002 .