Receiver disconnection relies on the incorrect assumption that
`head.index != tail.index` implies that the channel is initialized (i.e
`head.block` and `tail.block` point to allocated blocks). However, it
can happen that `head.index != tail.index` and `head.block == null` at
the same time which leads to a segfault when a channel is dropped in
that state.
This can happen because initialization is performed in two steps. First,
the tail block is allocated and the `tail.block` is set. If that is
successful `head.block` is set to the same pointer. Importantly,
initialization is skipped if `tail.block` is not null.
Therefore we can have the following situation:
1. Thread A starts to send the first value of the channel, observes that
`tail.block` is null and begins initialization. It sets `tail.block`
to point to a newly allocated block and then gets preempted.
`head.block` is still null at this point.
2. Thread B starts to send the second value of the channel, observes
that `tail.block` *is not* null and proceeds with writing its value
in the allocated tail block and sets `tail.index` to 1.
3. Thread B drops the receiver of the channel which observes that
`head.index != tail.index` (0 and 1 respectively), therefore there
must be messages to drop. It starts traversing the linked list from
`head.block` which is still a null pointer, leading to a segfault.
This PR fixes this problem by waiting for initialization to complete
when `head.index != tail.index` and the `head.block` is still null. A
similar check exists in `start_recv` for similar reasons.
Fixes#110001
Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
Switched provisional evaluation cache map to FxIndexMap, and replaced map.drain_filter with map.retain
Switching ProvisionalEvaluationCache's map field from FxHashMap to FxIndexMap was previously blocked because doing so caused performance regressions that could be mitigated by the stabilization of drain_filter for FxIndexMap (#104212). However, the only use of drain_filter can be replaced with a retain, so I made the modification and put in a PR to see if this causes a performance regression as well.
This PR is part of a broader effort (#84447) of removing iteration through FxHashMaps, as the iteration order is unstable and can cause issues in incremental compilation.
This may be potentially useful for
- avoiding uses of `hir::ItemKind::Use`
- preserving documentation comments on all reexports
- preserving and checking stability/deprecation info on reexports
- all kinds of diagnostics
Temporarily remove myself from reviewers list
I'm going to be unable to review for the next few weeks, so I'm removing myself from the review queue. Once I'm back and able to review again, I'll add myself back to the list.
r? ``@wesleywiser``
rustdoc: clean up JS
* Stop checking `func` in `onEach`. It's always hard-coded right at the call site, so there's no point.
* Use the ternary operator in a few spots where it makes sense.
* No point in making `onEach` store `arr.length` in a variable if it's only used once anyway.
I'm going to be unable to review for the next few weeks, so I'm
removing myself from the review queue. Once I'm back and able to review
again, I'll add myself back to the list.
This is needed for when the shell scripts bypass python altogether and run the downloaded
bootstrap directly. Changes are mainly provided from @jyn514, I just fixed the review notes.
Signed-off-by: ozkanonur <work@onurozkan.dev>
More descriptive error when qself path doesnt have a trait on the RHS of `as`
`<Ty as Enum>::Assoc` should report that `Enum` is a trait. Main question is whether to eagerly report the error, or raise it with `return Err(..)` -- i'll note that in an inline comment though.
cc `@GuillaumeGomez` who said this came up at a Paris Rust meetup.
r? `@petrochenkov`
Inline try_from and try_into
To avoid link time dependency between core and compiler-builtins, when using opt-level that implicitly enables -Zshare-generics.
While compiler-builtins should be compiled with -Zshare-generics disabled, the -Zbuild-std does not ensure this at the moment.
r? `@bjorn3`
(Small) Fix broken links for Rust merge
rust-lang/rust#110003's CI is [currently broken](https://github.com/rust-lang/rust/actions/runs/4628510374/jobs/8187672234?pr=110003) because of broken links. This PR fixes that.
It was tested against `lintcheck` and found another broken link in `usage.md` (apart from CI's broken links)
changelog:Fix broken links in the book
Sorry for putting more work on you, but you're the one doing the Rust PR
r? `@flip1995`
