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
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.
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
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
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
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
Fix ICE in normalizing inherent associated consts with `#[type_const]`
Fixesrust-lang/rust#151027Fixesrust-lang/rust#138089Fixesrust-lang/rust#138226Fixesrust-lang/rust#150960
When an inherent associated const is marked with `#[type_const]`, its generics expect args in the format `[Self, own_params...]`, similar to inherent associated types. However, HIR typeck's `instantiate_value_path` was constructing args in the regular associated const format `[impl_params..., own_params...]`. This mismatch caused ICEs when the `args` were later used in contexts expecting the IAC format, such as user type annotations and `borrowck`'s type ascription.
Port rustc_abi to the attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
This attribute either dumps the abi info for functions (debug arg)
or if you put it on a pair of fn ptr's it checks they match (assert_eq arg)
r? @JonathanBrouwer
Provide more context on trait bounds being unmet due to imperfect derive
When encountering a value that has a borrow checker error where the type was previously moved, when suggesting cloning verify that it is not already being derived. If it is, explain why the `derive(Clone)` doesn't apply:
```
note: if `TypedAddress<T>` implemented `Clone`, you could clone the value
--> $DIR/derive-clone-implicit-bound.rs:6:1
|
LL | #[derive(Clone, Copy)]
| ----- derived `Clone` adds implicit bounds on type parameters
LL | pub struct TypedAddress<T>{
| ^^^^^^^^^^^^^^^^^^^^^^^^-^
| | |
| | introduces an implicit `T: Clone` bound
| consider manually implementing `Clone` for this type
...
LL | let old = self.return_value(offset);
| ------ you could clone this value
```
When encountering a bound coming from a derive macro, suggest manual impl of the trait.
Use the span for the specific param when adding bounds in builtin derive macros, so the diagnostic will point at them as well as the derive macro itself.
```
note: required for `Id<SomeNode>` to implement `PartialEq`
--> $DIR/derive-implicit-bound.rs:5:10
|
LL | #[derive(PartialEq, Eq)]
| ^^^^^^^^^
LL | pub struct Id<T>(PhantomData<T>);
| - unsatisfied trait bound introduced in this `derive` macro
= help: consider manually implementing `PartialEq` to avoid undesired bounds
```
Mention that the trait could be manually implemented in E0599.
Fixrust-lang/rust#108894. Address rust-lang/rust#143714. Address #rust-lang/rust#146515 (but ideally would also suggest constraining the fn bound correctly as well).
