- Mark @ContractsDsl as @Experimental
- Move Contracts DSL out from 'internal' package
- Change visibility of ContractsDsl from 'internal' to 'public'
^KT-25274 Fixed
^KT-25495 Fixed
This commit effectively reverts
d386712903.
The reason is that when using a release language version, you can only
"see" the subset of a pre-release library which consists of released and
supported features, so reporting an error is not helpful there. Also, it
presents a problem currently when using kotlinc 1.3 (which is
pre-release) with language version 1.2 (stable) against the bundled
stdlib of version 1.3 (pre-release)
#KT-21267 Declined
Set LATEST_STABLE language version and current version of stdlib to 1.3, set IS_PRE_RELEASE
Remove "EXPERIMENTAL" from 1.3 version description in tests and gradle options
This commit reverts 59e2101a25 partially,
leaving only the implementation of KT-25972 for JVM. The reason is that
we can't fully commit to stabilizing JS (and .kotlin_metadata) binary
metadata formats so much as to postpone any changes done to it for a
whole release year time. It's likely that we will need to update JS
metadata format incompatibly pretty soon, and with the scheme where we
can read the "current + 1" version, it'd require advancing the metadata
version by 2, which would break the nice property that the metadata
version (since Kotlin 1.4) is equal to the version of the compiler that
produced it.
See KT-25972
JVM versions are increased in order to differentiate pre-1.3-M2 .class
files where signatures mentioning inline classes were not mangled. Other
versions are increased in case something similar will need to be
detected
This commit reverts f6571effcc and
reimplements the desired logic in another way.
In particular, we'd like these two conditions to hold:
1) only the release compiler with stable language settings (meaning,
language version is a released version of Kotlin and no experimental
features are enabled) should report errors when _reading_ pre-release
binaries.
2) the compiler should _write_ pre-release binaries only if language
settings are not stable, independent of whether the compiler itself
is release or not.
From these conditions it follows that we must use different logic to
determine how to behave when reading/writing pre-release binaries.
Namely, reading (in CompilerDeserializationConfiguration) now checks if
both the compiler is release and the language settings are stable, and
writing (in LanguageVersionSettings.isPreRelease) checks only that the
language settings are stable
This commit effectively reverts
d386712903.
The reason is that when using a release language version, you can only
"see" the subset of a pre-release library which consists of released and
supported features, so reporting an error is not helpful there. Also, it
presents a problem currently when using kotlinc 1.3 (which is
pre-release) with language version 1.2 (stable) against the bundled
stdlib of version 1.3 (pre-release)
#KT-21267 Declined
Already existing tests testRequireKotlinInNestedClassesAgainst14{,Js}
now check that there's no error when loading a module/class with
metadata version 1.4.0
#KT-25972 Fixed
The `include` calls were effectively made on the `resources`
`SourceDirectorySet`, which meant including '**' from 'src' as well.
Since the 'SourceDirectorySet' API is quite limited and does not support
specifying includes/excludes separately, configure the
`ProcessResources` task instead.
Previously, enum entries were treated by the data-flow subsystem similar
to other class/singletons. As a consequence, calls like
'Enum.ENTRY.property' had IdentifierInfo of 'property'.
However, specially for enum entries, descriptor of 'property' is one and
the same for all entries. It means that from the data-flow point of
view, 'Enum.ONE.property' and 'Enum.TWO.property' are *one and the same
data-flow values*.
It could obviously lead to some bogus smartcasts, so this commit
introduces separate IdentifierInfo.EnumEntry and uses it to build proper
qualified values.
^KT-20772 Fixed
The implementation is a bit obscure because this worked on JS since
Kotlin 1.0 and we should not break that; however, on JVM, a diagnostic
will be reported with old language/API version
#KT-25241 Fixed
The only client of this data is reflection, and since anonymous objects
do not have constructors in the source code, they shouldn't in
reflection as well
#KT-20442 Fixed
The call to `createTopLevel` instead of `create` (which creates
serializers for outer classes properly, with correct type parameter
contexts) caused MetadataSerializer to write type parameter metadata
incorrectly. For example, in the following case:
class A<E> {
inner class B<T, E> { ... }
}
A's type parameter E would get id 0, and B's type parameters T and E
would get ids 0 and 1. This is a problem because ids are supposed to be
unique for each class including its outer classes, and deserializer,
decompiler and stub builder rely on this assumption.
JVM metadata is unaffected because `create` is called correctly there,
see MemberCodegen#generateKotlinClassMetadataAnnotation
#KT-24944 Fixed
Supported:
- conversion in resolution parts. Also sam-with-receiver is supported automatically
- separate flag for kotlin function with java SAM as parameters
TODO:
- fix overload conflict error when function type is the same byte origin types is ordered
- consider case when parameter type is T, T <:> Runnable
- support vararg of Runnable
[NI] Turn off synthetic scope with SAM adapter functions if NI enabled
Alexander Udalov