It would be more consistently to prohibit the behavior from the unmuted
test (see KT-52428), but it was decided to postpone the breaking change.
Unfortunately, it didn't work to make a test where for computing
star projections we would need to substitute other type parameters
because effectively, it's not allowed to have SAM conversion when
star projections/wildcard is based on a type parameter which bounds
use other type parameters.
^KT-53552 In progress
ProcessCanceledException indicates that the compilation process was
terminated by user. This kind of exception should not be wrapped anyhow
in order to be handled on toplevel in CLICompiler.
#KT-38483 Fixed
... and the corresponding type parameter has a non-trivial (i.e.
non-`Any?`) upper bound.
The best solution here would be to get rid of
`removeExternalProjections` completely, and just use the type of the
argument at the call site, but see KT-52428.
#KT-51868 Fixed
1. Extension functions declared in data classes are generated earlier by `generateMembersDeclaredInClassBody`
2. Extension functions fake override from parent class are generated earlier by `generateFakeOverrideMemberDeclarations`
So it is safe to filter out extension functions inside `generateAdditionalMembersForDataClass`
#KT-49715
#KT-51798
This new filters will also take care of filtering out descriptors
that are provided by 'regular' dependencies instead of 'dependsOn'
dependencies.
^KT-50120
KT-50120 Partially solved for functions.
ClassConstructors seem to be deserialized with 'isExpect=false'
which will still lead to wrong 'expect/actual matching'
Also, do not try to use invokedynamic on SAM calls with intersection
types, because intersection type is not allowed as an immediate type
projection of a supertype, and constructing a fake override in
LambdaMetafactoryArgumentsBuilder led to an exception. This fixes the
problem which was worked around earlier in e6c089ef, effectively
reverting that commit.
The main motivation for this change is that LambdaMetafactory also
doesn't generate generic signature for SAM wrapper classes at runtime.
Since these classes are synthetic, nobody should rely on the fact that
they have generic supertypes, which was observable only via Java
reflection.
#KT-46149 Fixed
#KT-46238 Fixed
- Do not wrap exceptions resulting from generating error expressions
multiple times, as that could lead to stack traces where the identical
code is wrapped many times and is printed in the exception message on
each step, which was difficult to read
- Add element location (file name, line number & position) to the
message, similarly to exceptions from codegen, when catching and
rethrowing exceptions at the top level
The changes introduced 471134d31e are only needed
for the case of HMPP project while for other cases it might break the behavior
a bit like in KT-34027
See org.jetbrains.kotlin.resolve.calls.results.OverloadingConflictResolver#filterOutEquivalentCalls
Before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration
But straightforward fixing of this exact call-site (using original descriptors)
doesn't help: behavior might change in a very subtle way (see org.jetbrains.kotlin.spec.checkers.DiagnosticsTestSpecGenerated.NotLinked.Dfa.Pos#test72)
So, the main idea is changing the contract for areCallableDescriptorsEquivalent
only when project is HMPP one.
^KT-34027 In Progress
Move logic regarding expect classes to the only relevant call site at
PackageCodegenImpl, and return the list of members to remove code
duplication at remaining call sites
Make a separate subclass for DescriptorBasedFunctionHandle
to allow customize the behavior without complex abstract concepts
like `areDeclarationAndDefinitionSame`
- Give it more clear name mayBeUsedAsSuperImplementation
because defining if it can be used as super-implementation
this is what it used for
- The meaning is negated, so it's needed to negate its usages and impls
- Also, reuse it in findSuperImplementationForStubDelegation
It's difficult to fix KT-22818 until the IR comes along, so we're
providing a workaround where one can disable the
ACTUAL_FUNCTION_WITH_DEFAULT_ARGUMENTS error and provide default values
in the actual function, to avoid exception from the backend.
#KT-22818
This lead to an exception being thrown frequently
Proper fix would be to prevent binding context from being corrupted
Known cases are hard to debug/reproduce
#EA-101081 Fixed
Sergej Jaskiewicz