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
Observations:
- In case of !requiresPosition we don't need to track position
- Also, in the latter case we don't need scopeKind (implicit contract)
- There were a lot of LookupInfo instances having two references
(fileName/scopeFqName) pointing to the same strings.
Looks like in common case (reasonable amount of files/fqnames) it's more
sensible to group lookups in the two-level-tree (implemented with nested maps)
It's expected to decrease memory consumption up to 15M in case of compiling
`idea` module in Kotlin project
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.
- Calling suspend functions is allowed
- Presence of suspend function type still makes declaration
unusable unless it belongs to a value parameter as a top-level type
containing less then three parameters
Still, warning should be emitted because they will become unsupported in 1.4
#KT-25683 In Progress
When two functions with matching JVM signatures in the same package
were inlined sequentially, inliner could take a wrong method body from
the cache due to MethodId clash. This manifested with inline classes,
but also was possible with some legal Kotlin overloads with matching
erasure.
Use internal name of the corresponding implementation owner class
instead of FQN of the containing declaration. Such MethodIds can't match
accidentally, because corresponding JVM method signatures would clash.
Yan Zhulanow