Instead of using enums, we use booleans, and we change the terminology
as follows:
FormalSafety.semiSafe -> isGenericCovariantImpl
InterfaceSafety.semiTyped -> isGenericCovariantInterface
(The enum value FormalSafety.unsafe turned out to be redundant with
isCovariant, so it is no longer needed).
Similarly, the annotations in the front end tests are updated as follows:
@checkFormal=unsafe -> @covariance=explicit
@checkFormal=semiSafe -> @covariance=genericImpl
@checkInterface=semiTyped -> @covariance=genericInterface
Change-Id: Iafc0c5d3fc4e7608a2b8c52d8c29f293d9219995
Reviewed-on: https://dart-review.googlesource.com/5540
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
I also changed the way to mark roots for outlines.
Actually for outline purposes we should handle included libraries in
the same way as not included, with only distinction that all of public
nodes are included. So, it is easier to visit them using cycles and
feed into RetainedDataBuilder.
R=ahe@google.com, paulberry@google.com, sigmund@google.com
Bug:
Change-Id: I0dafad7572388de91f01e72f02599662e86f8759
Reviewed-on: https://dart-review.googlesource.com/5541
Reviewed-by: Paul Berry <paulberry@google.com>
A few corner cases weren't being handled correctly by the analyzer
code; some other corner cases weren't being handled correctly by the
front end.
Change-Id: I2b7153a411036541f48019757349b197f9b3bba7
Reviewed-on: https://dart-review.googlesource.com/5328
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The inferred types for const expressions shouldn't refer to type
variables that are in scope, because at runtime those type variables
may take on different values at different times (meaning the const
expression isn't actually const after all).
Test cases are in inference_new, since analyzer implements incorrect
behavior.
Fixes#30677.
Change-Id: I27b9a95a92557ad1ce1c2c0f28d9a760c372d52a
Reviewed-on: https://dart-review.googlesource.com/5298
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Rather than track precisely which types can be passed to each method
parameter through all of the interfaces it implements, and mark them
as semiSafe when they don't match the declared parameter type, it is
simpler to simply make semiSafe an "inherited" version of semiTyped.
The simpler analysis is slightly conservative--it will unnecessarily
mark parameters as semiSafe in a few circumstances, but those
circumstances seem like they will be rare enough that they don't
justify doing extra work.
This allows us to get rid of the extra field additionalIncomingTypes
(which we would otherwise have had to store in the kernel
representation).
In the process, reworked the logic for deciding whether to mark a
parameter as semiSafe or semiTyped so that it uses a type visitor
rather than by substituting and then doing a subtype check; this
should be significantly faster.
Note that in order for semiSafe to be "inherited" in all the right
circumstances, we need to mark it on abstract methods as well as
concrete ones; this is a departure from analyzer behavior, so I've
added a hack to front_end_runtime_check_test to ensure that it
generates the expected annotations.
Change-Id: I53d3718d8fb1979ac8551fe02734ddaf3d6708b8
Reviewed-on: https://dart-review.googlesource.com/5044
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL extends the computation of unsafe/semiSafe/safe and
semiTyped/typed annotations so that they apply to type parameters of
generic methods as well as ordinary method parameters (previously they
only applied to method parameters).
Change-Id: I5302e1bfe404df5c73656069557b80ca6787b2b4
Reviewed-on: https://dart-review.googlesource.com/4900
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The old technique had the right effect in a few simple corner cases,
but wasn't correct on theoretical grounds. The new technique is to
keep track, for every method parameter in every interface, the set of
types which might be passed to that method parameter through base
classes, and then compare those types to the declared method parameter
types.
So for instance, in the code:
class A<T> {
foo(List<T> argument) {}
}
class B extends A<num> {
foo(List<num> argument) {}
}
The set of types that might be passed to B.foo's argument is all
subtypes of List<Object> (since a caller might be invoking foo through
the interface A<Object>). Since List<Object> is not a subtype of
List<num>, B needs a runtime check.
Change-Id: Iae819e9f8c97ec1cf910fbfacf9bc635fccd9706
Reviewed-on: https://dart-review.googlesource.com/4610
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL addresses desugared assignments produced for assignments to
local and static variables.
Change-Id: I1e02745c65ef717a8f6484a0eed35c4ada3b89ac
Reviewed-on: https://dart-review.googlesource.com/4280
Reviewed-by: Peter von der Ahé <ahe@google.com>
Fixes#30582.
I'll address other kinds of assignments (assignment to a local
variable, static field/setter, or property) in follow up CLs.
Change-Id: I9055e951dc23a4aa1aa19489cf99a832319938c9
Reviewed-on: https://dart-review.googlesource.com/4184
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL implements type promotion logic for both `&&` and `||`;
however, the logic for `||` has no effect, since `_factsWhenFalse`
always returns the current facts. This is consistent with the current
Dart specification (which only specifies type promotion for `&&`).
Change-Id: I79f608aa33ea0501bb4bba303949330af2da4dda
Reviewed-on: https://dart-review.googlesource.com/3345
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Previous to this CL, inference of `??` matched the behavior specified
in the informal spec (https://github.com/dart-lang/sdk/pull/29371),
whereas inference of `?:` matched analyzer behavior.
In the long run, we want the behavior of both `??` and `?:` to match
the spec (note that the spec is still being debated, so this is a
moving target). But for now, to ease the transition to the new front
end, we want to match analyzer behavior.
With this CL, the inference for `??` is changed to match analyzer
behavior, and a boolean is introduced to make it easy for us to switch
to the behavior specified in the informal spec when it's appropriate
to do so.
Should address the inconsistency pointed out in #30624.
Change-Id: I33d95cd59e4c7e474f3ba27491be87c1bf66d85e
Reviewed-on: https://dart-review.googlesource.com/3421
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
It is stil permissible to access methods/getters on Object (toString,
==, hashCode, etc.), even if the receiver type is not an
InterfaceType, and we want type inference and kernel annotations to
work correctly.
Change-Id: I311b43c6de31faeefa85bc70636af05c62c4c1fe
Reviewed-on: https://dart-review.googlesource.com/3385
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
1. Instead of using a single lib/lib.dart, use a couple of small shared
libraries, and special libraries for each case we want to test.
2. Give tests meaningful structured names, with "source_*" tests
testing that we take into account referenced *from* somewhere.
And "target_*" tests for testing that we include referenced entities.
And "transitive_*" tests for including complete transitive closure
of referenced entities.
We don't yet include full transitive closure, this CL is just for
tests and results produced at the moment. Implementation and test
fixes will follow.
We also don't yet take exports into account.
R=ahe@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/3011663002 .
This test case verifies correct generation of abstract forwarding
stubs. Since analyzer doesn't contain logic for generating abstract
forwarding stubs, the test is in "runtime_checks_new" so that it won't
be checked against analyzer.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/3009873002 .
It turns out that it is easier to calculate whether or not checks are
needed at the site of the declaration of the interface target, not at
the call site. Accordingly, it makes sense to put the annotations on
the interface target declarations as well. This lets us get rid of a
clumsy annotation format that referred to arguments by number, in
favor of simply annotating the formal parameters themselves.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/3010613003 .
Paul Berry