Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments.
The compiler relies on `hir::Lifetime` being aligned to at least 4 bytes(for the purposes of pointer tagging).
However, on some systems(like m68k) with lower alignment requirements(eg. usize / u32 aligned to 2 bytes),`hir::Lifetime` will be aligned to only 2 bytes.
This causes the compilation to fail on those systems - a const assert in the compiler fails.
This PR makes the aligement requriement of hir::Lifetime explict. This has no effect on platforms where that already is the case(repr align can only raise alignment), but ensures the alignment will stay correct no matter what.
fixed typo chunks->as_chunks
Fixesrust-lang/rust#144555
info-:
fix typo chunks -> as_chunks
This now take us to as_chunks page when clicking on as_chunks link and not to chunks .
Thanks .
constify with_exposed_provenance
We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs.
Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB.
Tracking: https://github.com/rust-lang/rust/issues/144538
Cc `````@rust-lang/wg-const-eval````` `````@rust-lang/opsem`````
Add `core::mem::DropGuard`
## 1.0 Summary
This PR introduces a new type `core::mem::DropGuard` which wraps a value and runs a closure when the value is dropped.
```rust
use core::mem::DropGuard;
// Create a new guard around a string that will
// print its value when dropped.
let s = String::from("Chashu likes tuna");
let mut s = DropGuard::new(s, |s| println!("{s}"));
// Modify the string contained in the guard.
s.push_str("!!!");
// The guard will be dropped here, printing:
// "Chashu likes tuna!!!"
```
## 2.0 Motivation
A number of programming languages include constructs like `try..finally` or `defer` to run code as the last piece of a particular sequence, regardless of whether an error occurred. This is typically used to clean up resources, like closing files, freeing memory, or unlocking resources. In Rust we use the `Drop` trait instead, allowing us to [never having to manually close sockets](https://blog.skylight.io/rust-means-never-having-to-close-a-socket/).
While `Drop` (and RAII in general) has been working incredibly well for Rust in general, sometimes it can be a little verbose to setup. In particular when upholding invariants are local to functions, having a quick inline way to setup an `impl Drop` can be incredibly convenient. We can see this in use in the Rust stdlib, which has a number of private `DropGuard` impls used internally:
- [library/alloc/src/vec/drain.rs](9982d6462b/library/alloc/src/vec/drain.rs (L177))
- [library/alloc/src/boxed/thin.rs](9982d6462b/library/alloc/src/boxed/thin.rs (L362))
- [library/alloc/src/slice.rs](9982d6462b/library/alloc/src/slice.rs (L413))
- [library/alloc/src/collections/linked_list.rs](9982d6462b/library/alloc/src/collections/linked_list.rs (L1135))
- [library/alloc/src/collections/binary_heap/mod.rs](9982d6462b/library/alloc/src/collections/binary_heap/mod.rs (L1816))
- [library/alloc/src/collections/btree/map.rs](9982d6462b/library/alloc/src/collections/btree/map.rs (L1715))
- [library/alloc/src/collections/vec_deque/drain.rs](9982d6462b/library/alloc/src/collections/vec_deque/drain.rs (L95))
- [library/alloc/src/vec/into_iter.rs](9982d6462b/library/alloc/src/vec/into_iter.rs (L488))
- [library/std/src/os/windows/process.rs](9982d6462b/library/std/src/os/windows/process.rs (L320))
- [tests/ui/process/win-proc-thread-attributes.rs](9982d6462b/tests/ui/process/win-proc-thread-attributes.rs (L17))
## 3.0 Design
This PR implements what can be considered about the simplest possible design:
1. A single type `DropGuard` which takes both a generic type `T` and a closure `F`.
2. `Deref` + `DerefMut` impls to make it easy to work with the `T` in the guard.
3. An `impl Drop` on the guard which calls the closure `F` on drop.
4. An inherent `fn into_inner` which takes the type `T` out of the guard without calling the closure `F`.
Notably this design does not allow divergent behavior based on the type of drop that has occurred. The [`scopeguard` crate](https://docs.rs/scopeguard/latest/scopeguard/index.html) includes additional `on_success` and `on_onwind` variants which can be used to branch on unwind behavior instead. However [in a lot of cases](https://github.com/rust-lang/rust/issues/143612#issuecomment-3053928328) this doesn’t seem necessary, and using the arm/disarm pattern seems to provide much the same functionality:
```rust
let guard = DropGuard::new((), |s| ...); // 1. Arm the guard
other_function(); // 2. Perform operations
guard.into_inner(); // 3. Disarm the guard
```
`DropGuard` combined with this pattern seems like it should cover the vast majority of use cases for quick, inline destructors. It certainly seems like it should cover all existing uses in the stdlib, as well as all existing uses in crates like [hashbrown](https://github.com/search?q=repo%3Arust-lang%2Fhashbrown%20guard&type=code).
## 4.0 Acknowledgements
This implementation is based on the [mini-scopeguard crate](https://github.com/yoshuawuyts/mini-scopeguard) which in turn is based on the [scopeguard crate](https://docs.rs/scopeguard). The implementations only differ superficially; because of the nature of the problem there is only really one obvious way to structure the solution. And the scopeguard crate got that right!
## 5.0 Conclusion
This PR adds a new type `core::mem::DropGuard` to the stdlib which adds a small convenience helper to create inline destructors with. This would bring the majority of the functionality of the `scopeguard` crate into the stdlib, which is the [49th most downloaded crate](https://crates.io/crates?sort=downloads) on crates.io (387 million downloads).
Given the actual implementation of `DropGuard` is only around 60 lines, it seems to hit that sweet spot of low-complexity / high-impact that makes for a particularly efficient stdlib addition. Which is why I’m putting this forward for consideration; thanks!
Add `--link-targets-dir` argument to linkchecker
In my release notes API list tool (rust-lang/rust#143053) I want to check whether all links generated by the tool are actually valid, and using linkchecker seems to be the most sensible choice.
Linkchecker currently has a fairly big limitation though: it can only check a single directory, it checks *all* of the files within it, and link targets must point inside that same directory. This works great when checking the whole documentation package, but in my case I only need to check that one file contains valid links to the standard library docs.
To solve that, this PR adds a new `--link-targets-dir` flag to linkchecker. Directories passed to it will be valid link targets (with lower priority than the root being checked), but links within them will not be checked.
I'm not that happy with the name of the flag, happy for it to be bikeshedded.
The bug was triggered by a particular usage of the `?` try operator in a
proc-macro expansion.
Thanks to lqd for the minimization.
Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
Rename impl_of_method and trait_of_item
This PR used to tweak the implementation of impl_of_method, but that introduced a perf regression.
Rename impl_of_method and trait_of_item to impl_of_assoc and trait_of_assoc respectively. This reflects how the two functions are closely related. And it reflects the behavior more accurately as the functions check whether the input is an associated item.
Allow more MIR SROA
This removes some guards on SROA that are no longer needed:
- With https://github.com/rust-lang/compiler-team/issues/838 it no longer needs to check for SIMD
- With https://github.com/rust-lang/compiler-team/issues/807 it no longer needs to check for niches
- This means that `Wrapper(char)` and `Pin<&mut T>` can get SRoA'd now, where previously they weren't because the check was banning SRaA for anything with a niche -- not just things with `#[rustc_layout_scalar_valid_range_*]`.
- Technically rust-lang/rust#133652 isn't complete yet, but `NonZero` and `NonNull` have already moved over, so this is fine. At worst this will mean that LLVM gets less `!range` metadata on something that wasn't already fixed by rust-lang/rust#133651 or rust-lang/rust#135236, but that's still sound, and unblocking general SRoA is worth that tradeoff.
We've had a few users get confused when VS Code shows `my_custom_check
--args $saved_file`, as it looks like substitution didn't occur.
Instead, show `my_custom_check --args ...` in the display output. This
is also shorter, and the VS Code status bar generally works best with
short text.
Fix CI for drop_guard
fix CI
fix all tidy lints
fix tidy link
add first batch of feedback from review
Add second batch of feedback from review
add third batch of feedback from review
fix failing test
Update library/core/src/mem/drop_guard.rs
Co-authored-by: Ruby Lazuli <general@patchmixolydic.com>
fix doctests
Implement changes from T-Libs-API review
And start tracking based on the tracking issue.
fix tidy lint
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#144072 (update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs)
- rust-lang/rust#144151 (`tests/ui/issues/`: The Issues Strike Back [1/N])
- rust-lang/rust#144300 (Clippy fixes for miropt-test-tools)
- rust-lang/rust#144399 (Add a ratchet for moving all standard library tests to separate packages)
- rust-lang/rust#144472 (str: Mark unstable `round_char_boundary` feature functions as const)
- rust-lang/rust#144503 (Various refactors to the codegen coordinator code (part 3))
- rust-lang/rust#144530 (coverage: Infer `instances_used` from `pgo_func_name_var_map`)
r? `@ghost`
`@rustbot` modify labels: rollup
coverage: Infer `instances_used` from `pgo_func_name_var_map`
In obscure circumstances involving macro-expanded spans, we would sometimes emit a covfun record for a function with no physical coverage counters, and therefore no corresponding entry in the “PGO names” section of the binary. The absence of that name entry causes `llvm-cov` to fail with the cryptic error message:
```text
malformed instrumentation profile data: function name is empty
```
We can eliminate this mismatch by removing `instances_used` entirely, and instead inferring its contents from the keys of `pgo_func_name_var_map`.
This makes it impossible for a "used" function to lack a PGO name entry.
---
This is an attempt to eliminate the cause of rust-lang/rust#141577 when re-landing changes like rust-lang/rust#144298 in the future.
I haven't been able to reproduce the underlying issue in an in-tree test, because the only known repro involves a non-trivial derive proc-macro that relies on `syn` and `proc-macro2`. But I have manually verified in a separate branch that this change would have prevented the reoccurrence of https://github.com/rust-lang/rust/issues/141577#issuecomment-3120667286.
Various refactors to the codegen coordinator code (part 3)
Continuing from https://github.com/rust-lang/rust/pull/144062 this removes an option without any known users, uses the object crate in favor of LLVM for getting the LTO bitcode and improves the coordinator channel handling.
str: Mark unstable `round_char_boundary` feature functions as const
Mark `floor_char_boundary`, `ceil_char_boundary` const
Simplify the implementations, reducing the number of arithmetic operations
It seems unnecessary to do the lower/upper bounds calculations and extra slicing when we can jump straight to inspecting the bytes, assuming the underlying data is valid UTF-8.
Tracking issue https://github.com/rust-lang/rust/issues/93743
