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.
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)
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.
This is a large commit, which introduces general API for working with
abstraction of Platform.
- Add new abstraction to 'core' - SimplePlatform - which represents
exactly one platform
- Clients are strongly prohibited to create instances of SimplePlatform
by hand, instead, corresponding *Platforms abstraction should be used
(e.g. JvmPlatforms, JsPlatforms, KonanPlatforms)
- Move TargetPlatform to 'core', it represents now a collection of
SimplePlatforms
- Clients are strongly encouraged to use TargetPlatform
(not SimplePlatform) in API, to enforce checks for multiplatform
- Provide a helper-extensions to work with TargetPlatform
(in particular, for getting a specific component platform)
- Remove MultiTargetPlatform in favour of TargetPlatform
- Notably, this commit leaves another widely used duplicated abstraction,
namely, IdePlatform. For the sake sanity, removal of IdePlatform is
extracted in the separate commit.
This decouples simple data (TargetPlatform) from other subsystem-specific
logic (like default imports, built-ins, etc.).
Aside from purely aesthetic improvements, it also makes it easier
to move 'TargetPlatform' into core (see next commits)
Mostly unused imports. Also, in some places,
TargetPlatform/MultiTargetPlatform were just passed around without
actually using (e.g. in deserialization)
There is added a new service named `SubstitutingScopeProvider`, that
provides factory that creates captured types and approximator for them.
In OI they are the same as before commit, for NI they are empty, because
that approximation interferes with NI algorithm
That service is injected into function descriptors and property descriptors
and used for creating `SubstitutingScope` with correct services
Also there is changed time when we approximate captured types in NI
(after all call checkers)
#KT-25290 Fixed
The classes being filtered have been renamed months ago. The change
committed in KT-12402 is no longer relevant as the underlying issue has
been fixed.
Fixes CompileKotlinAgainstCustomBinariesTest.testInternalFromForeignModule
after unifying non-build-file mode and build-file mode.
Previously when the compiler was run without -Xbuild-file argument,
it was not using modules internally, so we were not checking if internal
descriptors were contained in destination dir of current module
(without -Xbuild-file we were returning false at `if (modules.isEmpty())
return false` in `ModuleVisibilityHelperImpl#isInFriendModule`).
After switching to using modules for CLI compilation,
any jar file contained in destination dir was considered friend,
because only a prefix was checked.
In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.
To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.
Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.
#KT-19227 Fixed
#KT-28198 Fixed
Inline function descriptor in derived class represented as FAKE_OVERRIDE.
So we should find it in base class declaration
(not interface cause inline function can't be virtual, but always final)
and then check class version.
#KT-29402 Fixed
The root problem is the fact that ConstantExpressionEvaluator returns
null for values such as infinity and NaN loaded from cls psi (see
IDEA-207252). This commit simply reverts a part of 8ab9226805 where we
started to compute default values more often than needed. In
LazyJavaClassMemberScope, we only need to check whether or not there
_is_ a default value, not compute its value.
#KT-29792 Fixed
Dmitry Savvinov