Implement Q1 2021 Small features release in dart2js

[leafpetersen]

This tracks the dart2js implementation work for this feature. See also this existing issue for triple shift.

cc @sigmundch @rakudrama @franklinyow

[sigmundch]

Of the small features I expect that metadata support is CFE only, >>> may require some optimizations down the line, but correctness will likely be CFE + runtime libraries only. I however we may need to do some backend work to adapt our RTI to accept generic types in new places as proposed by the feature.

@fishythefish @rakudrama - what's your take on how much work will be required in this case?

[rakudrama]

I added some tasks for optimizing >>> at #30890 (comment). I think they can be discharged quickly

I think RTI would be affected only by annotations that are somehow reified in the app.

[leafpetersen]

I think RTI would be affected only by annotations that are somehow reified in the app.

The semantics require no reification. Whether you want to do so for error message purposes is up to the implementations.

[leafpetersen]

It's might not be unreasonable to have an optional kernel transform which eliminates all reified uses of typedefs for backends that want to expand them out, assuming that multiple backends might do so. cc @johnniwinther @a-siva @crelier

[sigmundch]

Sorry I'm a bit confused. There are two changes involving type parameters:

• Type arguments on annotations: Allow generic metadata annotations language#1297
• Generic function types as type arguments Allow generic function types as type arguments and bounds language#496

I was assuming the former are not reified, but that the latter was reified. Is that incorrect?

If those are reified, is the dart2js RTI representation general enough to accept them or do we need to extend it?

[eernstg]

Yes, type arguments cf. dart-lang/language#496 need to be reified in order to maintain a type correct heap and support type tests and type casts.

I would assume that type arguments on annotations (formerly 'metadata') would have to be reified insofar as the annotation object itself exists at run time (presumably they don't have to exist at run time unless dart:mirrors is imported).

[rakudrama]

@sigmundch There is no restriction in the RTI representation as to which subterms may be generic function types. I'll let @fishythefish comment on whether there are impacts for the Rti-need optimizations.

[leafpetersen]

Sorry for the noise - I read this too quickly and was thinking about type aliases. Agreed with the above.

[fishythefish]

My understanding of our RTI need is still more empirical than theoretical, so I'll need to play around with this feature and run some test suites in order to be sure how it's affected.

One possible change is that we'll need to add some more edges to our implicit RTI need graph: if a generic function type F is used as a type argument and the type parameter bound to it is used in a type test, then we can't erase F's type variables. We should already be doing something similar for interface types, so this may require little to no work, but this is an area where I keep finding holes in our current implementation, so it's worth validating.

Because our RTI need computation builds up a set of type variables to preserve rather than a set to erase, RTI need bugs often result in type variables being spuriously erased (to a top type/dynamic). This frequently causes type tests to accidentally pass, but we'll want tests that detect this failure case.

[leafpetersen]

Per the linked bug, I believe this is done modulo some post-flag flip cleanup, is that correct?

[fishythefish]

For triple shift, I think so, and AFAIK metadata improvements don't require any backend work. I'm mostly concerned about support for generic function types in type arguments - I don't think it'll be a hard change to make, but it'll be easiest if we have a suite of language/co19 tests to validate against.

[franklinyow]

What is the status?

[fishythefish]

I don't think we have any work on non-function type aliases, and the current test failure seems to be a CFE issue.

For triple shift, there are two test failures, but no action to be taken prior to the release. corelib/unsigned_shift_test/07 is not intended to pass on the web for the upcoming release. #45376 and #45438 document some action that could be taken on co19/LanguageFeatures/Triple-Shift/Constants_A01_t05/01, but this is a more general change to bit operations to be taken after the release.

For generic metadata, there are no failures and no implementation work on our end.