- 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
Consider common supertype of `S` and `Nothing`, where `S` has nullable
upper bound or it's flexible. Before the fix, result was `S?`, which
is correct but too conservative. Now, we'll preserve nullability of
resulting type if it's already nullable.
This happened because we were failing to find path of not-nullable
types from `Nothing` to `S`, which should obviously exists by
semantics of Nothing
This was broken in c1ab08c8ce where we started to represent KClassValue
as a ClassId of the referenced class + number of times it's been wrapped
into kotlin.Array. Local classes do not have a sane ClassId, so in this
change we restore the old behavior by representing KClassValue with a
sealed class value instead
#KT-29891 Fixed
In general case, the module where built-ins are looked up
(builtInsModule) can have multiple package fragments corresponding to
the package "kotlin". Remove the misleading method
getBuiltInsPackageFragment along with its implementation details and use
the package view's scope instead (by changing
KotlinBuiltIns.getBuiltInsPackageScope), since it'll iterate over all
fragments accessible in the module and its dependencies.
The only difference between scopes of package fragment and package view
is that the latter also contains package views for subpackages, which is
why the change in BuiltInsReferenceResolverTest is necessary
Bypass builtins deserialization mechanism in legacy JS backend and load
bultins direcly as kotlin code.
This way we won't have separated IR declarations for Enum, Char, Long
Some "native" builtins are implemented in libraries/stdlib/js/irRuntime/builtins/
Other builtins are moved by MoveExternalDeclarationsToSeparatePlace and
used only in compile-time
Now both of those classes implements one interface with `TypeProjection`
property. That allows old captured type approximator use new captured types.
That change fixes tests related to diagnostics:
- SETTER_PROJECTED_OUT
- DEBUG_INFO_UNRESOLVED_WITH_TARGET
- UNRESOLVED_REFERENCE_WRONG_RECEIVER
Also `typeProjection` property renamed to `projection` according to naming in NI.
* if enum class has abstract members, then it is ABSTRACT
* otherwise, if enum class has entries with members, then it is OPEN
* otherwise, it is FINAL.
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
There's no need to add "values"/"valueOf" methods for them
(see com.intellij.psi.impl.compiled.StubBuildingVisitor#visitMethod that ignores them too)
We already have tests that check enum entries/synthetic methods
are properly resolved in Java:
idea/testData/kotlinAndJavaChecker/javaAgainstKotlin/*Enum*
{ T : Any? & Foo & Bar? }!! -> { T!! & Foo & Bar }
Also, fix bug with loosing non-representative number type.
For example, for type { Byte & SomeType } we lost type `Byte` because
`getDefaultPrimitiveNumberType` returns null for it
Fixes #KT-28334 for NI
In previous commits, renderValueParameter began to calculate its
containing declaration. However, WrappedValueParameterDescriptor
assumes that parent of IrParameter is IrFunction, which is not true
for dispatch receiver parameters. The correct fix would be not to create
WrappedValueParameterDescriptor for dispatch receivers at all and use
WrappedReceiverParameterDescriptor instead. In this fix, I just moved
parameter' containing declaration calculation inside specific option
which is usually false, thus hiding the found problem.
Dmitry Gridin