This commit introduces TypeConstructor.refine method.
It's implementation can be roughly split in three parts:
- trivial implementations which just return 'this': mostly, it used for
typeConstructors which can not be refined at all (e.g.
IntegerValueTypeConstructor and other special cases of constructors)
- delegating implementations which call 'refine' recursively for
component typeConstructors -- obviously, they are used in composite
typeConstructors (like IntersectionTypeConstructor)
- finally, the most interesting one is in 'AbstractTypeConstructor'
which returns lightweight wrapper called 'ModuleViewTypeConstructor'.
The idea here is to propagate refinement to supertypes without eagerly
computing them all.
VERY IMPORTANT CAVEAT of TypeConstructor.refine is that call to this
method CAN NOT add new supertypes, so returned supertypes are not
entirely "valid". See the KDoc for TypeConstructor.refine for details
Candidate ordering should be the same in ordinary Kotlin code and in evaluated expressions.
With the invention of 'foo_field' syntax, there is no need to do these nasty things any more.
If new inference is enabled only for IDE analysis, then this feature
will be disabled to reduce difference between new and old inference,
but if new inference is enabled in the compiler, then this feature
will be enabled too to preserve behavior of new inference for
compilation
#KT-32175 Fixed
#KT-32143 Fixed
#KT-32123 Fixed
#KT-32230 Fixed
This call have interesting rules for resolution, see
`KtQualifiedExpression.elementChain` function and it's usages:
resolution results for such call can be omitted and be replaced with
some other information, while diagnostics will be reported from
builder-inference.
To mitigate this problem, we'll just skip this call from builder-inference
as such calls can't have type parameters anyway
#KT-32094 Fixed
Consider call `foo(bar())` where bar() returns some type variable `T`;
We had a contract that call `bar` can be completed without completion
of foo (type variables can be inferred from the current context) if `T`
has at least one proper lower constraint (ProperType <: T).
Indeed, new constraints can be added only as upper ones, so there is
no need to grow constraint system.
Unfortunately, we have Exact annotation that is used on return type of
elvis. Now, consider the following situation:
```
fun foo(a: Any) {}
fun bar(e: T): @Exact T
foo(bar("str"))
```
Here, because of Exact annotation, constraint with `Any`-type will be
added as an equal one => our prerequisite that there will be no new
lower constraints is false. `bar("str")` is inferred to Any in OI,
this seems conceptually wrong, but it's another topic of discussion.
In NI we can't just grow constraint system to use outer call because
of another important use-case:
```
fun <T> generic(i: Inv<T>) {}
fun test(a: Inv<*>?, b: Inv<*>) {
generic(a ?: b)
}
```
Common constraint system for these two calls can't be solved
(fundamentally) for this example, only if (a ?: b) and generic(result)
are computed separately.
So, to mitigate initial issue, we'll grow constraint system only if
there is at least one non-proper constraint.
#KT-31969 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
'getContributedDescriptors' isn't obliged to apply filters, inlcuding
kindFilter, and may return declarations of different kind, so we have to
call 'filterIsInstance' explicitly
It's enough to have at least one good constraint.
Note that the whole algorithm can be a bit more general:
we could check also Out<T>, In<T> and verify that T has good only
lower constraint or upper constraint, but there are questions for
types like Inv<Out<T>>, where T should have lower and upper constraints
#KT-31514 Fixed
This commit introduces the ability to register a PlatformExtensionClashResolver
in a container. Each PlatformExtensionClashResolver has a corresponding
PlatformSpecificExtensions.
If, during container composition, several instances of
PlatformSpecificExtensions were registred, instead of throwing
InvalidCardinalityException, corresponding PlatformExtensionClashResolver
will be asked to resolve clash.
This allows to make injection more composable and less coupled across
different contributors of service, providing a basis for such motivating
cases as composing containers with both JS and JVM services (for analysis
of multiplatform modules).
Previously, that would be impossible:
a) JS would inject default instances for some services which would clash
with non-default JVM services (like SyntheticScopes)
b) Also, there are a very few services for which *both* platforms provide
non-default implementations, so they should be merged manually on
case-by-case basis (e.g., IdentifierChecker)
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
Mostly, these optimisations are picked from the old inference.
Also, remove exponential complexity for flexible types in approximation,
note that more correct fix for this would be to introduce new types
that corresponds just to platform types to avoid nullability problems,
but due to complexity it will be done later
#KT-31415 Fixed
Also that commit removes usages of builtins inside
effect system and starts refactoring of functor
composition via composition instead of inheritance.
There are some changes in testdata related to inference of recursive
functions with implicit return types.
After this commit they all are marked as unresolved. It happens because
those functions have DeferredType as return type, and computing this
type produces recursive exception, which provides “typechecker
recursive problem” diagnostic.
Before this commit, function call was completed successfully, because
call completer didn’t computed that type, and computation of DeferredType
were triggered only in `DataFlowAnalyzer.checkType`.
Now, effect system tries to compute that type while wrapping KotlinTypes
into ESTypes, and effect system itself is triggered in in call completer,
so, call completion doesn’t finish and function call is marked as unresolved.
#KT-31364
It breaks `org.jetbrains.kotlin.nj2k.NewJavaToKotlinConverterSingleFileTestGenerated.ToArray#testToArray` test due to losing external nullability annotations
Dmitriy Novozhilov