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
ASM has logic that splits exception tables in MethodWriter.computeAllFrames:
// Loop over all the basic blocks and visit the stack map frames that must be stored in the
// StackMapTable attribute. Also replace unreachable code with NOP* ATHROW, and remove it from
// exception handler ranges.
...
firstHandler = Handler.removeRange(firstHandler, basicBlock, nextBasicBlock);
...
https://gitlab.ow2.org/asm/asm/issues/317867
#KT-28546 Fixed
Proper SMAP support for default values from expect declarations is required.
Default value in expect declaration could has line number that
exceed line count in actual file that causes an error
#KT-23739 Fixed
#KT-29174 Open
In 1.3.0 there was introduced KT-28061 bug, which caused some of the
NO_RETURN_IN_FUNCTION_WITH_BLOCK_BODY diagnostics to be lost (turning
"red" code into "green")
500dc11514 fixes the bug and returns
lost diagnostics back. This commit adds additional information for some
of the cases where diagnostics were list and then brought back (for the
user sanity).
The heuristic used for detecting cases which need additional information
is simple: if function has return in in-place called lambda, and
NO_RETURN_IN_FUNCTION_WITH_BLOCK_BODY should be reported, then we
enhance it with additional information.
^KT-28061 Fixed
Main test data (testName.txt) a not totally valid cause of IDEA-205039.
Javac test data (testName.javac.txt) a not valid
cause of type annotations support absence.
Runtime tests are disabled cause reflection support absence.
Introduce lowering phase that turns !!exp -> exp for the boolean
'not' builtin. This makes sure that code such as
```
if (!!!!!booleanValue) {
doStuff()
}
```
generates only one branch.
Original problem is that lowered ir closures doesn't meet inliner expectations
about captured variable position in inlining method.
E.g.: Call 'foo(valueParam) { capturedParam }' to
inline function 'foo' with declaration
inline fun foo(valueParam: Foo, inlineParamWithCaptured: Bar.() ->) ....
is reorganized through inlining to equivalent call foo(valueParam, capturedParam1, cp2 ...).
But lowered closure for lambda parameter has totally different parameters order:
fun loweredLambda$x(extensionReceiver, captured1, cp2..., valueParam1, vp2...)
So before inlining lowered closure should be transformed to
fun loweredLambda$x(extensionReceiver, valueParam1, vp2..., captured1, cp2..)
#KT-28547 Fixed
In general case parameter type could differ from actual default lambda type.
E.g.: fun inlineFun(s: (Child) -> Base = { a: Base -> a as Child}),
where type of default lambda is '(Base) -> Child'.
In such case we should find somehow actual invoke method in bytecode knowing
only name, number of parameters and that's actual invoke is non-synthetic
regardless of bridge one.
#KT-21946 Fixed
Ilmir Usmanov