Useful for tests that check behavior which depends on having a recent
API version enabled, and that don't want to depend on a specific fixed
API version (to prevent eventual obsoletion)
To mimic the case of user passing an explicit "-api-version" flag to
avoid API version being inferred to the version of stdlib in
dependencies by JvmRuntimeVersionsConsistencyChecker
Under COMPOSITE mode we don't have a globally known way to create
built-ins, instead, we have to create them on per-module basis.
So, in this commit we:
1. Use builtInsProvider: (ModuleInfo) -> KotlinBuiltIns instead of
precomputed builtIns instance, in order to be able to calculate
builtIns on per-module basis
2. Introduce new entity, called BuiltInsCache, which, roughly
speaking, is a map of form ModuleInfo -> KotlinBuiltIns, to prevent
creation of multiple builtInsInstances
NB. Actually, it's of form BuiltInsCacheKey -> KotlinBuiltIns, because
we shouldn't create new builtIns for each module. Also, currently,
each platform has its own BuiltInsCacheKey implementation, because
parameters by which built-ins are created, are a bit different across
different platforms. Ideally, we should eliminate those differences
and they use one concrete implementation as a key.
As consequence, remove IdePlatformKindTooling.resolverForModule, because
it became more than just field, and it duplicates similar API in
IdePlatformKindResolution anyways
Unlike previously, this optimisation works on every callee return type.
Tail-calls inside unit functions can be either
INVOKE...
ARETURN
or
INVOKE
POP
GETSTATIC kotlin/Unit.INSTANCE
ARETURN
The first pattern is already covered. The second one is a bit tricky,
since we cannot just assume than the function is tail-call, we also need
to check whether the callee returned COROUTINE_SUSPENDED marker.
Thus, resulting bytecode of function's 'epilogue' look like
DUP
INVOKESTATIC getCOROUTINE_SUSPENDED
IF_ACMPNE LN
ARETURN
LN:
POP
#KT-28938 Fixed
annotationsViaActualTypeAliasFromBinary.kt is ignored because
ExpectActualRemover can't find actual for the expected constructor of
Anno now, because `ExpectedActualResolver.findActualForExpected`
incorrectly filters out actual declarations without any source file, and
Java classes loaded in the fast mode don't have any source files.
This will need to be fixed separately, probably by making
ExpectedActualResolver look for the actual class of an expected class
member first (with source file-based filtering), and then
unconditionally locating the corresponding member there
After b602c08773, this test started to put all .java files to the
dependencies when compiling .kt files, _in addition_ to the already
compiled class files from those Java sources. This is incorrect because
the test should actually check how Kotlin compiles _against_ Java
binaries. The other behavior (compiling against Java sources) is already
supported and used in normal box tests with .java sources.
However, we can't simply filter out all .java files before calling
`super.doMultiFileTest` because many of those contain directives
(WITH_RUNTIME, FULL_JDK, etc.) and we should load them in
`CodegenTestCase.compile`. As a workaround, remove '.java' file
extension to prevent their compilation but still be able to resolve
directives.
This commit doesn't change behaviour of any inference algorithm, it
introduces opportunity to switch constraint system that is used for
overload resolution and fix problematic cases by changing one enum
entry.
Due to fundamental changes, there are cases where a new inference
algorithm reports overload resolution ambiguity errors (#KT-31670,
#KT-31758), which is correct from its point of view. However, this is
a breaking change and to really make it, we should be very confident
and have enough motivation for it, therefore, we don't change behavior
now in order to collect more examples (if there are any). And if we
find a lot of erroneous examples, we'll be able to change the behavior
quite simply
- implement wrappers to wrap old and new API providers and resolvers
- make old API deprecated (with error where possible)
- drop old internal classes related to the old API
- refactor usages accordingly
- fix and add missing features to the scripting API where necessary
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.
Essentially, this function was used solely for setting
'useBuiltInsProvider' to 'true'; otherwise it were just delegating to
createContainerForLazyResolveWithJava, which were just increasing the
noise.
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)
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
Simon Ogorodnik