The `compileOnly` configuration of a source set was not included in the
granular dependency transformation, which led to the dependencies from
the configuration being excluded as unrequested during dependency
processing.
Fix this by properly including the compileOnly scope into the
dependencies transformation.
Issue #KT-36469 Fixed
In some setups, the friendArtifacts that we had in addition to direct
associate compilations' output classes were insufficient. For example:
1. When an Android module's tests depend on another module which
transitively depends on the module containing tests: then the AGP
API doesn't tell us that there are artifacts from the tested
variant, but instead there's just the module's artifact.
2. Similar case but without Android, and if the classes are read from
the module's artifact rather than the production output classes dir,
then they are definitely not on the friend paths (which include the
production classes dirs and not the the production artifact).
In both cases, the friendArtifacts mechanism allows us to add those
potential sources of the friend classes to the friend paths.
Issue #KT-35942 Fixed
- Now inspection does not rely on synthetic descriptors at all, instead
it uses `SamConversionOracle` and `SamConversionResolver` to detect
if the argument type support SAM conversion
- This transparently considers all language features like
`SAM conversions for kotlin functions`, `Functional interfaces` etc.
- In case of multiple SAM arguments, part of them can be converted only
when `SAM conversion per argument` is enabled
- Fix inspection and nj2k tests that were failing because of better
working inspection
- Rewrite automatically fixes multiple bugs that were present
- ^KT-36367 ^KT-36368 ^KT-36296 ^KT-36395 Fixed
Previoisly, there were two places where mapping had happened:
- toConeKotlinTypeWithNullability
- enhancePossiblyFlexible
The first one was used for supertypes and bounds and the second one
was used for other signature parts
The main idea is to perform type mapping once to a flexible type,
and then use it as it's needed (it's lower bound, or for the further ehnancement)
Also, this commit fixes flexibility for type arguments, see the tests
`invoke` in suspend lambdas overrides FunctionN.invoke, so the
refactored BridgeLowering already generates correct bridges there.
All the hack does is break overrides of interface suspend methods.
We always set the $assertionsDisabled field based on the top-level
enclosing class. This means that for anonymous objects we have to
rewrite the call to Class.desiredAssertionStatus.
While we have an overload resolution algorithm working for O(n^2),
call resolution for the single particular call may work more then just
a second.
Thus, we need to call ProgressManager.checkCanceled() with more granularity
^KT-35135 Fixed
See 62a55b7b00
Previously, it was working for O(n^2)
Now, we first group it by jvm descriptor,
then for each groups of size g_i finding the most specific for O(g_i^2)
It should help for the cases when we have a lot of overloads with
different JVM descriptors (modulo return type)
NB: Having the same JVM descriptors is rather rare, because
in Java one cannot generate such a class.
Looks like it's only possible for Scala or some other JVM languages (KT-17560)
It should help a lot for KT-35135
Mikhail Glukhikh