Simplify MultifileClassPartCodegen, remove related tests and change some
tests to use const val instead of val because backing fields for const
properties are stored in the facade, not parts
#KT-23701 Fixed
In JDK 9, Class.simpleName changed behavior for local/anonymous Kotlin
classes (see KT-23072), this is why we now check for both variants of
the name in tests. Also, the format of annotation arguments changed a
little, where float parameters no longer have the trailing "f", and
class literals are rendered with ".class" at the end
Now both of those classes implements one interface with `TypeProjection`
property. That allows old captured type approximator use new captured types.
That change fixes tests related to diagnostics:
- SETTER_PROJECTED_OUT
- DEBUG_INFO_UNRESOLVED_WITH_TARGET
- UNRESOLVED_REFERENCE_WRONG_RECEIVER
Also `typeProjection` property renamed to `projection` according to naming in NI.
Simplify ifs when branches have condition true/false.
Simplify blocks containing only a variable declaration
and a variable get of the same variable. Simplify to
just the condition.
Do not introduce temporary variables for constants for
null checks. Constants have no side-effects and can be
reloaded freely instead of going through a local.
This simplifies code such as "42.toLong()!!" so that the
resulting code has no branches and uses no locals. The
simplifications happen as follows:
```
block
temp = 42.toLong()
when
(temp == null) throw NPE
(true) load temp
---> null test simplification
block
temp = 42.toLong()
when
(false) throw NPE
(true) load temp
---> when simplification
block
temp = 42.toLong()
load temp
---> block simplification
42.toLong()
```
* if enum class has abstract members, then it is ABSTRACT
* otherwise, if enum class has entries with members, then it is OPEN
* otherwise, it is FINAL.
In case of the same class defined in different modules they contain
different descriptors instances in their scope that might lead
to failing assertion in findConcreteSuperDeclaration
because there are overridden from different modules
It might happen even in the compiler because of different built-in modules
defined for sources-module and for dependencies' one
^KT-29320 Fixed
In super class constructor arguments, 'this' can be resolved
as a reference to a companion object of a superclass.
This breaks an assumption in psi2ir that 'this' can only refer to some
receiver from the current scope.
If 'this' refers to an 'object' (including 'companion obejct'),
and we are not inside the corresponding class scope,
then 'this' represents a reference to a singleton instance "by name"
(represented as IrGetObjectValue).
Introduce lowering to remove null checks for primitive type
expressions and replace them with true/false. Side-effects
are preserved.
Generate ifnull/ifnonnull instructions for null checks instead
of materializing a null literal for an equality check.
The case for KT-7237 belongs to /NoGTInTypeArguments test
It was fixed implicitly: before it recovery was working but the name for
the next parameter was attached to type argument list.
After that change, parameter without name gets parsed correctly (with an
error of course)
^KT-13731 Fixed
^KT-7237 Fixed
Consider following expression: 'call() is Foo'. Suppose that we know
something about the 'call()', e.g. 'returns(foo) -> <condition>'
Previously, we've tried to re-use knowledge about 'call()', constructing
some smart clause, like 'returns(true) -> foo is Foo && <condition>'.
The conceptual error here is that *we can't* argue that <condition>
holds. Imagine that 'call()' actually has unspecified 'returns(foo2) ->
<!condition>', and 'foo2 is Foo' also holds. Then we would get
'returns(true) -> foo2 is Foo && <condition>' <=> 'returns(true) ->
<condition>' for the whole call, which is not correct.
More concrete example would be something like:
'if (!x.isNullOrEmpty() is Boolean)'
^KT-27241 Fixed
In case we extending some Map specialization with non-trivial type arguments,
e.g. Map<String, String> from Kotlin point-of-view it has
"remove(String, String)" signature while in Java it's "remove(Object, Object)".
So, we generate an override "remove(String, String)" in first Kotlin class of the hierarchy,
which body delegates to "super.remove(Object, Object)"
Also, we generate a final override for "remove(Object, Object)" to allow
for Java inheritors choose only the version with String while overriding.
The main idea of the fix is to make mayBeUsedAsSuperImplementation
return true in case of PlatformDependent annotations.
Otherwise, we weren't able to choose the impl from the java.util.Map
as a delegate in our bridge.
Another part of the fix is overriding `isDeclaration`:
it was necessary because otherwise bridge-generation algorithm
was assuming that there's already an actual declaration
in the first sub-class (TestMap) in the test and we need to
delegate to the latter instead of the method from the interface
^KT-26069 Fixed
Functor is an imperative representation of function's contract (contrary
to ContractDescription, which is a declarative one). ContractDescription
is convenient when we deal with sources of contracts declarations
(binaries, source), while Functors are convenient for analyzing code
with contracts.
It means that we have to convert ContractDescription into Functor when
we start working with contracts. This computation isn't trivial, and
Functor and ContractDescription are in 1-1 correspondence, so we would
like to cache Functor for each ContractDescription somewhere.
We used to do this in binding trace, in slice FUNCTOR.
Now, it turns out that this approach causes "Rewrite at slice"
exception, see KT-28847. We won't go into details of why that happens
here, you can see the issue comments for details (but be prepared for the
very long and nitty-gritty story)
This commit removes the problematic slice and introduces another
approach, where Functor is attached to the ContractDescription, computed
lazily and cached here.
^KT-28847 Fixed
Svyatoslav Kuzmich