| Age | Commit message (Collapse) | Author |
|---|
|
|
|
https://play.kotlinlang.org/ of the example that's being changed
here is currently unreliable: the last line is occasionally `null`.
By increasing all time intervals twofold, we reduce the impact of
the CPU scheduling in the constrained environment. With this
change, the results are consistent across dozens of runs:
<https://pl.kotl.in/uCa-60j43>
Originally reported by `@PetrakovichVictoria`
|
|
See <https://github.com/reactor/reactor-core/issues/3794>
|
|
|
|
code mentioned (#4100)
|
|
|
|
coroutine-context-and-dispatchers.md (#4081)
|
|
|
|
At the end of the book, they multiply 6 * 7 :)
|
|
calls (#4080)
|
|
|
|
Fixes #4071
|
|
|
|
Calling a function containing atomic operations from a different file results in the failure of Native incremental compilation.
Made BufferedChannel#sendImpl function private.
This is a WA for KT-65554
|
|
Replace the specific place where ARFU gets misexecuted by a specific Android toolchain
Fixes #3820
|
|
|
|
* Reduce the number of time spent on lincheck tests in stress mode to be aligned with our stress test multiplier (25) instead of x100
* Reduce the number of iterations and time spent in [nowadays] less relevant tests
Rationale: these contribute to more than an hour of stress tests time spent
|
|
Workaround for KT-64075
Also, thoroughly document the contracts imposed on the callbacks provided to `invokeOnCompletion` and `invokeOnCancellation`.
|
|
state (#4052)
A potential bug is fixed, where `nextInt` would always return zero due to incorrect initialization of rngState with zero.
This could happen during the creation of a worker with thread id = `1595972770` (JDK >=8), or unpredictable if fallback thread-local random is used (android SDK <34 or JDK <7), approximate probability is 2.4E-10
Also, this slightly optimizes the performance of coroutines initialization. During the creation of `CoroutineScheduler.Worker`, we need to initialize its embedded random number generator.
To avoid additional class-loading costs (#4051), `rngState` is now directly initialized from the current nanoTime (that is used as seed).
Fixes #4051
Co-authored-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
|
|
|
|
Merge `develop` with `master`
|
|
|
|
Adjust tests and the documentation
Rationale: this option implies significant and non-trivial overhead, yet its utility is unclear (e.g., we got a multitude of signals that this option brings no use and none that it's useful even when asked explicitly)
Fixes #3783
|
|
Small documentation fixes
|
|
Fixes #3280
|
|
Seems like a lot of the information was outdated.
Fixes #3725
|
|
What does it even mean?
|
|
Emphasize the fact that the function fails to resume *even if it
already completed* but wasn't dispatched yet. Before the change,
when translating the documentation to Chinese, there could be a
confusion as to what "it will not resume successfully" means.
Fixes #3888
|
|
Fixes two issues:
* It is surprising for some users that the same exception can be
thrown several times. Clarified this point explicitly.
* Due to #3658, `await` can throw `CancellationException` in
several cases: when the `await` call is cancelled, or when the
`Deferred` is cancelled. This is clarified with an example of
how to handle this.
Fixes #3937
|
|
A user raised a concern that the internal coroutines machinery may
break if `runBlocking` is used somewhere deeply in the call stack.
Calling `runBlocking` from a `suspend` functions can lead to
deadlocks naturally due to blocking the thread, or to surprising
event ordering, but nothing is expected to break.
This commit clarifies the exact danger of calling `runBlocking`
from `suspend` functions.
|
|
Before this change, it could happen that some size-limiting
operators upstream swallowed the requests to limit the flow size
emitted by the operators downstream.
This could cause `onCompletion` calls between these operators to
incorrectly report that the flow was not in fact limited by the
downstream operators.
Additionally, in the presence of additional size-limiting operators
in the chain, `first` and `single` and their variants could exhibit
incorrect behavior where emitting a value from `onCompletion` would
overwrite their output.
Fixes #4035
|
|
With the newer Kotlin Gradle plugin, we got this error:
'var compilations: NamedDomainObjectContainer<KotlinJvmCompilation>' can't be called in this context by implicit receiver. Use the explicit one if necessary
With this change, we use an explicit receiver, as instructed.
|
|
* Replace `*` with `-` everywhere in KDoc
git grep -l '\* \+\* ' | xargs -n1 sed -i 's/^\([ \t]*\* \+\)\* /\1- /'
* Fix several false positives of the regex replacement
|
|
to a separate module (#4011)
|
|
Move the test facilities lying around `kotlinx-coroutines-core`
and their reimplementation in `kotlinx-coroutines-test` into
a separate module, on which the other modules now depend.
This allows us to have internal testing facilities in common
code.
After the migration, the test facilities were also refactored
a bit:
* Removed many SUPPRESS directives,
* Extracted a lot of code to multiplatform,
* Fixed a couple of bugs in TestBase,
* etc.
Finally, the tests were cleaned up automatically a bit, most
notably by replacing `assertTrue(a is T)` with `assertIs`.
|
|
* Remove the workarounds for IDEA import from gradle.kts
Without the workarounds, everything still seems to be working
fine, even after invalidating the caches.
* Clarify the opt-ins.
Unify the handling of all opt-ins in the project, and also
add opt-ins for Native that would be widespread otherwise.
Unfortunately, even after that, the IDE still complains about
not having the right opt-in in
kotlinx-coroutines-test/common/test/Helpers.kt.
* Extract the logic of grouping several source sets into a
single shared one.
* Update the kotlinx-coroutines-core build script:
- Utilize the multiplatform hierarchy to avoid defining
extra source sets.
- Reorder the code for readability.
* Fix the IDE failing to find `actual` implementations for jvmCore
by making sure `jvmCoreMain` is only defined when the IDE is not
active. Without a dependency from jvmCoreMain to jvmMain,
`expect` declarations in the IDE complained that they couldn't
find `actual` in the `jvmCore` source-set. For example, this
could be seen in
kotlinx-coroutines-core/common/src/internal/Concurrent.common.kt.
* Fix passing the stressTest system property to tests
Broken in #3966
* kotlinOptions -> compilerOptions
|
|
|
|
This commit intentionally won't build. It's introduced to preserve
history, so that Git tooling understands the line of succession
between the old and new files.
|
|
* Re-structure DebugProbes documentation and mention classloading
Fixes #4000
Co-authored-by: Dmitry Khalanskiy <52952525+dkhalanskyjb@users.noreply.github.com>
|
|
* Remove copyright notices from individual files;
* Update the NOTICE file to include the year of initial publication
and the year of the latest change;
* Remove the IDEA template for adding notices to every file.
This is in accordance with
https://youtrack.jetbrains.com/articles/MKT-A-236159528/, using the
clarifications from
https://youtrack.jetbrains.com/issue/LegalCZ-6871
|
|
Fix "Type mismatch: inferred type is String? but String was expected"
|
|
|
|
Notably, an artificial entry point
Fixes #4009
|
|
|
|
Update the development branch after a release
|
|
|
|
|
|
As there were no native targets in smokeTest, the problem with the missing atomicfu dependency (KT-64111) was not addressed in time. The bug was revealed after release of kotlinx.coroutines with atomicfu-gradle-plugin 0.23.1. Coroutines enabled Native IR transformation, and for this mode, atomicfu-gradle-plugin only provided compile dependency to atomicfu, though implementation dependency was still necessary.
This commit adds the smoke test for Native and temporarily adds an explicit dependency on atomicfu for Native artifacts.
Fixes #3968
Co-authored-by: Maria Sokolova <maria.sokolova@jetbrains.com>
|
|
Fixes #3993
|
|
|
