Implement internal `IsZero` for Wrapping and Saturating for `Vec` optimizations
This implements the `IsZero` trait for the `Wrapping` and `Saturating` types so that users of these types can get the improved performance from the specialization of creating a `Vec` from a single element repeated when it has a zero bit pattern (example `vec![0_i32; 500]`, or after this PR `vec![Wrapping(0_i32); 500]`)
CC #60978
fix: correct broken logic for return complition
It seems that we've accidentally deleted the tests here couple of years
ago, and then fairly recently made a typo during refactor as well.
Reinstall tests, with coverage marks this time :-)
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with @eddyb, we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
r? @eddyb
It seems that we've accidentally deleted the tests here couple of years
ago, and then fairly recently made a typo during refactor as well.
Reinstall tests, with coverage marks this time :-)
rustdoc: remove redundant mobile-sized `.source nav:not(.sidebar).sub`
It's redundant because there's already a selector `.source nav.sub` with exactly the same margin-left at [line 796].
[line 796]: 84f0c3f79a/src/librustdoc/html/static/css/rustdoc.css (L796)
This selector was added in 1e98fb1027, along with an identical desktop selector, but that desktop selector was removed in 6a5f8b1aef as part of a larger simplification.
Forbid mixing `System` with direct sytem allocator calls
e.g. [on windows](dec689432f/library/std/src/sys/windows/alloc.rs (L129-L178)), trying to mix `System::alloc` and `HeapFree` will not work because of the extra work done to serve higher alignments.
updated description of File struct in std::fs
I've seen several folks confused by the description of `std::fs::File` as "A reference to an open file on the filesystem." Apparently the word `reference` is sometimes taken to mean a Rust `&` reference, leading to confusion. Here's a recent representative [Reddit thread](https://www.reddit.com/r/rust/comments/x4k0lv/comment/imxu7v2/?utm_source=share&utm_medium=web2x&context=3), but I've seen this before as well.
This patch changes the description to "An object providing access to an open file on the filesystem." Hopefully this is clearer.
Fix internal doc link
The doc link from `DedupSortedIter` to `BTreeMap::bulk_build_from_sorted_iter` was broken when building internal documentation,
This prevented me from building internal documentation locally:
```
R:\Rust\rust> $env:RUSTDOCFLAGS="--document-private-items"
R:\Rust\rust> x doc library/std --open --stage 0
Building rustbuild
Compiling bootstrap v0.0.0 (R:\Rust\rust\src\bootstrap)
Finished dev [unoptimized] target(s) in 3.15s
Documenting stage0 std (x86_64-pc-windows-msvc)
Documenting core v0.0.0 (R:\Rust\rust\library\core)
Finished release [optimized] target(s) in 36.42s
Checking core v0.0.0 (R:\Rust\rust\library\core)
Checking rustc-std-workspace-core v1.99.0 (R:\Rust\rust\library\rustc-std-workspace-core)
Checking compiler_builtins v0.1.79
Documenting alloc v0.0.0 (R:\Rust\rust\library\alloc)
error: unresolved link to `BTreeMap::bulk_build_from_sorted_iter`
--> library\alloc\src\collections\btree\dedup_sorted_iter.rs:6:15
|
6 | /// Used by [`BTreeMap::bulk_build_from_sorted_iter`].
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no item named `BTreeMap` in scope
|
= note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
error: could not document `alloc`
```
fix wording for `derivable_impls`
While looking at the explanation as to why this lint was not automatically applicable, found the explanation a bit clunky grammatically.
Feel free to close if you consider the wording was correct in the first place.
changelog: none
Fix `unnecessary_to_owned` false positive
Fixes#9351.
Note that this commit reworks that fix for #9317. The change
is to check that the type implements `AsRef<str>` before regarding
`to_string` as an equivalent of `to_owned`. This was suggested
by Jarcho in the #9317 issue comments.
The benefit of this is that it moves some complexity out of
`check_other_call_arg` and simplifies the module as a whole.
changelog: FP: [`unnecessary_to_owned`]: No longer lints, if type change would cause errors in the caller function
safe transmute: use `Assume` struct to provide analysis options
This task was left as a TODO in #92268; resolving it brings [`BikeshedIntrinsicFrom`](https://doc.rust-lang.org/nightly/core/mem/trait.BikeshedIntrinsicFrom.html) more in line with the API defined in [MCP411](https://github.com/rust-lang/compiler-team/issues/411).
**Before:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<
Src,
Context,
const ASSUME_ALIGNMENT: bool,
const ASSUME_LIFETIMES: bool,
const ASSUME_VALIDITY: bool,
const ASSUME_VISIBILITY: bool,
> where
Src: ?Sized,
{}
```
**After:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<Src, Context, const ASSUME: Assume = { Assume::NOTHING }>
where
Src: ?Sized,
{}
```
`Assume::visibility` has also been renamed to `Assume::safety`, as library safety invariants are what's actually being assumed; visibility is just the mechanism by which it is currently checked (and that may change).
r? `@oli-obk`
---
Related:
- https://github.com/rust-lang/compiler-team/issues/411
- https://github.com/rust-lang/rust/issues/99571
It's redundant because there's already a selector `.source nav.sub` with
exactly the same margin-left at line 796.
This selector was added in 1e98fb1027, along
with an identical desktop selector, but that desktop selector was removed in
6a5f8b1aef as part of a larger simplification.
rustdoc: remove `.impl-items { flex-basis }` CSS, not in flex container
Added in 34bd2b845b
For this to actually do anything, [according to MDN] (and Firefox Dev Tools), it must be a "flex item", which only happens if its a direct child of a node with `display: flex` on it. It seems like it could not have worked at the time when this rule was added, because the only items in `rustdoc.css` with `display: flex` active were:
* `#help`
This should not contain anything like this.
* `.impl-items h4, h4.impl, h3.impl`
These are all headers, so they shouldn't contain `.impl-items` either.
* `.content .impl-items .method, .content .impl-items > .type, .impl-items > .associatedconstant`
Associated constants and methods definitely shouldn't contain a list of impl items, and the `.type` class seems to refer to type aliases, which, when shown inside of an impl, only show a link to the aliased type.
[according to MDN]: https://developer.mozilla.org/en-US/docs/Web/CSS/flex-basis
Nowadays, `display: flex` is a lot more prolific, but `.impl-items` still seems to only be used in plain block parents:
* If it's not a trait impl, then it's nested below a `<div>` with an id but no class, added in a5216cf67d. This will be `display: block`, probably. For example, [vec deref]
* Inherent impls also get a `<div>` tag, for example [vec impl], and they are also wrapped by their own non-flexbox `<details>` tag.
* If it's a tait implementation, then it's also nested below a `<details>` container, like [deref cstring].
[vec impl]: https://doc.rust-lang.org/1.63.0/std/vec/struct.Vec.html#impl
[vec deref]: https://doc.rust-lang.org/1.63.0/std/vec/struct.Vec.html#deref-methods-%5BT%5D
[deref cstring]: https://doc.rust-lang.org/1.63.0/std/ops/trait.Deref.html#impl-Deref
Also, this would imply that trait items ought to take up as much space as possible, pushing everything else to the edge of the screen. If this is nested directly below the `.rustdoc` container, which has a row basis, that would be bad.
Added in 34bd2b845b
For this to actually do anything, [according to MDN] (and Firefox Dev Tools),
it must be a "flex item", which only happens if its a direct child of a node
with `display: flex` on it. It seems like it could not have worked at the time
when this rule was added, because the only items in `rustdoc.css` with
`display: flex` active were:
* `#help`
This should not contain anything like this.
* `.impl-items h4, h4.impl, h3.impl`
These are all headers, so they shouldn't contain `.impl-items` either.
* `.content .impl-items .method, .content .impl-items > .type, .impl-items > .associatedconstant`
Associated constants and methods definitely shouldn't contain a list of impl
items, and the `.type` class seems to refer to type aliases, which, when
shown inside of an impl, only show a link to the aliased type.
[according to MDN]: https://developer.mozilla.org/en-US/docs/Web/CSS/flex-basis
Nowadays, `display: flex` is a lot more prolific, but `.impl-items` still
seems to only be used in plain block parents:
* If it's not a trait impl, then it's nested below a `<div>` with an id but no
class, added in a5216cf67d. This will be
`display: block`, probably. For example, [vec deref]
* Inherent impls also get a `<div>` tag, for example [vec impl], and they are
also wrapped by their own non-flexbox `<details>` tag.
* If it's a tait implementation, then it's also nested below a `<details>`
container, like [deref cstring].
[vec impl]: https://doc.rust-lang.org/1.63.0/std/vec/struct.Vec.html#impl
[vec deref]: https://doc.rust-lang.org/1.63.0/std/vec/struct.Vec.html#deref-methods-%5BT%5D
[deref cstring]: https://doc.rust-lang.org/1.63.0/std/ops/trait.Deref.html#impl-Deref
Also, this would imply that trait items ought to take up as much space as
possible, pushing everything else to the edge of the screen. If this is nested
directly below the `.rustdoc` container, which has a row basis, that would
be bad.
