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.
This is needed because platform of the module is determined by the
suffix after last '-' in 'createModule', and for string 'test-module'
that would be 'module', which obviously doesn't make any sense.
Howwever, due to how MultiTargetPlatform was implemented, it was
possible to create platform with such name, and everything was fine
as long as no one actually tried to switch on such a malformed
"platform".
After switching to more strict TargetPlatform representation, some tests
that had been trying to create platforms with such names started failing.
Seems that it was purely a mistake introduced in the
af1264a46d, so this commit fixes it by
specifying proper module name
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)
A synthetic property descriptor created for `B.value` (see the added
test) should not be equal to the normal descriptor created by the fake
override construction algorithm. Otherwise we can't reach this synthetic
non-abstract descriptor when building bridges in `C`, which results in
exception.
#KT-31367 Fixed
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
It uses isStaticMethod to determine whether to set ACC_STATIC, which is
not correct (see PR #2341). This results in using incorrectly typed
opcodes (as all arguments are shifted by 1) when modifying the inlined
lambda's bytecode. For example, in the test added by this commit, these
opcodes are inserted to spill the stack into locals before calling
another inline function.
Because getMethodAsmFlags is used by the non-IR backend (see PR #2341
again for why changing stuff might not be a good idea), the proposed
solution is to ditch it completely and override generateLambdaBody in
IrExpressionLambdaImpl to use FunctionCodegen's IR-based flag
computation logic.
Dmitry Savvinov