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.
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](ae8c0a5a46/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
Also duplicate `#[expect]` attribute in `#[derive]`-ed code
This PR updates our derive logic to also duplicate any `#[expect]` attribute in the `#[derive]`-ed code, as we already do for all the other lint attribute (`#[allow]`, `#[warn]`, `#[deny]`, ...).
The original and duplicated attribute share the same attribute id, which due to the way [`check_expectations`](56aaf58ec0/compiler/rustc_lint/src/expect.rs (L28-L46)) is implemented makes the expectation fulfilled if the lint is either trigger in the original code or the derived code.
This was discussed by T-lang in https://github.com/rust-lang/rust/issues/150553#issuecomment-3780810363.
cc @rust-lang/lang-ops (in case you want to do an FCP)
Fixesrust-lang/rust#150553
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.
Add avr_target_feature
This adds the following unstable target features (tracking issue: https://github.com/rust-lang/rust/issues/146889):
- The following two are particularly important for properly supporting inline assembly:
- `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also https://github.com/rust-lang/rust/pull/146901)
- `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also 2a528760bf)
- The followings help recognizing whether specific instructions are available:
- `addsubiw`
- `break`
- `eijmpcall`
- `elpm`
- `elpmx`
- `ijmpcall`
- `jmpcall`
- `lpm`
- `lpmx`
- `movw`
- `mul`
- `rmw`
- `spm`
- `spmx`
Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure.
- Report future-incompatible warning (https://github.com/rust-lang/rust/issues/116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM.
- See https://github.com/rust-lang/rust/pull/146900#issuecomment-3323558005 for details.
LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something.
(The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).)
cc @Patryk27 @Rahix
r? workingjubilee
@rustbot label +O-AVR +A-target-feature
