For any practicaly purpose it was useless because we casted to
FieldDeclaration anyway to get documentation and isStatic field.
One additional change is that we now create ConstFieldElementImpl only
for non-static final fields. This corresponds to the logic in
ResolverVisitor.visitVariableDeclaration(), which clones initializers
only for final non-static fields.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1696793003 .
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 .
This is a temporary measure to restore incremental resolution in most
cases. In the future we should avoid putting constant variables into
cache at all and enforce this on the cache.put() level.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1682333003 .
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 .
When the context A uses unit U from the context B, we don't resolve U
in A to RESOLVED_UNIT, we usually stop somewhere before. But we still
want to update U in A incrementally. We don't put RESOLVED_UNITx
results into cache, so we don't write a less resolved unit as a more
resolved result.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1680403003 .
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 .
I neglected to sort members when converting the idl format from fields
to getters; this rectifies the problem.
Note that sorting members changes the format of summary files, since
data is indexed according to its order of appearance in the idl. In a
future CL I will introduce a mechanism to keep the indexing stable so
that introducing new fields won't break backward compatibility.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1681733002 .
Konstantin Shcheglov