resolve: Preserve reexport chains in `ModChild`ren
This may be potentially useful for
- avoiding uses of `hir::ItemKind::Use` (which usually lead to correctness issues)
- preserving documentation comments on all reexports, including those from other crates
- preserving and checking stability/deprecation info on reexports
- all kinds of diagnostics
The second commit then migrates some hacky logic from rustdoc to `module_reexports` to make it simpler and more correct.
Ideally rustdoc should use `module_reexports` immediately at the top level, so `hir::ItemKind::Use`s are never used.
The second commit also fixes issues with https://github.com/rust-lang/rust/pull/109330 and therefore
Fixes https://github.com/rust-lang/rust/issues/109631
Fixes https://github.com/rust-lang/rust/issues/109614
Fixes https://github.com/rust-lang/rust/issues/109424
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>
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.
Fix buffer overrun in bootstrap and (test-only) symlink_junction
I don't think these can be hit in practice, due to their inputs being valid paths. It's also not security-sensitive code, but just... bad vibes.
I think this is still not really the right way to do this (in terms of path correctness), but is no worse than it was.
r? `@ChrisDenton`
Original `var_os` description said that it _may_ return an error if the value contains `=` or NUL. Let's make no promises on the `None` return value in these situation either, keep it in the [potential mood](https://en.wikipedia.org/wiki/Grammatical_mood#Potential).
Update compiler-builtins to 0.1.91 to bring in msp430 shift primitive…
… fixes.
This fixes unsoundness on MSP430 where `compiler-builtins` and LLVM didn't agree on the width of the shift amount argument of the shifting primitives (4 bytes vs 2 bytes). See https://github.com/rust-lang/compiler-builtins/pull/522 for more details.
binary_heap: Optimize Extend implementation.
This PR makes the `Extend` implementation for `BinaryHeap` no longer rely on specialization, so that it always use the bulk rebuild optimization that was previously only available for the `Vec` specialization.
Improve grammar of Iterator.partition_in_place
This is my first PR against Rust, please let me know if there's anything I should be providing here! I didn't find any instructions specific to documentation grammar in the [std-dev guide](https://std-dev-guide.rust-lang.org/documentation/summary.html).
bors
Richard Schneeman
Lukas Markeffsky
Patrik Kormosi
Yuki Okushi
Michael Goulet
Petros Angelatos
Vadim Petrochenkov
Deadbeef
Scott McMurray
Sergei Belokon
Jörn Bethune
Maybe Waffle
zhaixiaojuan
Tomasz Miąsko
Matthias Krüger
Jonas Platte
管唯宇
Konrad Borowski
Thom Chiovoloni
clubby789
The 8472
fleetingbytes
Sergey Kaunov
Nilstrieb