Skip to content

Version 1.5.0-RC #2675

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 56 commits into from
Apr 26, 2021
Merged

Version 1.5.0-RC #2675

merged 56 commits into from
Apr 26, 2021

Conversation

qwwdfsad
Copy link
Collaborator

No description provided.

dkhalanskyjb and others added 30 commits March 9, 2021 12:02
`kotlinx.coroutines.debug.internal.DebugProbesImpl.updateState`
sometimes parks in order to acquire a lock, which leads BlockHound
to detect an illegal blocking call. Now, blocking calls inside
`DebugProbesImpl` are permitted. Though allowing `updateState`
would suffice, the other users of the lock seem safe, too, and are
allowed even when it doesn't make much sense to call them from
coroutines.
They were deprecated long time ago and were removed in Gradle 7
* It slightly cuts down startup time
    * It simplifies the code in general
    * It do not serve its purpose, coroutines are already protected from StackOverflowError with nested event-loops where applicable
* Update Gradle to 4.8.3, add space-dev repository
* Update atomicfu and binary compatibility validator
* Merge onStartInternal and onStart to reduce the number of methods and make code a bit simpler
* Rework initParentJob
* Always establish a parent-child relationship when creating a subclass of AbstractCoroutine. That's our own internal class that we have full control of and it never has a chance to leak to the user-code (so cancellation handlers will be installed etc.).  Force implementors of AbstractCoroutine deliberately choose whether parent-child relationship should be established
 * As a consequence, get rid of parentContext in all our coroutine classes that are not ScopeCoroutine
* Remove some dead code
* Get rid of an additional parent field from ScopeCoroutine
 Leverage already presented information in our implementation, just expose it via an already present internal interface
* Update SharedFlow documentation
* Rework reusability control in cancellable continuation

    * Update initCancellability documentation and implementation to be aligned with current invariants
    * Make parentHandle non-volatile and ensure there are no races around it
    * Establish new reusability invariants
      - Reusable continuation can be used _only_ if it states is not REUSABLE_CLAIMED
      - If it is, spin-loop and wait for release
      - Now the parent is attached to reusable continuation only if it was suspended at least once. Otherwise, the state machine can return via fast-path and no one will be able to release intercepted continuation (-> detach from parent)
      - It implies that the parent is attached after trySuspend call and can be concurrently reused, this is where new invariant comes into play
    * Leverage the fact that it's non-atomic and do not check it for cancellation prematurely. It increases the performance of fast-path, but potentially affects rare cancellation cases

Fixes #2564
    * Introduce three-state ChannelResult, a domain-specific Result class counterpart
    * Introduce receiveCatching/onReceiveCatching, make it public
    * Get rid of receiveOrClosed/onReceiveOrClosed without migrations, it was @InternalCoroutinesApi anyway

Fixes #330
…cement for error-prone offer, poll and receiveOrNull

Fixes #974
* Fix wrong docs on Job.join and Job.cancelAndJoin

Fixes #2615
* Deprecation and migration of receiveOrNull and onReceiveOrNull.

    * Raise deprecation level for members, introduce deprecation for extensions
    * Explain rationale behind deprecation
    * Provide default implementation for deprecated members in Channel interface
    * Get rid of the internal implementation, leverage receiveCatching
    * Introduce new extensions for ChannelResult and use them as a replacement in our own operators

Fixes #1676
The implementation of Reactive Streams' Subscriber used for
`await*` operations was assuming that the publisher is correct.
Now, the implementation detects some instances of problematic
behavior for publishers and reports them.

Fixes #2079
…entical 'ensureActive' extension to reduce code duplication (#2467)
    * Remove all deprecated inline methods
    * Move the rest to the Deprecated.kt
    * Apply Deprecated.HIDDEN where possible, otherwise use internal + published API
    * Remove all deprecated inline methods
    * Promote ERROR to HIDDEN where applicable
    * Promote WARNING to ERROR where applicable
* Embrace new channel API

    * Introduce trySendBlocking and deprecate sendBlocking
    * Use it in callbackFlow example
    * Stabilize callbackFlow and channelFlow as they finally have error-safe API
    * Irrelevant: migrate from deprecated stdlib API to be able to build with Kotlin 1.5


Co-authored-by: Roman Elizarov <[email protected]>
elizarov and others added 26 commits April 13, 2021 15:00
* Otherwise Kotlin users with non-reactive background get confused by flow/stdlib inconsistency
    * Make it experimental to delay the final decision about the name

Fixes #2641
…ages along the codebase (#2644)

* Deprecate SendChannel.offer and replace its usages along the codebase
* Deprecate ReceiveChannel.poll and replace its usages along the codebase

Co-authored-by: Roman Elizarov <[email protected]>

Addresses #974
#2647)

* Mark BroadcastChannel, ConflatedBroadcastChannel and all related operators as obsolete API replaced with SharedFlow and StateFlow

* Remove operator fusion with deprecated broadcastIn in order to simplify further Flow maintenance
 * Migrate inline classes to value classes
 * Adjust debugger/state recovery for new codegen
 * Temporarily disable R8 tests
 * Update webpack for new K/JS
* Fixed `PublisherCoroutine`, `rxObservable`, and
  `Flow.toPublisher` ignoring cancellations.
* Fatal exceptions are not treated in a special manner by us
  anymore. Instead, we follow the requirement in the reactive
  streams specification that, in case some method of `Subscriber`
  throws, that subscriber MUST be considered canceled, and the
  exception MUST be reported in someplace other than `onError`.
* Fixed `trySend` sometimes throwing in `PublisherCoroutine` and
  `rxObservable`.
* When an exception happens inside a cancellation handler, we now
  consistently throw the original exception passed to the handler,
  with the new exception added as suppressed.
* Fixed `PublisherCoroutine` and `rxObservable` claiming that the
  channel is not closed for send for some time after `close()` has
  finished.
* Fixed publishers sometimes signalling `onComplete()` after
  cancellation even though their streams are not finite.

Fixes #2173
…hout it (#2637)

Also, remove the tutorial variant of the basic coroutine introduction as it essentially duplicates the content of the
basic coroutine introduction, albeit with "how to create a project" additional information, which does not seem to be appropriate in this section at all.

Fixes #2122

Co-authored-by: Vsevolod Tolstopyatov <[email protected]>
Co-authored-by: Andrey Polyakov <[email protected]>
…deadlocks when the downstream throws, but other flow has no elements in it (#2659)

Fixes KT-46013
* Clarify docs about the restriction on MutableSharedFlow function's onBufferOverflow parameter.

* Clarify docs about MutableSharedFlow function without subscribers but with onBufferOverflow

Co-authored-by: Zach Klippenstein <[email protected]>
…nd Maybe (#2628)

* Deprecated `awaitSingleOr*` on arbitrary Publishers
* Added specialized `awaitSingle` and `awaitSingleOrNull` methods on
  `Maybe<T>` and `Mono<T>`
* Deprecated `Maybe<T>.await()` in favor of `Maybe<T>.awaitSingleOrNull()`
* Added specializations of most of the `await*` methods for `Mono<T>` and
  deprecated them, as the only useful methods on `Mono<T>` are
  `awaitSingle` and `awaitSingleOrNull`
* Reworded some documentation for `await*` methods

Fixes #2591
Fixes #1587
…routines-core (#2632)

* It fixes IDEA issue that was introduced in coroutines 1.4.3 where we switched to Kotlin 1.4.30 and stopped producing root artifact with JVM classes
    * It simplifies manual -javaagent specification for end-users who shouldn't even be aware of kotlinx-coroutines-core-jvm.jar

Fixes #2619
* Establish clear contract on ChannelResult.isClosed
* This method provides a **clear** migration from correct 'offer' usages to 'trySend'
…#2638)


* On JVM it uses java.util.concurrent.CancellationException, same as stdlib declaration
* Fully backwards compatible for JVM, Native-friendly for Obj-C interop
* Remove dev repositories and Bintray usages where applicable
* Update our frontend example
* Update lincheck
* Temporary ignore MutexLincheckTest.modelCheckingTest
Reworked the comments, added new tests.
Fixed a bug where `Maybe.collect()` would hang on success.
# Conflicts:
#	README.md
#	gradle.properties
* Update Kotlin to 1.5.0
* Update atomicfu to 0.16.1

Co-authored-by: SokolovaMaria <[email protected]>
@qwwdfsad qwwdfsad requested a review from elizarov April 26, 2021 16:21
@qwwdfsad qwwdfsad merged commit 65e1b84 into master Apr 26, 2021
@qwwdfsad qwwdfsad deleted the version-1.5.0-rc branch July 12, 2021 09:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants