`Expected failure flag` was wrongly included in list of test checks.
However, the nature of checks and this flag is different:
- any test check can pronounce the test as failed.
- `Expected failure flag` must invert the accumulated effect of all checks.
Having flag as an additional check cannot catch usecase,
when test is failed only by producing wrong stdout.
This commit extracts this flag out of check list.
^KT-59288
- This helps to track down disposables which are never disposed, and
reduces confusion when printing disposables in general (the names will
now be meaningful, instead of endless lists of "newDisposable" and
"TestDisposable").
^KT-64099
- The disposable passed to `getOrCreateApplicationEnvironment` should
not actually be the application environment's disposable, which is
created inside the function. Instead, it should be the project's
disposable, which is used to track how many projects still rely on the
shared application environment.
- This issue wasn't apparent before because there is no visible
consequence when an application isn't disposed after all projects have
been disposed (during tests). However, the solution for KT-63650
relies on application environments being disposed after all projects
are disposed, so that a new application environment with a different
configuration can be created. (Only one shared application environment
may be active at the same time.)
^KT-63650
- Make the messages that are reported by KLIB resolver prettier
- For those messages that affect the resolve process add
prefix "KLIB resolver: "
- Don't log warning on duplicated libraries on the classpath. This
does not make any sense.
^KT-63573
The reason of this change is to make messages (especially warnings)
that are reported by the KLIB resolver become visible to the end user.
This can be achieved to forwarding such messages to the appropriate
compiler's components such as
`org.jetbrains.kotlin.cli.common.messages.MessageCollector` and
`org.jetbrains.kotlin.ir.util.IrMessageLogger`.
Also: The default `DummyLogger` should be used as minimal as possible.
Because it just forwards messages to the standard output (console)
where they can remain unattended. When the compiler is executed
from the Gradle plugin such messages appear only in DEBUG Gradle's log.
^KT-63573
```
interface A {
fun <T> foo(): T
}
class B(val a: A) : A by A {
generated fun <T'> foo(): T' {
return a.foo() // <------
}
}
```
There was a problem that type of generated delegated call used
an unsubstituted type of the original delegated declaration, which led
to a situation when (see example) type of call `a.foo()` was not `T'`
but `T`, which led to incorrect IR and further exceptions on backend
^KT-64257 Fixed
^KT-64284 Obsolete
Second phase of removing LLVM coverage. This had to wait until after the
bootstrap advance.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-838
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
After a generation of fake overrides some code may still to refer old
symbols from declaration storage (like computation of overridden
symbols for lazy functions), so we need to remap those symbols using
information from IR f/o generator
When running `codegen/box` tests, Kotlin/Native test infrastructure
divides test data files into groups and compiles each group in a single
compilation.
As a result, compilation problem with one test can cause an unrelated
nearby test to fail.
To make this less frustrating, this commit adjusts test failure reports:
it moves the test grouping mention from the bottom of a report to the
top and makes the wording more clear and actionable.
Native bitcode files were moved out of the stdlib to the default
location of bitcode files in the dist.
Now it is possible to build stdlib separately and once as a klib
without bitcode files inside.
Objective-C has a special type, "instancetype". Generally, it is a type
that matches the method receiver type. So, if `Foo.foo` method returns
`instancetype`, then `Foo.foo()` would be of type `Foo`, while
`Bar.foo()` would be of type `Bar` (where `Bar` is a subclass of `Foo`).
Surprisingly, `instancetype` can be used not only as a return type, but
also somewhere inside a return type. cinterop wasn't ready for this.
This commit expands implementation of `instancetype` in cinterop to
cover more cases.
^KT-59597 Fixed
Previously when unsigned arrays were passed as vararg in a named form the necessary spread element wasn't generated, which resulted in a compilation error.
^KT-63514 fixed
Kirill Rakhman