js-interop check: warn about conflict with native types

[sigmundch]

(creating a separate bug for checks mentioned in #32929 (comment))

To help users detect issues like #42200, we can check names used for classes in @JS do not conflict with any native names on our core libraries. At the time the js-interop-checker runs, we should have access to all declarations within the dart sdk (dart:html, typed_data, etc) and extract a list of native types that can't be used.

[ryanheise]

Hi @sigmundch , this error checking seems to have a loophole. See @keaganhilliard 's PR which adds web support to audio_service:

https://github.com/ryanheise/audio_service/blob/master/lib/js/media_session_web.dart

The native MediaSession.setActionHandler accepts a handler that's essentially a void function with no parameters. The above code overrides it so that the handler function can accept the details parameter which is needed for example to know which position to seek to. Since this uses @JS to bind to the navigator.mediaSession object rather than the MediaSession class, it is not detected as a "class name" conflict, although it seems to work well for us and we are happily going along with that.

The only issue now is that our other override is being detected as a conflict:

https://github.com/ryanheise/audio_service/blob/master/lib/js/media_metadata.dart

Although we can probably delete that for now as the native class seems fine. (This code is working fine for us on the flutter beta channel, by the way.)

I will give my thoughts on #42200 over on that issue, but above I just wanted to make you aware that the above quirk.

[srujzs]

Yeah, we can't feasibly have a static error check in that first case since there are many, many different ways you can access a native object. We've seen this come up in internal code as well. I guess we could theoretically have runtime checks for these accesses, but I'm assuming that becomes prohibitively expensive in many cases.

For MediaMetadata, if the @Native class works, that would be my preference, but if it doesn't, there are still ways to avoid using it in an @JS annotation by using js_util to interact with the native object.

Thanks for sharing though, it's definitely helpful.

[natebosch]

I guess we could theoretically have runtime checks for these accesses, but I'm assuming that becomes prohibitively expensive in many cases.

It might not be a problem to have that in DDC.