Weaken `assert_dep_node_not_yet_allocated_in_current_session` for multiple threads
This changes `assert_dep_node_not_yet_allocated_in_current_session` to not panic if the node is already marked green. Another thread may manage to mark it green if there was uncolored node when we initially tried to mark it green.
Suppress unused_mut lint if mutation fails due to borrowck error
Remedying the borrowck error will likely result in the mut becoming used, and therefore the lint is likely incorrect.
Fixesrust-lang/rust#152024
r? compiler
Remove some unnecessary `try`-related type annotations
I left a few, like
```rust
let result: Result<_, ModError<'_>> = try {
```
where it felt like seeing it might still be useful for the reader.
Feel free to push back on any of these changes if you think they should be left alone.
Support long diff conflict markers
git can be configured to use more than 7 characters for conflict markers, and jj automatically uses longer conflict markers when the text contains any char sequence that could be confused with conflict markers. Ensure that we only point at markers that are consistent with the start marker's length.
Ensure that we only consider char sequences at the beginning of a line as a diff marker.
Fix https://github.com/rust-lang/rust/issues/150352.
GVN: Only propagate borrows from SSA locals
Fixes https://github.com/rust-lang/rust/issues/141313. This is a more principled fix than https://github.com/rust-lang/rust/pull/147886.
Using a reference that is not a borrowing of an SSA local at a new location may be UB.
The PR has two major changes.
The first one, when introducing a new dereference at a new location, is that the reference must point to an SSA local or be an immutable argument. `dereference_address` has handled SSA locals.
The second one, if we cannot guard to the reference point to an SSA local in `visit_assign`, we have to rewrite the value to opaque. This avoids unifying the following dereferences that also are references:
```rust
let b: &T = *a;
// ... `a` is allowed to be modified. `c` and `b` have different borrowing lifetime.
// Unifying them will extend the lifetime of `b`.
let c: &T = *a;
```
See also https://github.com/rust-lang/rust/issues/130853.
This still allows unifying non-reference dereferences:
```rust
let a: &T = ...;
let b: T = *a;
// ... a is NOT allowed to be modified.
let c: T = *a;
```
r? @cjgillot
Avoid a bogus THIR span for `let x = offset_of!(..)`
The code that creates spans for THIR `let` statements was doing span endpoint manipulation without checking for inclusion/context, resulting in bogus spans observed in https://github.com/rust-lang/rust/pull/151693.
The incorrect spans are easiest to observe with `-Zunpretty=thir-tree`, but they also cause strange user-facing diagnostics for irrefutable let-else.
Remove `rustdoc` adhoc group
With https://github.com/rust-lang/triagebot/pull/2273, reviewers can now tell triagebot to opt them out of being assigned through a given team, so that `r? <team>` does not consider them if they don't want to.
That means that we can now finally get rid of adhoc groups that correspond to actual Rust teams. I wanted to start with a smaller team than `t-compiler` to test this, so I started with `rustdoc`, which was the smallest team that I found an adhoc group for.
Currently, the `rustdoc` team contains the following members:
- aDotInTheVoid
- GuillaumeGomez
- notriddle
- fmease
- camelid
- Manishearth
- Urgau
- lolbinarycat
- yotamofek
Only three of those were previously assignable through `r? rustdoc`. So to reproduce the previous state, I will run `as <username> work set-team-rotation-mode rustdoc off` for the remaining members of the `rustdoc` team before this is merged.
If more people from `t-rustdoc` want to join the review rotation, they can send [triagebot](https://rust-lang.zulipchat.com/#narrow/dm/261224-triagebot) a DM with `work set-team-rotation-mode rustdoc on`.
CC @rust-lang/rustdoc
Introduce helper `ty::Generics::has_own_self`
The pattern `generics.has_self && generics.parent.is_none()` only occurs 5 times in rustc+rustdoc at the time of writing but I keep getting reminded/annoyed that there doesn't exist a nice wrapper fn that abstracts it & immediately clarifies the intent. Most recently that happened when working on my open PR RUST-129543 in which I add yet another occurrence of it ([via](https://github.com/fmease/rust/blob/ae8c0a5a46364b0d0bca349cba544adb762e7c0a/compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs#L1771-L1773)).
For context, `generics.has_self` indicates that there is a `Self` type parameter (at position 0) in the "oldest" / "root" generic parameter list in the chain of generic parameter lists (rephrased: it's true if the chain *as a whole* has a `Self` type parameter). `has_own_self` on the other hand indicates that the `own_params` contain a `Self` type parameter which is sometimes needed for offsetting the own parameters or arguments.
RwLock: refine documentation to emphasize non-reentrancy guarantees
This addresses the need for clarification brought up in rust-lang/rust#149693. Specifically, it notes that some implementations may choose to panic if they detect deadlock situations during recursive locking attempts for both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock. (as demonstrated in the very same documentation a few paragraphs above)
* Improve documentation regarding the possibility of panics during recursive read or write lock attempts.
Issues: https://github.com/rust-lang/rust/issues/149693
Convert to inline diagnostics in `rustc_lint`
For https://github.com/rust-lang/rust/issues/151366
r? @jdonszelmann
This was a big one! Second to last one, `rustc_parse` is the last one and even bigger :P
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#148590 (Stabilize `atomic_try_update`and deprecate `fetch_update` starting 1.99.0)
- rust-lang/rust#150522 (Stabilize new inclusive range type and iterator type)
- rust-lang/rust#152235 (Convert to inline diagnostics in `rustc_parse`)
- rust-lang/rust#152267 (feat: Implement `int_from_ascii` for `NonZero<T>`)
- rust-lang/rust#151576 (Stabilize `core::hint::cold_path`)
- rust-lang/rust#151933 (Linker-plugin-based LTO: give an explanation how to use linker-plugin-lto with full LTO)
- rust-lang/rust#152010 (Ignore all debuginfo tests for LLDB that we do not run in CI)
- rust-lang/rust#152199 (Move `rustc_query_system::cache`.)
Move `rustc_query_system::cache`.
It only defines two types, `Cache` and `WithDepNode`. Neither has anything much to do with queries -- they use `DepNodeIndex`, that's all.
This commit moves the module into `rustc_middle`, to where they are used. It also renames the extremely non-descriptive `Cache` as `WithDepNodeCache`.
r? @Zalathar
Ignore all debuginfo tests for LLDB that we do not run in CI
We only run LLDB 1500 in CI. Any test with a min-lldb-version above that is currently ignored. It's not clear any of these tests actually work with that LLDB version, and they definitely don't work on LLDB ~2100. So, ignore them until we fix debuginfo testing.
Fixesrust-lang/rust#151966
Linker-plugin-based LTO: give an explanation how to use linker-plugin-lto with full LTO
Closesrust-lang/rust#138910
The existing linker-plugin-based LTO documentation does not describe the correct usage of full LTO. Specifically, when invoking `rustc` with full LTO, the `-C lto` flag must be passed in addition to `-C linker-plugin-lto`.
Also, this PR documents the use of full LTO when linking Rust with Fortran. Unfortunately, LLVM `flang` does not currently support ThinLTO, so full LTO is the only viable option in this case.
Toolchain combinations were slightly updated.
TODO:
- [x] check swiftc compiler. Almost unusable.
- [x] check how std lib is actually compiled
- [x] add note about LLD and bitcode
- [x] report bug to LLVM: https://github.com/llvm/llvm-project/issues/179800
<details>
<summary>Swiftc is unusable</summary>
https://www.swift.org/install/ gave me LLVM-17. During playing with swift main + rust static library, LLVM-23 removed main :D
```console
# thin LTO Rust:
rustc --crate-type=staticlib -Clinker-plugin-lto -Copt-level=3 ./ftn.rs
# full LTO swift:
swiftc -static libftn.a main.swift -lto=llvm-full -O -use-ld=/tmp/test/llvm-project/install/bin/ld.lld -Xlinker --gc-sections -Xlinker --as-needed -o sr
./sr
> ftn() returned: 77
# thin LTO swift:
swiftc -static libftn.a main.swift -lto=llvm-thin -O -use-ld=/tmp/test/llvm-project/install/bin/ld.lld -Xlinker --gc-sections -Xlinker --as-needed -o sr
./sr
> No output
```
</details>
Stabilize `core::hint::cold_path`
`cold_path` has been around unstably for a while and is a rather useful tool to have. It does what it is supposed to and there are no known remaining issues, so stabilize it here (including const).
Newly stable API:
```rust
// in core::hint
pub const fn cold_path();
```
I have opted to exclude `likely` and `unlikely` for now since they have had some concerns about ease of use that `cold_path` doesn't suffer from. `cold_path` is also significantly more flexible; in addition to working with boolean `if` conditions, it can be used in `match` arms, `if let`, closures, and other control flow blocks. `likely` and `unlikely` are also possible to implement in user code via `cold_path`, if desired.
Closes: https://github.com/rust-lang/rust/issues/136873 (tracking issue)
---
There has been some design and implementation work for making `#[cold]` function in more places, such as `if` arms, `match` arms, and closure bodies. Considering a stable `cold_path` will cover all of these usecases, it does not seem worth pursuing a more powerful `#[cold]` as an alternative way to do the same thing. If the lang team agrees, then:
Closes: https://github.com/rust-lang/rust/issues/26179
Closes: https://github.com/rust-lang/rust/pull/120193
feat: Implement `int_from_ascii` for `NonZero<T>`
- Tracking issue: rust-lang/rust#134821
This pull request adds `from_ascii` and `from_ascii_radix` methods to `NonZero<T>` that parses a non-zero integer from an ASCII-byte slice (`&[u8]`) with decimal digits or digits in a given base.
When using the combination of `int::from_ascii` or `int::from_ascii_radix` and `NonZero::<T>::new`, [`IntErrorKind::Zero`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html#variant.Zero) cannot be returned as an error.
`NonZero::<T>::from_str_radix` and `NonZero::<T>::from_str` require a string (`&str`) as a parameter.
```rust
// Cannot return `IntErrorKind::Zero` as an error.
assert_eq!(NonZero::new(u8::from_ascii(b"0").unwrap()), None);
// Can return `IntErrorKind::Zero` as an error.
let err = NonZero::<u8>::from_ascii(b"0").unwrap_err();
assert_eq!(err.kind(), &IntErrorKind::Zero);
```
See also rust-lang/rust#152193
Convert to inline diagnostics in `rustc_parse`
This was the most annoying one by far, had to make a few changes to the representation of two errors (no user-facing changes tho), these changes are in separate commits for clarity :)
For https://github.com/rust-lang/rust/issues/151366
r? @jdonszelmann
Stabilize new inclusive range type and iterator type
Part 1 of stabilizing the new range types for rust-lang/rust#125687
stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter`. Newly stable API:
```rust
// in core and std
pub mod range;
// in core::range
pub struct RangeInclusive<Idx> {
pub start: Idx,
pub last: Idx,
}
impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ }
impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> {
pub const fn contains<U>(&self, item: &U) -> bool
where
Idx: [const] PartialOrd<U>,
U: ?Sized + [const] PartialOrd<Idx>;
pub const fn is_empty(&self) -> bool
where
Idx: [const] PartialOrd;
}
impl<Idx: Step> RangeInclusive<Idx> {
pub fn iter(&self) -> RangeInclusiveIter<Idx>;
}
impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ }
impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ }
impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ }
impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ }
pub struct RangeInclusiveIter<A>(/* ... */);
impl<A: Step> RangeInclusiveIter<A> {
pub fn remainder(self) -> Option<RangeInclusive<A>>;
}
impl<A: Step> Iterator for RangeInclusiveIter<A> {
type Item = A;
/* ... */
}
impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ }
impl<A: Step> FusedIterator for RangeInclusiveIter<A> { }
impl<A: Step> IntoIterator for RangeInclusive<A> {
type Item = A;
type IntoIter = RangeInclusiveIter<A>;
/* ... */
}
impl ExactSizeIterator for RangeInclusiveIter<u8> { }
impl ExactSizeIterator for RangeInclusiveIter<i8> { }
unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> {
type Output = [T];
/* ... */
}
unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> {
type Output = str;
/* ... */
}
```
I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.
Adwin White