dart-lang / dart-lang/language

[parts-with-imports] Conditional part directives and the analyzer

Open
#3,973 20 comments 0 reactions 0 assignees View on GitHub
enhanced-parts
Dominant language
TeX
Stars
2.9k
Forks
239
Avg merge
2d 18h
Merged PRs (30d)
14

Description

The proposal extends `part` directives to allow for conditional URI support similar to the conditional support for `import` directives.

The analyzer has never had the best possible support for conditional `import` directives. It uses the default URI and assumes that conditionally imported URIs will usually implement the same public interface and can hence be ignored. We don't, for example, verify that assumption, let alone create diagnostics if the assumption is violated. (Note that we only ignore the conditional libraries while analyzing the importing library, each conditional library will be analyzed independently as well, at least in the context of an IDE and assuming that the conditional library is in the same package as the importing library).

We decided that that approach was probably good enough because we didn't expect the feature to be widely used and/or that the condition wasn't likely to be violated. I don't know what the usage numbers look like in practice, but we've had very few issues opened asking for better support, suggesting that this was probably a reasonable choice.

At first glance we might expect that we could use a similar approach for conditional parts, but I'm wondering whether that's true.

Whereas the assumption required for conditional imports is that the public API of the default library will be implemented by all of the conditional libraries, the assumption required to have the same level of support for conditional parts is that both the public and private API of the default subtree will be implemented by all of the conditional subtrees. And unlike conditionally imported libraries, conditionally included subtrees won't (can't) be analyzed independent of the containing library, so ignoring them means that some portions of the library might not be analyzed at all. I can fairly easily imagine that the first assumption won't be violated very often, but I find the second implication to be concerning.

The question is: do we think that performing analysis against only the default subtree is adequate, or do we need to do more analysis for conditional parts than we do for conditional imports in order to reasonably support them? If so, how much extra analysis are we talking about?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.