Checks to see if a JS interop member is correctly annotated with
the `external` keyword. If it is not, it must be one of several
exceptions to be allowed.
This CL also changes static errors to first check for `JS` and
`external` before processing the member as a JS interop member.
This makes it clearer whether a member is a JS member.
Change-Id: I412eeafbfe8773847bfb9c864e4fb9b65e2d632a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158083
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Adds errors for class members that have a @JS annotation but the
enclosing class does not.
Change-Id: Id693af71678510047a723863846d89aa29cebe26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157004
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@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>
Bad identifier for async closure generator body names in extension methods.
Fixed: 42531
Change-Id: Ice29bb5ac03c67b1024c0fd53ffdb9b9b1d2131f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153484
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
We cannot simply discard the `required` modifier in weak mode function
types since function types that differ in the placement of `required`
cannot compare equal. Instead, we do that during subtype checks.
We continue to ignore `required` in the actual calling convention in
weak mode.
Change-Id: I7dbb28550095c635f65592f78e495e8e4e8d7026
Fixes: https://github.com/dart-lang/sdk/issues/42608
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153386
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: 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>
When reducing the type promotion in case of assignment, the target
info wasn't correctly handling the reduction to the trivial state.
This caused an error in a following join computation.
Closes#42281
Change-Id: I2144f5401e9736308dc37147f7a5cb9ab1be8583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150935
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
There are several problems contributing to issue 41449.
This fixes the malformed call-through stubs.
Change-Id: I90f1584f221956ee3fe4111314cba2813a16837c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150283
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
A HParameterValue can be an SSA value or a mutable local variable
accessed via HLocalFet/HLocalSet. The latter happens in code that is not
completely SSA-converted (due to exception control flow).
The main bug is that the check on a mutable-variable-mode HParameterValue
should have been on a HLocalGet of the value, and not the HParameterValue
itself. This means that a reference to the HParameterValue cannot be
replaced with a strengthening check, as that breaks the invariant that
HLocalGet/Set refer to variables. There was code in types_propagation
that tried to work around this broken invariant.
The bug (issue 42189) required
- An elided instance method parameter
- try(-catch)(-finally) to avoid complete SSA-conversion
- -O0 to avoid optimizing away the check early with inferred types
The first attempt at a fix was to not check the elided parameter at all
since the default value is statically checked. This is still worthwhile.
Bug: 42189
Change-Id: Idd5e2b1485eba4950a36d1e4ff57ebe35e4c98a0
Fixed: 42189
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150171
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
