Provide a command-line option to load built-ins from the module and its
dependencies instead of looking for them in kotlin-compiler.jar; built-ins must
be found this way, or an error will be reported (or, most likely at this
moment, an exception will be thrown).
Note that this does not affect whether built-ins (loaded from one place or the
other) are added to the _dependencies_ of the module, this is controlled by
another option. The option added in this commit only makes the KotlinBuiltIns
instance which is used via ModuleDescriptor throughout the compiler front-end
(and also injected in a bunch of places) a sort of "helper" which always goes
to that same module to find descriptors for built-in classes
Introduce a new method KotlinClassFinder#findBuiltInsData, which is only
implemented correctly in the JvmCliVirtualFileFinder because it's only used in
the compiler code at the moment.
Introduce JvmBuiltInsPackageFragmentProvider, the purpose of which is to look
for .kotlin_builtins files in the classpath and provide definitions of
built-ins from those files.
Also exclude script.runtime from compilation because, as other excluded
modules, it has no dependency on the stdlib and is no longer compilable from
the IDE now, because it cannot resolve built-ins from anywhere
In subsequent commits, a JVM module will be able to have up to two package
fragments for a given package FQ name. For example, for package "kotlin" in
kotlin-runtime.jar there will be a LazyJavaPackageFragment with binary
(Kotlin+Java) dependencies, and a BuiltInsPackageFragment for built-ins
metadata (which is loaded from kotlin/kotlin.kotlin_builtins)
Use the same approach that is used for creating function type classes
(Function{0,1,...}) + add Cloneable to supertypes of Array and primitive arrays
#KT-5537 Fixed
Use it instead of mapPlatformClass where we only need to check emptiness
because mapPlatformClass requires built-ins and it's not always easy to come up
with the correct instance of built-ins.
In KotlinEvaluationBuilder, use the nullable function
findClassAcrossModuleDependencies instead of mapPlatformClass which uses the
throwing resolveClassByFqName. This is necessary because DefaultBuiltIns, which
are used there, are not always able to find classes mapped by a _Java_ to
Kotlin class map. (The correct solution would be not to use DefaultBuiltIns at
all, instead obtaining the correct instance of built-ins, which are almost
certainly going to be JvmBuiltIns, from the project configuration.)
Just reporting error by call checker may be too restrictive
in case there are some extensions that can be used successfully
Solution is to annotate additional members with
@Deprecated(level=Error) + @kotlin.internal.LowPriorityInOverloadResolution
Do not treat members with already changed signature as a reason
to create a hidden copy
See tests for clarification:
- There are `charAt` method in B that has different name in Kotlin - `get`,
i.e. relevant descriptor has initialSignatureDescriptor != null
- When collecting methods from supertypes, `charAt` from A is also get
transformed to `get`
- So it has effectively the same signature as B.get (already declared)
- If by an accident B.get had been declared with Kotlin signature
we would have add A.charAt (after transformation) with special flag:
HiddenToOvercomeSignatureClash (hides it from resolution)
- But here B.charAt was artificially changed to `get`, so no signature clash
actually happened
#KT-13730 Fixed
Effectively all custom logic was moved from MemberIndex to JavaScope classes,
and as member names are being cached there, so it prevents repeating supertypes
traversal (see getAllMemberNames extension)
Do not use memoized function if member with given name is not contained in the scope
There are a lot of queries with names of non-existent functions, that leads to many
effectively redundant Map nodes in MemoizedFunction and also cause
additional computation that is worth to compute at once
To indicate that repeating calls to them may require additional computations
Also change second parameter to be nullable, this will be necessary in the next commits
Also provide some basic implementation
The main purpose of these methods is optimization.
Most of the member scopes store mapping from names to descriptors
MemoizedFunction<Name, Collection<Descriptor>>
While there are 10 functions in class in average, there are a lot of
queries with names of non-existent functions, that leads to many
effectively redundant Map nodes in MemoizedFunction and also cause
additional computation that is worth to compute at once
If deserializing a type with arguments based on a local class for
decompiler, then just return Any type (without arguments).
Previously Any constructor was used with serialized arguments, that lead
to exception
Note that in case of deserialization for compiler nothing changes about
local-classes-based types (LocalClassifierResolverImpl is just inlined)
#KT-13408 Fixed
- First parameter should have type of K instead of Any
- Special bridge should return second parameter if a key has wrong type
- Special bridge may throw an exception if defaultValue has wrong type
#KT-13209 Fixed
Basically what's it checked before is that
receiver is a valid override of raw version of builtinWithErasedParameters
While we need to check that method has the same JVM descriptor as builtinWithErasedParameters,
but it's not a valid override of latter
It's important for 'getOrDefault(Object k, V value)' ('getOrDefault(K k, V value)' in Kotlin):
'getOrDefault(Object k, V value)' is not override of 'getOrDefault(Object k, Object value)',
that leads to incorrect loading of former method (like it's not an override of declaration in Map)
It works only for Java methods and it's purpose is Java overridability rules emulation,
namely distinction of primitive types and their wrappers.
For example `void foo(Integer x)` should not be an override for `void foo(int x)`
#KT-11440 Fixed
#KT-11389 Fixed
Alexander Udalov