Other related tests:
- testGenericJavaProperty
- testFunInterfaceConstructorReference
Meta issue: KT-8575
Review: https://jetbrains.team/p/kt/reviews/9595
UnsupportedSyntheticCallableReferenceChecker only existed for K1,
because we wanted to release the feature for 1.9 and the feature should
have been working for K2 unconditionally. But since, we're postponing
the release until 2.1, we also need to port the checker from K1 to K2
The issue is that during binding fake overrides, the compiler doesn't
differ setters from its properties, so the compiler uses the same
visibility for setter and entire property.
Changing logic at the binding stage can cause some unpredictable consequences so
the fix is to do this differentiation right at the reporting stage
^KT-56662 Fixed
Merge-request: KT-MR-9565
Merged-by: Michail Zarečenskij <Mikhail.Zarechenskiy@jetbrains.com>
The compiler should only report diagnostics for
comparisons over builtins and identity-less types,
other incompatibilities should be reported
via inspections.
It's ok that in `equalityChecksOnIntegerTypes`
instead of `EQUALITY_NOT_APPLICABLE_WARNING` we get
`EQUALITY_NOT_APPLICABLE`, because
`ProperEqualityChecksInBuilderInferenceCalls`
is already active by default.
This change also replaces the notion of a representative superclass
with the least upper bound.
This makes complex types like
intersection/flexible transparent to
RULES1-based compatibility checks.
One way to look at it is to think
that this is an automatic way of handling
type parameters: automatic picking of
"interesting" bounds, and checking them against one another.
Note that `TypeIntersector.intersectTypes`
for `Int` and `T` where `T` is a type parameter
may return both `{Int & T}` or `null`
depending on `T`-s bounds. At the same time,
for type parameters `T` and `K` it will
always return `{T & K}`.
`ConeTypeIntersector.intersectTypes`, on the
other hand, will always return `{Int & T}`
irrespectively of the bounds. Meaning, the two
intersectors differ in corner cases.
`lowerBoundIfFlexible` call in `isLiterallyTypeParameter` is backed by
the `equalityOfFlexibleTypeParameters` test.
^KT-35134 #fixed-in-k2
^KT-22499 #fixed-in-k2
^KT-46383 #fixed-in-k2
Note: here we set sinceVersion = null for this feature.
However, we plan in 1.9.* - 2.0 time frame to solve KT-56377
and to enable this feature in 2.0, the latest in 2.1.
This is required to be able to compile KGP and it's dependencies which
set LV to 1.4 when repo will use LV 1.9. This caused by the change how
enums are compiled (KT-48872).
JS IR BE incremental compilation infrastructure uses
LanguageVersionSettings::toString method to detect if any
compiler features or flags were enabled or disabled.
It is important that the features and flags order are stable
in the result string.
^KT-56580 Fixed
This fixes test failures when advancing bootstrap.
When a language feature has UNSTABLE_FEATURE kind, enabling it causes
the compiler to mark the compiled library with the pre-release flag.
JsAllowImplementingFunctionInterface feature is enabled by default in
Wasm backend. So effectively, all Wasm klibs are marked with the
pre-release flag, including the standard library.
Pre-release checks were enabled recently and cause compiler errors.
To fix the problem, this commit changes the feature kind to OTHER, which
doesn't enforce the pre-release flag.
Merge-request: KT-MR-8582
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
- In contrast to other kinds of dependencies, `dependsOn` dependencies
must be followed transitively.
- Add `transitiveDependsOnDependencies` to `KtModule`. These
dependencies are calculated lazily with a topological sort. They are
added to the dependency provider when it's built in
`LLFirSessionFactory`.
^KT-55329 fixed
This commit means that we will not see K2 DFA warnings until
we explicitly enable them (probably in 1.9.20 or 2.0).
We are going to enable DFA warnings at the moment when
K2/IDE is accessible for external users
When a language feature has UNSTABLE_FEATURE kind, enabling it causes
the compiler to mark the compiled library with the pre-release flag.
JsAllowValueClassesInExternals feature is enabled by default in JS IR
backend. So effectively, all JS klibs are marked with the pre-release
flag. This remained unnoticed because the compiler currently doesn't
read this flag from klibs. This will change soon.
To fix the problem, this commit changes the feature kind to OTHER, which
doesn't enforce the pre-release flag.
This checker was enabled only on JVM by mistake.
It's now fixed, but we don't want to make it an error in minor release.
So it will be an warning in 1.8.20 and an error in 1.9.0
^KT-27002
The main reason is a bug in deserialization(KT-55357) that doesn't allow
to deserialize some binaries compiled with that feature enabled.
While we might fix it in 1.8.0, it doesn't help because previous
compilers, e.g. 1.7.0 still may break when using freshly recompiled
libraries.
Considering, that almost any meaningful fix might look unsafe for
the almost released 1.8.0, we can't enable the feature even in 1.9,
because 1.8.0 compilers wouldn't read those libraries anyway.
So, effectively this feature will be only enabled in K2.
^KT-55357 Related
^KT-36770 Related
This feature is not needed because it is unconditionally disabled for K1
(because of not fully correct implementation) and unconditionally enabled
in K2 (K2 does not support old behavior)
^KT-38895
- Allow 'lateinit' for inline classes which underlying type
is suitable for 'lateinit'
- K2: report all problems related to 'lateinit' modifier
^KT-55052: Fixed
JS scripting uses the old IR to JS transformer.
The new IR to JS transformer can not be used for
JS scripting out of the box. Patching the new transformer for
JS scripting is potentially dangerous and requires a lot of effort.
Dropping JS scripting and the old IR to JS transformer allows to
refactor and simplify JS BE codebase.
Review: https://jetbrains.team/p/kt/reviews/7418
`State` enum contains `DISABLED` item which is redundant for
`LanguageFeature`. It's redundant because `sinceVersion = null` is used
to express the same semantic.
I had to reorder some items in the enum because otherwise
`testLanguageFeatureOrder` fails. I could keep the same logic in
`testLanguageFeatureOrder` but I would need to make
`isEnabledWithWarning` public which I don't want to. Anyway, it's not
obvious what is more readable: keep `isEnabledWithWarning = true` items
at the end or at the beginning.
Also all effectively disabled features (`sinceVersion = null` or
`defaultState = State.DISABLED`) are now moved to the "Experimental"
section at the end which is obviously better.
Related issue: KT-48872
Review: https://jetbrains.team/p/kt/reviews/7418
If we want to make the feature experimental then specifying
`sinceVersion` higher than the current compiler version is enough.
`defaultState = State.DISABLED` is redundant
Nikita Bobko