Preface: Kotlin 1.3 will be able to read metadata of .class files
produced by Kotlin 1.4 (see KT-25972). Also, to simplify implementation
and to improve diagnostic messages, we're going to advance JVM metadata
version to 1.4.0 in Kotlin 1.4, and would like to keep it in sync with
the compiler version thereafter. This presents a problem: in an unlikely
event that before releasing 1.4, we find out that the metadata-reading
implementation in 1.3 was incorrect, we'd like to be able to fix the bug
in that implementation and _forbid_ 1.3 from reading metadata of 1.4.
But prior to this commit the only way to do this was to advance the
metadata version, in this case to 1.5, and that breaks the
metadata/compiler version equivalence we'd like to keep.
The solution is to add another boolean flag to the class file, called
"strict metadata version semantics", which signifies that if this class
file has metadata version 1.X, then it can only be read by the compilers
of versions 1.X and greater. This flag effectively disables the smooth
migration scenario proposed in KT-25972 (as does increasing metadata
version by 2), and will be used only in hopeless situations as in the
case described above.
Note that this change brings an incompatibility: `Array<Foo>::class`
will be seen as `Foo::class` by the old deserializer. We consider this
OK because the compiler never had any logic that relied on reading class
literal arguments correctly (otherwise it wouldn't have worked because
it could only see `Array<*>::class` before this commit), and the support
of annotations on types in JVM reflection is only available in the
upcoming 1.3 release (KT-16795)
#KT-22069 Fixed
- 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
Denis Zharkov