When a captured local type variable was used in more than one context
with different nullabilities, we would construct a separate field for
each one. Because the localToFieldMap is keyed by the local, each field
would clobber the previous one when it was written to the map.
This is a side effect of the CFE storing nullability on each type rather
than as a wrapper. Consider the following function:
void Function<S1 extends T, S2 extends T?>() f<T>() =>
<S1 extends T, S2 extends T?>() {};
Although the closure that f returns has a single free variable (T), we
end up with two distinct TypeVariableTypeWithContexts - one for T% and
one for T? - even though they're both keyed by the same local - T.
Change-Id: I7ea3ca7132ad51201beeb3c2a52311a97ce45875
Bug: #42847
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156445
Commit-Queue: Mayank Patke <fishythefish@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The stored AbstractValue is unused and removing it makes it possible
for the dummy to be independent of the AbtractValueDomain.
The actual receiver type is stored independently on the HInvokeDynamic
node, and would also be available via the 'interceptor' input, since
the dummy is used only on 'self-intercepted' call sites.
Change-Id: I04ff0a50f3afd399a6994ebe7f006687d57c84f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156585
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
These two functions (includeClosureCallInDomain and locateMembersInDomain) are similar to existing ones but take an AbstractValueDomain as a parameter. This is done so that the abstract value parameter belongs to the abstract value domain passed, for the wrapped version this did not happen.
Change-Id: Id085c1d589beccbf95fd2a0251b3b884f1dc2d30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156220
Commit-Queue: Christian Altamirano <coam@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
All of the backends (dart2js, DDC, VM) were checking if the invocation
name was tagged with "set:" and appending "=" to the name if so.
Instead, we can simply have the CFE perform this logic at the callsite.
Note that the name of the setter itself is still unchanged. Backends may
still need to generate the correct name themselves when handling NSMs
via code paths other than instantiateInvocation.
Change-Id: Iae42c849d3557be3e3b77c3af6f3993347ba0b6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156142
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
* Adds a bool `isNonNullableByDefault` field to Library entities.
* Adds a bool `usesNonNullableInitialization` to the JS emitter's StaticField.
* Emits two lazy-variable initialization functions: one for
pre-null-safety and one for post
New issues:
* Always emits both lazy init functions - even when only one is ever used.
Fixes#42419
Change-Id: I6a76798946b13842fbb2ad566d4505bbcd9ca0d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156063
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Pass the CommonMasks abstract value domain instead of the JClosedWorld to TypeMask methods that need access to *their* abstract value domain. It is wrong to get the abstract value domain from the JClosedWorld because when we try to wrap abstract values, the abstract value domain in the JClosedWorld is the wrapper domain, not the domain being wrapped.
Change-Id: I5bbd0f4c56abe45714dd0a2657f73ef240efae0e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155640
Commit-Queue: Christian Altamirano <coam@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
On a very big partition this reduces the memory footprint of the
ImportSets by 70% and is slightly faster.
This is because most ImportSet._transition maps have one entry.
Change-Id: I318a5675d8c3cf135c4937b2b0f63409e5c2d754
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155725
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
The current implementation of this check is incorrect and produces false
negatives. Conservatively assuming that one type is always a potential
subtype of another is a simple fix to get this working.
The main downsides are that we may emit signatures and provide type
arguments to functions even when they're not needed because we no longer
statically deduce that a type check must fail. This may cause size
regressions.
I've added a TODO to add proper constraint solving per the local type
inference spec, but this is not currently a priority since no regression
is observed on large Google apps.
Change-Id: Ie5065596331c33a030e06e66481f258ef937e659
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155544
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
--omit-implicit-checks.
When the default check policy is "trusted" instead of "emitted", we skip
checking every function during the RTI need computation. This works
because if the type arguments are needed for some other reason, like the
literal being used in the body, we see the type use and go back and
update the RTI need of the function. We can't do this for callable
properties because we don't know which function will be assigned at
runtime, so we need to conservatively provide type arguments no matter
what.
We could optimize this slightly by only providing type arguments if we
know a type use occurs in a function which is assignable to the type of
the property, but I expect this to save little for the amount of
overhead during compilation.
We also update the dependency computation to ensure that if a callable
property needs type arguments, then they're available for the enclosing
context to pass along.
Bug: https://github.com/dart-lang/sdk/issues/41449
Fixes: https://github.com/dart-lang/sdk/issues/41449
Change-Id: I98d9024dfa64cbfe33bd43172ffa905a8537649e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154284
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
ConstantValueTypeMasks will now contain a CommonMasks domain as a field which will be used in its visitor methods
Change-Id: I2913148794cce868f48ba4bf6fc5015cbb8f186b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154600
Commit-Queue: Christian Altamirano <coam@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The emitter creates classes in bulk, and then later connects them together
except for adding stubs for JS-interop is checks. We assumed the class for
JavaScriptObject was previously created and stored stubs eagerly while creating
classes.
We believe this caused a crash with flutter because the class was not yet
defined in that case.
One theory why this wasn't hit as much externally is that we sort classes by
location and process dart:* classes first. Flutter is the first use case where
JS-interop classes can be defined within SDK libraries.
Fixes#42612Fixes#25517
Change-Id: Icad0a9a16ec0d05481ed60f581a23c9eeb1ed5d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153943
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Account for the size of the a generative constructor factory.
The factory evaluates all the initializers up the inheritance/mixin chain,
allocates the object, and then calls all the constructors down the
inheritance chain. All this is missed by the old code looking at the
immediate constructor body, sometimes causing extremely large
constructors to be inlined.
Change-Id: I8803b0f4b4155dec0f7878fd5527c1dd507b9c80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153560
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This CL adds support for converting local function type variables from
the K model to the J model. The entity use for the J model type variables
isn't created before the closure classes and closure call methods have
been created. Therefore, the [ClosureData] is now registered
with the [JsToFrontendMap] object, once computed, allowing conversion of
local function type variables. Conversion of [BackendUsage] is moved
after closure creation because [RuntimeTypeUse] can refer to local
function type variables.
Closes#42088
Change-Id: Ifc00e69b5db0dd05710ea97017c41e8c7f5e520e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153080
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This was noticed when running the benchmarks/Calls/dart/Calls.dart with
sound-null-safety.
The only fix that was needed is to swap the argument order, but I also changed
to add the type promotion to make these errors stand out statically.
Change-Id: If47b04596d2da9d30961705fd858f2f2ba2b12c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153062
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
On a per output-unit basis, repeated large strings are shared via a
`string$` pool.
TODOs:
- don't do it with strings passed to JS() code (they might need
to be property accesses).
- tweak thresholds, using different thresholds for slow/run-once code.
Change-Id: Ib14245d9d428e52fb2ca23f34fa533de97fa2208
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136304
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This CL adds a Node.toText method together with an AstPrinter. These
facility and better toString implementation on AST nodes while allowing
for toString independent printing of AST to use in testing. This also
add support for an integrated toString of custom/internal nodes.
Some work is still needed in bringing the toString implementation on
all nodes to the old quality, and not all internal nodes have
customized textual representations yet. This work is left for future
CLs.
Change-Id: Ib0bf8a0bc02f489dfacdc8aa5f96da9c52f26058
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150923
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Christian Altamirano