This is an addition to c1ab08c8ce where KT-26582 was fixed. The test
testClassLiteralArguments in JvmRuntimeDescriptorLoaderTestGenerated
failed before this change but went unnoticed because it wasn't run on CI
(see the previous commit)
This is a squashed and rebased commit of https://github.com/JetBrains/kotlin/pull/1945
- add idl2k to default gradle build lifecycle
- removemaven build completely
- invert maven's `idl2k.deploy.skip` to `idl2k.deply` in gradle
(false by default)
- antlr upgrade from 4.5.3 to 4.7.1 - I'd have to slightly modify WebIDL.g4 definition though -
and updated copyright accordingly - my updates were based on
https://raw.githubusercontent.com/antlr/grammars-v4/master/webidl/WebIDL.g4
- I've checked all generated output to make sure it is identical to
what we hade before dependency update.
- Package idl2k according to our souce code guidelines
'v.anew(Type.geType(...))' worked accidentally because
1. By default, ASM 6 creates METHOD Type for 'Type.geType(...)' invocation
2. It didn't fail because this type was used only in 'anew' invocation that
calls 'internalName' only
3. ASM 7 changes default behavior to throw Exception
ASM 7 changes default behavior for 'getTypeInternal' (was 'getType') method.
Now it's throwing exception instead of create 'METHOD' Type.
Old behavior was equals to 'Type.getMethodType("<invalid>")'
#KT-27833 Fixed
The existing disambiguation rule for the Usage attribute lead to
runtime variants being resolved even for compile-scoped input
configurations, because Gradle runs disambiguation rules even if the
consumer value is present in the candidates list.
For example, an `app` project's `jvmCompileClasspath` configuration
would get its `project('lib')` dependency resolved to the
`jvmLibRuntimeElements` instead of `jvmLibApiElements`.
Fix this by:
1) running the part of the disambiguation rule only with Gradle 4.1+, so
as to use the consumer value for proper disambiguation;
2) choosing the JAVA_API usage when the consumer is JAVA_API or
KOTLIN_API, and choosing one of the JAVA_RUNTIME usages if the
consumer is either KOTLIN_RUNTIME, one of the JAVA_RUNTIME usages, or
does not specify its usage.
Issue #KT-27849 Fixed