Use only getDeclaredMethod/getDeclaredConstructor instead. The reason is
that getMethod/getConstructor only finds public-API (public or protected
on JVM) declarations, and to determine if a declaration is public-API in
the class file we used isPublicInBytecode, which was trying to load
annotations on the declaration to see if it was InlineOnly, and that
required lots of time-consuming actions and worsened the stack trace (as
can be seen e.g. in KT-27878). In fact, the implementation of
Class.getMethod is not supposed to do anything complicated except
loading annotations from each superclass and superinterface of the given
class. Doing it in our codebase simplifies implementation and probably
improves performance
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
Alexey Tsvetkov