rustdoc: Fix doctest heuristic for main fn wrapping
Fixes#140412 which regressed in #140220 that I reviewed. As mentioned in https://github.com/rust-lang/rust/pull/140220#issuecomment-2837061779, at the time I didn't have the time to re-review its latest changes and should've therefore invalided my previous "r=me" and blocked the PR on another review given the fragile nature of the doctest impl. This didn't happen which is my fault.
Contains some other small changes. Diff best reviewed modulo whitespace.
r? ``@GuillaumeGomez``
std: mention `remove_dir_all` can emit `DirectoryNotEmpty` when concurrently written into
Closes#139958
The current documentation for `std::fs::remove_dir_all` function does not explicitly mention the error types that may be returned in concurrent scenarios. Specifically, when one thread attempts to remove a directory tree while another thread simultaneously writes files to that directory, the function may return an `io::ErrorKind::DirectoryNotEmpty` error, but this behavior is not clearly mentioned in the current documentation.
r? libs
simd_select_bitmask: the 'padding' bits in the mask are just ignored
Fixes https://github.com/rust-lang/rust/issues/137942: we documented simd_select_bitmask to require the 'padding' bits in the mask (the mask can sometimes be longer than the vector; I am referring to these extra bits as 'padding' here) to be zero, mostly because nobody felt like doing the research for what should be done when they are non-zero. However, codegen is already perfectly happy just ignoring them, so in practice they can have any value. Some of the intrinsic wrappers in stdarch have trouble ensuring that they are zero. So let's just adjust the docs and Miri to permit non-zero 'padding' bits.
Cc ````@Amanieu```` ````@workingjubilee````
Fix some grammar errors and hyperlinks in doc for `trait Allocator`
I was reading the allocator docs and noticed some weird sentences and missing hyperlink, so I fixed them and made this small PR.
* "while until either" could also be changed to "for a while until either", but I just deleted "while".
* fixed sentence with incorrect "at" and "has/have".
* linked [*currently allocated*] similar to other methods. All other hyperlinks are fine.
docs: Add example to `Iterator::take` with `by_ref`
If you want to logically split an iterator after `n` items, you might first discover `take`. Before this change, you'd find that `take` consumes the iterator, and you'd probably be stuck. The answer involves `by_ref`, but that's hard to discover, especially since `by_ref` is a bit abstract and `Iterator` has many methods.
After this change, you'd see the example showing `take` along with `by_ref`, which allows you to continue using the rest of the iterator. `by_ref` had a good example involving `take` already, so this change just duplicates that existing example under `take`.
Refactor `diy_float`
The refactor replaces bespoke algorithms with functions already inside the standard library, improving both codegen and readability.
The inline documentation for all other free functions in the `std::io`
module use the phrase "creates a" instead of "create a", except for the
currently nightly-only `std::io::pipe()` function. This commit updates
the text to align with the predominant wording in the `std::io` module.
I recognize this PR is quite a minuscule nitpick, so feel free to ignore
and close if you disagree and/or there are bigger fish to fry. 😄
In LLVM 21 PR https://github.com/llvm/llvm-project/pull/130940
`TargetRegistry::createTargetMachine` was changed to take a `const
Triple&` and has deprecated the old `StringRef` method.
@rustbot label llvm-main
Decouple SCC annotations from SCCs
This rewires SCC annotations to have them be a separate, visitor-type data structure. It was broken out of #130227, which needed them to be able to remove unused annotations after computation without recomputing the SCCs themselves.
As a drive-by it also removes some redundant code from the hot loop in SCC construction for a performance improvement.
r? lcnr
shared-generics: Do not share instantiations that contain local-only types
In Zed shared-generics loading takes up a significant chunk of time in incremental build, as rustc deserializes rmeta of all dependencies of a crate. I've recently realized that shared-generics includes all instantiations of some_generic_function in the following snippet:
```rs
pub fn some_generic_function(_: impl Fn()) {}
pub fn non_generic_function() {
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
}
```
even though none of these instantiations can actually be created from outside of `non_generic_function`. This is a dummy example, but we do rely on invoking callbacks with FnOnce a lot in our codebase.
This PR makes shared-generics account for visibilities of generic arguments; an item is only considered for exporting if it is reachable from the outside or if all of it's arguments are visible outside of the local crate.
This PR reduces incremental build time for Zed (touch editor.rs scenario) from 12.4s to 10.4s. I'd love to see a perf run if possible; per my checks this PR does not incur new instantiations in downstream crates, so if there'd be perf regressions, I'd expect them to come from newly-introduced visibility checks.
According to `anyhow`'s Cargo.toml:
> On compilers older than 1.65, features=["backtrace"] may be used to enable
> backtraces via the `backtrace` crate. This feature has no effect on 1.65+
> besides bringing in an unused dependency, as `std::backtrace` is always
> preferred.
So this is just bringing in an unused dependency.
This reverts commit e907456b2e10622ccd854a3bba8d02ce170b5dbb.
This is due to a CI failure (technically broken HTML with duplicate IDs)
caused by this commit (visibly fine but invalid per the HTML specification
and detected by the LinkCheck tool on the Rust CI process).
The author independently working on a rustdoc enhancement to enable writing
multiple references to a single footnote. Once that change makes it to the
stage0 compiler (the next beta), the original change will be acceptable
again (postponed for possibly the version 1.89 cycle).
