In case Java enum has an abstract member, it has the ACC_ABSTRACT flag
set in the bytecode. However, we should still load it with final
modality to be consistent with Kotlin enums which are always considered
final
#KT-23426 Fixed
We would like DeclarationDescriptor.getOriginal() to always point to a
(preferably unique) unsubstituted descriptors for the given possibly
substituted descriptor. In case of LazySubstitutingClassDescriptor
(which can be observed for nested generic Java classes), this invariant
was broken, because 'getOriginal()' for constructors of substituted
class returned a copy created for this particular substituted class.
Cleanup TypeConstructors & KotlinTypes in VariableFixationFinder
Cleanup TypeConstructors & KotlinTypes in TypeVariableDirectionCalculator
Cleanup KotlinTypes in TypeCheckerContext for ConstraintSystem
Cleanup KotlinTypes in NewCommonSuperTypeCalculator
Cleanup KotlinTypes in TypeApproximator
Cleanup type substitution
Cleanup NewTypeVariable
Cleanup StubType
Cleanup TypeCheckerContext creation, extract common supertype context
Provide TypeSystemInferenceExtensionContext via dependency injection
Previously, we used a pretty roundabout way to load a MemberScope from a
single file facade represented by KPackageImpl, which involved going
through ModuleDescriptor, PackageFragmentProvider, PackagePartProvider
etc. The only advantage of this approach was that it sort of works
similarly as in the compiler, however mutable state in
RuntimePackagePartProvider and the fact that .kotlin_module files were
required for this to work diminished this advantage.
In this change, we load MemberScope from a KPackageImpl pretty much
directly, by using the existing method
`DeserializedDescriptorResolver.createKotlinPackagePartScope` and
caching the result in the new component PackagePartScopeCache.
#KT-30344 Fixed
This removes the mandatory dependency of all JVM IR tests on
kotlin-stdlib (ConfigurationKind.ALL in all IR test cases) and speeds up
tests which don't need kotiln-stdlib by about 20%. Another advantage of
this method is that all required dependencies are listed in one file,
are easy to grasp, and changes to the related code generation can be
done independently of the corresponding changes in the actual library,
which may help in bootstrapping the compiler
For functions with implicit return type annotations will be replaced
anyway in order to initialize return type, so this restriction in
`StubType` was too strong
#KT-30656 Fixed
Add `IntegerLiteralTypeConstructor` that holds types, that can take
integer literal with given value. It has two supertypes
(`Number` and `Comparable<IntegerLiteralType>`) and have
special rules for subtyping, `intersect` and `commonSuperType`
functions with primitive number:
Example (assuming that ILT holds Int type):
* ILT <: Int
* Int :> ILT
* ILT intersect Int = Int
* commonSuperType(ILT, Int) = Int
#KT-30293 Fixed
#KT-30446 Fixed
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
Dmitriy Novozhilov