merging `LLFirSelectingCombinedSymbolProvider.selectFirstElementInClasspathOrder`
relies on the fact that a candidate belongs to exactly one module.
This can be not true for libraries, attached to multiple modules.
In that case we need to accept "wrong module" to retrieve correct provider
when source for compiled fir elements is set, it leaks e.g. to diagnostics,
which is then filtered
see `TestsWithStdLib.Experimental.testImplicitUsages`
Use the same condition as in the already existing `createIrEnumEntry`
function (and as in psi2ir): enum class should be final unless there's
an enum entry with any declaration other than its constructor.
#KT-57216
since we generate the default getter in this case in
Fir2IrDeclarationStorage.createIrProperty, so the serialized metadata
should follow the same behavior.
#KT-57373 fixed
Adds @AcceptablePropertyValues annotation that accepts comma-separated
property values that could be used. If the value set from the command
line or as an enforced one is not in the list the default value will be
used instead.
- return single instance of emptySet for build method from SetBuilder
- return single instance of emptyMap for build method from MapBuilder
- return single instance of emptyList for build method from ListBuilder
^KT-54739 fixed
Do not include delegated field into generated constructor even though it
might have backing field.
Test that shows issue was added. Properties that are explicitly marked
as delegated are now excluded.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2091
Once configured this property changed default language version
convention for all compiler options to '2.0'.
On usage, it produces a warning that it should not be used in
production.
^KT-57736 In Progress
There's a heuristic for approximation of a captured type that once
it has non-trivial lower bound (other than Nothing), it's worth
approximating it to sub-type even while the containing
top-level type is being approximated to super-type.
And that sounds reasonable in case the lower bound is indeed non-trivial,
but that's not the case because nullability here comes from
the nullability of captured type position.
So, the fix is basically not to treat such approximations as non-trivial.
And while that seems to be a bit of a change in the language semantics,
it still looks reasonable (see other changes in test data and KT-58087)
^KT-57958 Fixed
^KT-58087 Fixed
While plainly repeating K1 behavior might be a dumb solution,
but inventing another one might be quite complicated
because we need to stop fixing variables into Nothing in many cases,
but probably not in all of them (see KT-58232).
^KT-58149 Fixed
^KT-58232 Related
Anna Kozlova