Analyzer: support platform specific analysis in the presence of conditional imports

[leafpetersen]

See #32960 for context.

Dart will support limited configuration specific imports, and provides different core libraries on different platforms (e.g. dart:io, dart:ui, etc).

The analyzer needs to have a story for what the UX for analyzing both inside and outside of the IDE is.

cc @devoncarew @vsmenon @bwilkerson

[devoncarew]

Is #34316 sufficient for this?

[leafpetersen]

This partially is a question for clients - are clients of the analyzer ok getting analysis based on the default import or do they need accurate analysis for the platform?

The UX question seems to me to be somewhat up to the analyzer team. My thinking has always been that it will be a better experience if users can select their platform and get errors customized to that, but I know there is also a concern that having modal selection of platforms is confusing. The two main questions that come to mind for me are:

• Does the user get warnings if they use config specific imports incompatibly (that is, they import a web only library guarded by dart.library.flutter or somesuch)?
• Does the user get errors and warnings from the analyzer based on the actual platform they're compiling to, or do we just rely on the compilers to issue the errors and warnings if the actual platform version of the library differs from the default library?

[devoncarew]

Some ideas here:

• in terms of how to switch platforms, this could be controlled by a new flag in the analysis options file: analyze-for-platform: dart.library.foo or similar.
• it would be useful to also allow a CLI override of this: dartanalyzer --analyze-for-platform: foo. That would help support the CI use case, where you want to verify against a few platforms.
• without an explicitly specified platform, we'd likely just analyze against the default import (so, we wouldn't try and auto-detect what platform they intended and use that).

[matanlurey]

/cc @natebosch @jakemac53 @grouma as I think its important we get our story consistent across tools.

[grouma]

cc @davidmorgan

Providing a new flag to analyze in a platform context will likely be sufficient for the dart_library scenario. I'm curious how analysis will look in the editor though. What context will be used? Can it be inferred?

[devoncarew]

I'm curious how analysis will look in the editor though. What context will be used? Can it be inferred?

It could possibly be, through I'm worried about the auto-magical nature of that. Per above, we'd try always analyzing against the default import if nothing was explicitly specified, and allow users specify a specific platform via an analysis options file setting. This would be respected by the analysis server (and through that the IDEs).

[natebosch]

We might consider allowing analysis against multiple platforms if performance allows it. It might be enough to pick a single platform for the IDE and expect users to set up multiple invocations of dartanalyzer within CI to get multiple platforms, but that's putting a larger onus on the users and leaving more room for mistakes.

Especially when it comes to config specific imports it's a bad experience for me to have an if (dart.library.io) 'io_impl.dart'; and never be notified that io_impl.dart is missing some interface I'm using because I forgot to run with --analyze-for-platform vm.

Also a nit about terminology, dart.library.io is not a platform. "vm" and "flutter" are both platforms that indicate support for dart.library.io.

[devoncarew]

We might consider allowing analysis against multiple platforms if performance allows it.

It's more of a complexity of the implementation concern than a performance one -

It might be enough to pick a single platform for the IDE and expect users to set up multiple invocations of dartanalyzer within CI to get multiple platforms

That's mostly what I'm imagining, and I think a reasonable place to be. We could use feedback from users to determine if something additional was required.

[vsmenon]

@devoncarew what is the current expected behavior if someone (in Intellij say) imports both dart:ui and dart:html at the top-level?

@yjbanov was showing me an example where he did something like this (internally) - with no reported errors.

Is the analyzer:

• under checking / reporting errors?
• somehow magically merging dart_sdk files (there is no single one with both)?
• doing something else?

[devoncarew]

The behavior depends on what sdk is used. The one vended from dart-lang/sdk doesn't contain dart:ui, so will show as an error. The one from flutter doesn't contain dart:html, so will show an error for that.

Internally, I believe we're still creating a synthetic combined sdk, so it does contain both libraries; no errors displayed there is expected.