When moving away from descriptors, this top-level declaration check
was lost. That leads to many useless annotation elements in
inner classes attributes for annotations that are not inner classes.
There is no option in UI to enable/disable passing those variables,
but during Gradle Sync environment variables are passed by default
Also Gradle expect that gradleOptions are passed but there is also no option in UI
(during Gradle Sync IDEA add some options but they shouldn't affect dependencies resolution process)
see GradleExeSettings.resolverExtension.getExtraCommandLineArgs
gradleWithConnection was removed because it isn't used by gradle because they need to manage the TAPI project directory
projectRoot was fixed to externalProjectPath because it can be overrided in settings.gradle
^KT-30974 Fixed
There is new child of `VariableAsFunctionResolvedCall` in
new-inference: `NewVariableAsFunctionResolvedCallImpl`. So, in order to
support both versions, just use parent class
Previously, a lot of clients used JvmPlatform as platform-marker,
without thinking about jvmTarget.
For the sake of migration, this commits introduced so-called
UnspecifiedJvmPlatform, which can be used for a time being, but
generally, all usages should be removed in future.
This is needed, because previously such code were not distinguishing
between different flavours of JVM or Common. Now we do, and, for
example, JdkPlatform(1.6) != JdkPlatform(1.8), which causes such
dependencies to be erroneously dropped
Previously, containers set-up was performed by calls to static functions
like 'createContainerForLazyResolve', which would set-up whole container
from scratch.
This has several issues:
- complicates code re-use and encourages copy-paste of one and the same
set-up logic
- complicates composition of multiplatform containers (because each
set-up method relies on the fact that it should take an empty
container and compose it completely)
The idea of this commit is to split set-up methods into smaller ones,
with finer areas of responsibility, which allows to re-use them
in various scenarios (and, in particularly motivating composition
of multiplatform container)
This commit introduces the ability to register a PlatformExtensionClashResolver
in a container. Each PlatformExtensionClashResolver has a corresponding
PlatformSpecificExtensions.
If, during container composition, several instances of
PlatformSpecificExtensions were registred, instead of throwing
InvalidCardinalityException, corresponding PlatformExtensionClashResolver
will be asked to resolve clash.
This allows to make injection more composable and less coupled across
different contributors of service, providing a basis for such motivating
cases as composing containers with both JS and JVM services (for analysis
of multiplatform modules).
Previously, that would be impossible:
a) JS would inject default instances for some services which would clash
with non-default JVM services (like SyntheticScopes)
b) Also, there are a very few services for which *both* platforms provide
non-default implementations, so they should be merged manually on
case-by-case basis (e.g., IdentifierChecker)
The idea is to try to resolve the dependency without considering default
instances first.
This makes containers more composable, e.g., it is now possible to put
several containers together as long as all except one provide default
implemenetation for some particular service (non-default implementation
will be automatically chosen, and all defaults will be discarded).
Essentially, this function was used solely for setting
'useBuiltInsProvider' to 'true'; otherwise it were just delegating to
createContainerForLazyResolveWithJava, which were just increasing the
noise.
It was used called only once, and hasn't provided any useful
abstraction.
Actually, this "cosmetic" refactoring makes similarities with other
platform-specific container set-ups cleare, which allows to make further
generalizations and simplifications.
Anton Bannykh