- just legacy - report warning about deprecation
- both - report warning about deprecation of legacy
- no compiler explicitly chosen - error about explicit setting compiler
warn from cli legacy compiler
nowarn flag - kotlin.js.compiler.nowarn
KT-42326
KT-53074
JS IR generates bridges with type checks for special class methods,
however if parent and child type parameters are same,
the JS signature for the generated brige will be clashed with
the JS signature of original method.
This patch changes type parameter name of EnumEntriesList to avoid the clash.
^KT-54011 Fixed
#KT-53947 fixed
without the fix, in the presence of the implicit receiver of the same
type as the processed receive, the lowering was incorrectly substituting
the correct receiver with the accessor to the implicit one
The correct return type of getAnnotatedBounds is Array<AnnotatedType>.
This fact causes some problems now that kotlin-stdlib is targeting JDK
1.8:
* the compiler generates a bridge to the incorrect "override" that
attempts to cast an empty Array<Annotation> into the correct type,
which fails because those two types are unrelated;
* on Android, touching this method in any way (via reflection) on
any API version causes a ClassNotFoundException;
* tools that validate references in libraries when compiling for
Android complain about the bridge because they know the returned
type does not exist.
The easiest solution is to simply remove the override and leave
getAnnotatedBounds unimplemented, making it throw AbstractMethodError
when called. This is the behavior it previously had anyway, as
kotlin-stdlib targeting JDK 1.6 lacked a method with the correct
signature.
- Remove obsolete exclusion of core & stdlib modules, since they are now
compiled with JVM target 1.8, but leave `:core:descriptors` because of
an issue in Proguard.
- Remove binary-compatibility-validator and update test data instead.
- Replace some "contains" checks with equality for clarity.
- Remove modules from -Werror filter which no longer use the deprecated
compatibility mode.
This will finally make calls to KotlinCompilation.defaultSourceSet
or sourceSets.getByName(compilation.defaultSourceSetName) safe.
This will also enable removing the `kotlinSourceSetsIncludingDefault`
pitfall
^KT-52726 Verification Pending
This requires to make MutableObservableSet public as well, since
public implementations will inherit. The MutableObservableSet
therefore move its implementation to an internal
MutableObservableSetImpl
^KT-52726 Verification Pending
The effect of this changes are twofold:
1) Maintaining the 'allKotlinSourceSets' closure
makes access to this field cheaper
2) The observability of changes in the kotlinSourceSets
will allow implementing a faster compilationsBySourceSet util
KT-52726
This is used twofold:
1) The dependsOnClosure and withDependsOnClosure can be accessed
w/o any additional overhead
2) This can later be used to maintain caches for a
replacement of the slow compilationsBySourceSet util
KT-52726
Mads Ager