Update Rust Foundation links in Readme
The Rust Foundation links in the Readme are outdated. I'm not sure if this is the best wording to use in place of the media guide, that can be changed if need be.
Improve upvar analysis for deref of child capture
Two fixes to the heuristic I implemented in #123660. As I noted in the code:
> Luckily, if this function is not correct, then the program is not unsound, since we still borrowck and validate the choices made from this function -- the only side-effect is that the user may receive unnecessary borrowck errors.
This indeed fixes unnecessary borrowck errors.
r? oli-obk
---
The heuristic is only valid if we deref a `&T`, not a `&mut T` or `Box<T>`, so make sure to check the type. This fixes:
```rust
struct Foo { precise: i32 }
fn mut_ref_inside_mut(f: &mut Foo) {
let x: impl AsyncFn() = async move || {
let y = &f.precise;
};
}
```
Since the capture from `f` to `&f.precise` needs to be treated as a lending borrow from the parent coroutine-closure to the child coroutine.
---
The heuristic is also valid if *any* deref projection in the child capture's projections is a `&T`, but we were only looking at the last one. This ensures that this function is considered not to be lending:
```rust
struct Foo { precise: i32 }
fn ref_inside_mut(f: &mut &Foo) {
let x: impl Fn() -> _ = async move || {
let y = &f.precise;
};
}
```
(Specifically, checking that `impl Fn() -> _` is satisfied is exercising that the coroutine is not considered to be lending.)
Rollup of 5 pull requests
Successful merges:
- #136293 (document capacity for ZST as example)
- #136359 (doc all differences of ptr:copy(_nonoverlapping) with memcpy and memmove)
- #136816 (refactor `notable_traits_button` to use iterator combinators instead of for loop)
- #138552 (Misc print request handling cleanups + a centralized test for print request stability gating)
- #138573 (Make `_Unwind_Action` a type alias, not enum)
r? `@ghost`
`@rustbot` modify labels: rollup
Make `_Unwind_Action` a type alias, not enum
It's bitflags in practice, so an enum is unsound, as an enum must only have the described values. The x86_64 psABI declares it as a `typedef int _Unwind_Action`, which seems reasonable. I made a newtype first but that was more annoying than just a typedef. We don't really use this value for much other than a short check.
I ran `x check library --target aarch64-unknown-linux-gnu,x86_64-pc-windows-gnu,x86_64-fortanix-unknown-sgx,x86_64-unknown-haiku,x86_64-unknown-fuchsi
a,x86_64-unknown-freebsd,x86_64-unknown-dragonfly,x86_64-unknown-netbsd,x86_64-unknown-openbsd,x86_64-unknown-redox,riscv64-linux-android,armv7-unknown-freebsd` (and some more but they failed to build for other reasons :D)
fixes#138558
r? workingjubilee have fun
Misc print request handling cleanups + a centralized test for print request stability gating
I was working on implementing `--print=supported-crate-types`, then I noticed some things that were mildly annoying me, so I pulled out these changes. In this PR:
- First commit adds a centralized test `tests/ui/print/stability.rs` that is responsible for exercising stability gating of the print requests.
- AFAICT we didn't have any test that systematically checks this.
- I coalesced `tests/ui/feature-gates/feature-gate-print-check-cfg.rs` (for `--print=check-cfg`) into this test too, since `--print=check-cfg` is only `-Z unstable-options`-gated like other unstable print requests, and is not additionally feature-gated. cc ``@Urgau`` in case you have any concerns.
- Second commit alphabetically sorts the `PrintKind` enum for consistency because the `PRINT_KINDS` list (using the enum) is *already* alphabetically sorted.
- Third commit pulls out two helpers:
1. A helper `check_print_request_stability` for checking stability of print requests and the diagnostics for using unstable print requests without `-Z unstable-options`, to avoid repeating the same logic over and over.
2. A helper `emit_unknown_print_request_help` for the unknown print request diagnostics to make print request collection control flow more obvious.
- Fourth commit renames `PrintKind::{TargetSpec,AllTargetSpecs}` to `PrintKind::{TargetSpecJson,AllTargetSpecsJson}` to better reflect their actual print names, `--print={target-spec-json,all-target-specs-json}`.
r? ``@nnethercote`` (or compiler/reroll)
refactor `notable_traits_button` to use iterator combinators instead of for loop
~Small cleanup.
Use `Iterator::any` instead of `for` loop with `predicate = true;`.
I think this makes the code more readable... and also has the additional benefit of short-circuiting the iterator when a notable trait is found (a `break` statement was missing in the `for` loop version, I think). Probably won't be significant enough to show on perf results, though.~
Three commits, each attempting to optimize `notable_trait_buttons` by a little bit.
document capacity for ZST as example
The main text already covers this, although it provides weaker guarantees, but I think an example in the right spot does not hurt. Fixes#80747
Add `From<{integer}>` for `f16`/`f128` impls
This PR adds `impl From<{bool,i8,u8}> for f16` and `impl From<{bool,i8,u8,i16,u16,i32,u32}> for f128`.
The `From<{i64,u64}> for f128` impls are left commented out as adding them would allow using `f128` on stable before it is stabilised like in the following example:
```rust
fn f<T: From<u64>>(x: T) -> T { x }
fn main() {
let x = f(1.0); // the type of the literal is inferred to be `f128`
}
```
None of the impls added in this PR have this issue as they are all, at minimum, also implemented by `f64`.
This PR will need a crater run for the `From<{i32,u32}>` impls, as `f64` is no longer the only float type to implement them (similar to the cause of #125198).
cc `@bjoernager`
r? `@tgross35`
Tracking issue: #116909
It's bitflags in practice, so an enum is unsound, as an enum must only
have the described values. The x86_64 psABI declares it as a `typedef
int _Unwind_Action`, which seems reasonable. I made a newtype first but
that was more annoying than just a typedef. We don't really use this
value for much other than a short check.
Optimize multi-char string patterns
Uses specialization for `[T]::contains` from #130991 to optimize multi-char patterns in string searches.
Requesting a perf run to see if this actually has an effect 🙏
(I think that adding `char` to the list of types for which the `SliceContains` is specialized is a good idea, even if it doesn't show up on perf - might be helpful for downstream users)
To correspond to their actual print request names, `target-spec-json`
and `all-target-specs-json`, and for consistency with other print name
<-> print kind mappings.
I can't find any dedicated tests that actually exercises the stability
gating (via `-Z unstable-options`) of print requests, so here's a
dedicated one.
I coalesced `tests/ui/feature-gates/feature-gate-print-check-cfg.rs`
into this test, because AFAICT that print request is not feature gated,
but only `-Z unstable-options`-gated just like other unstable print
requests.
core: Make `Debug` impl of raw pointers print metadata if present
Make Rust pointers appear less magic by including metadata information in their `Debug` output.
This does not break Rust stability guarantees because `Debug` impl are explicitly exempted from stability:
https://doc.rust-lang.org/std/fmt/trait.Debug.html#stability
> ## Stability
>
> Derived `Debug` formats are not stable, and so may change with future Rust versions. Additionally, `Debug` implementations of types provided by the standard library (`std`, `core`, `alloc`, etc.) are not stable, and may also change with future Rust versions.
Note that a regression test is added as a separate commit to make it clear what impact the last commit has on the output.
Closes#128684 because the output of that code now becomes:
```
thread 'main' panicked at src/main.rs:5:5:
assertion `left == right` failed
left: Pointer { addr: 0x7ffd45c6fc6b, metadata: 5 }
right: Pointer { addr: 0x7ffd45c6fc6b, metadata: 3 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
added some new test to check for result and options opt
Apologies for the delay. Finally have some time to get back into contributing.
## Context
- Added some tests to show optimization on result and options for 64 and 128 bits
- Relevant issue https://github.com/rust-lang/rust/issues/101210
## Some newb questions from me
- [x] My local llvm IR has `nuw` in `result_nop_match_128` etc whereas [godbolt version](https://rust.godbolt.org/z/Td9zoT5zn) doesn't have. So I put optional there, but not sure if it's desirable (maybe I'm not using the compiled llvm in the repo). I ran the test with
```bash
./x test tests/codegen/try_question_mark_nop.rs
```
- [x] Unless I'm reading it wrongly, but `option_nop_match_128` and `option_nop_traits_128` look to be **not** optimized away?
Update:
Here's the test for future reference
```rust
// CHECK-LABEL: `@option_nop_match_128`
#[no_mangle]
pub fn option_nop_match_128(x: Option<i128>) -> Option<i128> {
// CHECK: start:
// CHECK-NEXT: %trunc = trunc nuw i128 %0 to i1
// CHECK-NEXT: br i1 %trunc, label %bb3, label %bb4
// CHECK: bb3:
// CHECK-NEXT: %2 = getelementptr inbounds {{(nuw )?}}i8, ptr %_0, i64 16
// CHECK-NEXT: store i128 %1, ptr %2, align 16
// CHECK: bb4:
// CHECK-NEXT: %storemerge = phi i128 [ 1, %bb3 ], [ 0, %start ]
// CHECK-NEXT: store i128 %storemerge, ptr %_0, align 16
// CHECK-NEXT: ret void
match x {
Some(x) => Some(x),
None => None,
}
}
```
r? `@scottmcm`
Rollup of 16 pull requests
Successful merges:
- #133055 (Expand `CloneToUninit` documentation.)
- #137147 (Add exclude to config.toml)
- #137864 (Don't drop `Rvalue::WrapUnsafeBinder` during GVN)
- #137890 (doc: clarify that consume can be called after BufReader::peek)
- #137956 (Add RTN support to rustdoc)
- #137968 (Properly escape regexes in Python scripts)
- #138082 (Remove `#[cfg(not(test))]` gates in `core`)
- #138275 (expose `is_s390x_feature_detected!` from `std::arch`)
- #138303 (Fix Ptr inconsistency in {Rc,Arc})
- #138309 (Add missing doc for intrinsic (Fix PR135334))
- #138323 (Expand and organize `offset_of!` documentation.)
- #138329 (debug-assert that the size_hint is well-formed in `collect`)
- #138465 (linkchecker: bump html5ever)
- #138471 (Clean up some tests in tests/ui)
- #138472 (Add codegen test for #129795)
- #138484 (Use lit span when suggesting suffix lit cast)
r? `@ghost`
`@rustbot` modify labels: rollup
debug-assert that the size_hint is well-formed in `collect`
Closes#137919
In the hopes of helping to catch any future accidentally-incorrect rustc or stdlib iterators (like the ones #137908 accidentally found), this has `Iterator::collect` call `size_hint` and check its `low` doesn't exceed its `Some(high)`.
There's of course a bazillion more places this *could* be checked, but the hope is that this one is a good tradeoff of being likely to catch lots of things while having minimal maintenance cost (especially compared to putting it in *every* container's `from_iter`).
Expand and organize `offset_of!` documentation.
* Give example of how to get the offset of an unsized tail field (prompted by discussion <https://github.com/rust-lang/rust/pull/133055#discussion_r1986422206>).
* Specify the return type.
* Add section headings.
* Reduce “Visibility is respected…”, to a single sentence.
* Move `offset_of_enum` documentation to unstable book (with link to it).
* Add `offset_of_slice` documentation in unstable book.
r? Mark-Simulacrum
Add missing doc for intrinsic (Fix PR135334)
The previous [PR135334](https://github.com/rust-lang/rust/pull/135334) mentioned that some of the intrinsic APIs were missing safety descriptions.
Among intrinsic APIs that miss safety specifications, most are related to numerical operations. They might need to be discussed and then seen how to organize.
Apart from them, only a few intrinsics lack safety. So this PR deals with the APIs with non-numerical operations in priority.
