Since we skipped trivial constraint with `Any?` from parameter type of
function `equals`, the compiler thought that there is no proper
constraints (upper bounds do not matter here) and marked resolved
call as a failed one, then diagnostic about missing equals was added
Also, tune `TrivialConstraintTypeInferenceOracle` for `Any?`-like
constraints
#KT-30724 Fixed
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
Follow-up of 9b3e17f0. There we decided to complete call if a type
variable from a return type has proper lower constraints, now we refine
this rule wrt `Nothing`-like constraints to avoid inferring type variables
to Nothing, which is quite useless
#KT-30370 Fixed
The problem is that delegated properties resolve two calls together:
`getValue`/`setValue` with a common receiver, which can contain
callable references. For each completion new anonymous descriptor
was created and caused "rewrite at slice" exceptions later.
Now there is a little hack to check that during one inference session
we don't complete one call more than one time.
More correct fix would be to explicitly specify common receiver for
inference session but it requires quite big refactoring, which will
be done later with a whole refactoring of the common solver
#KT-30250 Fixed
- Port NewKotlinTypeChecker.equalTypes
- Decouple new-type transform from isSubtypeOf
- Port isSubtypeForSameConstructor
- Port checkSubtypeForSpecialCases
- Port isSubTypeOf without internals
- Port anySupertype
- Port isSubtypeForSameConstructor, findCorrespondingSupertypes
- Port isSubtypeOfForSingleClassifierType
- Port NullabilityChecker
- Reorder checks for performance
Even though acquire/release pattern guarantees memory visibility across
threads, it doesn't prevents concurrent access to critical section (i.e.
to force-resolve of the corresponding body).
This can lead to multiple resolution passes over one and the same PSI in
IDE, which, in turn, leads to 'rewrite at slice'-exceptions. See
KT-30030 for case description and details.
^KT-30030 Fixed
Add some classes to hierarchy of `ESValue`:
- `ESReceiver` -- representation of receiver
of lambda function
- `ESDataFlow` and `ESDataFlowReceiver` -- little refactoring of entities
that holds information for DFA (description in comments in code).
Also add kdoc to classes of `ESValue` hierarchy
Default built-ins represent built-ins loaded from the compiler jar via
class loader, and they may not be equivalent to the built-ins present in
the standard library that is used in compilation dependencies, in case
the compiler and stdlib versions do not match. Use built-ins from the
given module instead.
This commit deals with more-or-less obvious usages of DefaultBuiltIns;
next commits refactor the ESConstant values and related code to support
injected built-ins
Instead use a filter with a simple check. This seems to be slightly
better both for readability (`strictPartition` gave an impression that
two its parameters were related in some way, but they were totally
independent) and for performance (do not create unnecessary objects,
instead decompose the existing objects and check their structure)
Consider following expression: 'call() is Foo'. Suppose that we know
something about the 'call()', e.g. 'returns(foo) -> <condition>'
Previously, we've tried to re-use knowledge about 'call()', constructing
some smart clause, like 'returns(true) -> foo is Foo && <condition>'.
The conceptual error here is that *we can't* argue that <condition>
holds. Imagine that 'call()' actually has unspecified 'returns(foo2) ->
<!condition>', and 'foo2 is Foo' also holds. Then we would get
'returns(true) -> foo2 is Foo && <condition>' <=> 'returns(true) ->
<condition>' for the whole call, which is not correct.
More concrete example would be something like:
'if (!x.isNullOrEmpty() is Boolean)'
^KT-27241 Fixed
Functor is an imperative representation of function's contract (contrary
to ContractDescription, which is a declarative one). ContractDescription
is convenient when we deal with sources of contracts declarations
(binaries, source), while Functors are convenient for analyzing code
with contracts.
It means that we have to convert ContractDescription into Functor when
we start working with contracts. This computation isn't trivial, and
Functor and ContractDescription are in 1-1 correspondence, so we would
like to cache Functor for each ContractDescription somewhere.
We used to do this in binding trace, in slice FUNCTOR.
Now, it turns out that this approach causes "Rewrite at slice"
exception, see KT-28847. We won't go into details of why that happens
here, you can see the issue comments for details (but be prepared for the
very long and nitty-gritty story)
This commit removes the problematic slice and introduces another
approach, where Functor is attached to the ContractDescription, computed
lazily and cached here.
^KT-28847 Fixed
Input and output types are crucial for type variable fixation order and
analysis of postponed arguments (callable references, lambdas).
Specifically, if there is non-fixed type variable inside input types of
a callable reference, then we'll postpone resolution for such callable
reference.
Initial example with the expected type `KMutableProperty1<*, F>` caused
problems because input types were computed incorrectly (while there
aren't input types here)
#KT-25431 Fixed
Mikhail Zarechenskiy