before core env construction. Refactor script evaluation extension to
this scheme.
Plus some refactorings of the logic of script/repl evaluation in K2JVMCompiler
There is no need to track definitions of constants in sources for now.
References to constants are tracked in order to capture dependencies between types.
This ensures that any change to a type defining a constant (either from the
classpath or sources), will trigger reprocessing of the type that uses the
constant.
1) Fix tests to use canonical path for comparison because Mac was failing
2) Update current classpath snapshot only with the missing entries from the previous one
3) Clean-up code and style
Use artifact transforms to capture structure and
dependencies of classpath entries. In the KAPT task
this information is used to compare previous classpath
structure with the current one. Once changed classes are
detected, all classes that transitively depend on those
are identified, and that set is passed to KAPT invocation.
In order to avoid unrelated classpath changes, we record an
ABI snapshot of the classpath entry. This snapshot ignores
all private members, and @Metadata annotation.
#KT-23880
Pass computed list of changed classpath names to KAPT instead
of relying on the history files to be computed by stub generation.
Also, stop generating classpath history changes during the stub generation.
This commit does not compute the actual changed classpath entries,
and that will be done in the following commits.
#KT-23880
This commit adds support for tracking of used constants in
source files. For every constant used in a source file, class
that defines the constant and the constant name are tracked.
Value of the constant can be obtained using
annotation processing APIs, so if the constant value changes, a source file
using it has to be reprocessed.
#KT-23880
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
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
Up-to-date check is very heavy for intellij repo due to artifact size.
If module directory in repo is written only by one task we can assume
that task if up-to-date if target directory exists.
Ilya Chernikov