Turn @staticInterop tear-off into closure

[srujzs]

@staticInterop members will start disallowing tear-offs, so this member should turn into a closure.

The static check wasn't added in time, so this is modifying the source code again.

ee3ce32 was the original change, but the static error didn't make it into the Dart SDK, so this is fixing another tear-off.

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read and followed the [Flutter Style Guide] and the [C++, Objective-C, Java style guides].
• I listed at least one issue that this PR fixes in the description above.
• [] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See [testing the engine] for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the [CLA].
• All existing and new tests are passing.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[Hixie]

test-exempt: code refactor with no semantic change

[eyebrowsoffire]

LGTM, with a small comment that avoids the lint override. Will static interop methods ever be valid as tearoffs? It bothers me a bit that the lint and this limitation are in conflict.

[eyebrowsoffire]

To avoid this lint override, you could instead do:

fontFaces.forEach((DomFontFace fontFace) => domDocument.fonts!.add(fontFace));

[srujzs]

This comes across another lint: https://dart.dev/tools/linter-rules#avoid_function_literals_in_foreach_calls :/

[eyebrowsoffire]

Blech. Well then just ignore my comment for now. If we will eventually get tearoffs for static interop (you could even just have a kernel transform emit a closure like this for static interop tearoffs) maybe we should put a TODO here so that we can remove the lint override?

[eyebrowsoffire]

Well I read your more detailed comment, thanks for the context. I was imagining dynamic tearoff creation but I didn't think about tearoff equality... hmmm.

[eyebrowsoffire]

In general these lint rules are awfully opinionated about things that don't seem to matter all that much 😆

[srujzs]

Yeah, even if we were to ignore tearoff equality, the semantics is inconsistent between a regular call and a tear-off call, so in cases where optionality matters, users will still have to battle these lints.

I agree that there shouldn't be a lint for a regular for-loop, but that's my personal opinion. :)

[srujzs]

Will static interop methods ever be valid as tearoffs? It bothers me a bit that the lint and this limitation are in conflict.

The complication around supporting tearoffs is that

1. The semantics are at odds with a regular call. Imagine a static interop method has positional arguments. We can lower regular invocations so that only the passed in arguments are in the final JS call. We cannot do that with a tear-off as we don't know how it's invoked, so we have to include every possible argument. So if you had external void foo(int a, [int? b]), foo(0) will give you foo(0) in JS, but (foo)(0) gives you foo(0, null) in JS.

2. We generate a node in the AST that gives you the tear-off. This adds code size for every interop member in DDC that can instead be not emitted. We could work around this by generating a tear-off dynamically, but this fails tear-off equality semantics.

I agree that it's a bit weird that the lint is noisy here. We can't really do your suggestion as it comes across another lint (https://dart.dev/tools/linter-rules#avoid_function_literals_in_foreach_calls). I'll have to think more about what code here should look like, but I don't know if this particular case can avoid all lints.

[gaaclarke]

It's my understanding that Linux linux_license is the engine_v2 recipe which has been reverted. I'm going to attempt to rebase to see if we get the Linux license bot to execute (which I think doesn't have the problem we are seeing with the rom files).

edit: the revert pr is #41903