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>
Several tests need to access source files in the 'pkg' directory, and
they use various mechanisms for finding it. This CL changes
everything to use the same mechanism.
Change-Id: I146a6d72ec05a20cf07451a83eada9fb8e71a966
Reviewed-on: https://dart-review.googlesource.com/5484
Reviewed-by: Konstantin Shcheglov <scheglov@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>
Previously, we generated annotations at the same time as we changed
the value of the .formalSaftey or .interfaceSafety kernel field. This
had two drawbacks:
- If a field's safety ever changed twice (i.e. the algorithm first
decided it was semi-safe, and then revised it to unsafe), we would
get two annotations.
- The annotation code was spread out, leading to a greater risk that
an annotation would be forgotten.
This CL addresses both drawbacks by moving all of the annotation code
to a common location.
Change-Id: I842c6c3dae4b4f28c868736cd862e5400406428e
Reviewed-on: https://dart-review.googlesource.com/5020
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>
Anytime a user adds `abstract` to a member of a class,
the fasta parser now reports an AbstractClassMember error
rather than the more general ExtraneousModifier error.
Change-Id: I41094ff71d38f1572c692b0a66fe8b68948fc23b
Reviewed-on: https://dart-review.googlesource.com/4143
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
During type inference, figuring out the type of a method invocation,
property get, or property set takes three steps:
- findInterfaceMember() looks up the target of the invocation, get, or
set.
- In the case of a method invocation, additional inference is
performed (to determine generic parameters).
- getCalleeType() uses the interface member and the receiver type to
figure out the type of the target.
Previous to this CL, there were two circumstances in which
findInterfaceMember() might return `null`: if the invocation was
dynamic, or the receiver's type was a FunctionType and the method name
is `call`. In order to allow getCalleeType() to distinguish these two
possibilities, it was necessary to keep track of the method name and
plumb it through to getCalleeType().
That was cumbersome, and it would have interfered with fixing
dartbug.com/30582 (which requires keeping track of the targets of
invocations/gets/sets within complex desugared expressions, in
codepaths that don't have room to easily pass additional information
around).
This CL changes findInterfaceMember to return the sentinel string
`call` to represent the case where the receiver's type is a
FunctionType and the method name is `call`. This avoids the need for
extra plumbing, since the interface member is already plumbed through
to getCalleeType().
It also does some cleanup of getCalleeType and getSetterType, removing
code branches that have turned out to be unnecessary.
Change-Id: I3295ea139106511005b2067cc9b85b5bc01952c3
Reviewed-on: https://dart-review.googlesource.com/3800
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>
Konstantin Shcheglov