This should mitigate having the inliner decide not to inline when
the architecture is lacking an implementation of
TargetTransformInfo::areInlineCompatible aware of the target
features (e.g. PowerPC as today).
Fix unset e_flags in ELF files generated for AVR targets
Closes#106576
~~Sort-of blocked by gimli-rs/object#500~~ (merged)
I'm not sure whether the list of AVR CPU names is okay here. Maybe it could be moved out-of-line to improve the readability of the function.
Use structured suggestion when telling user about `for<'a>`
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
Encode item bounds for `DefKind::ImplTraitPlaceholder`
This was lost in a refactoring -- `hir::ItemKind::OpaqueTy` doesn't always map to `DefKind::Opaque`, specifically for RPITITs, so the check was migrated subtly wrong, and unfortunately I never had a test for this 🙃Fixes#113155
r? ``@cjgillot``
Account for late-bound vars from parent arg-position impl trait
We should be reporting an error like we do for late-bound args coming from a parent APIT.
Fixes#113016
suggest `slice::swap` for `mem::swap(&mut x[0], &mut x[1])` borrowck error
Recently saw someone ask why this code (example slightly modified):
```rs
fn main() {
let mut foo = [1, 2];
std::mem::swap(&mut foo[0], &mut foo[1]);
}
```
triggers this error and how to fix it:
```
error[E0499]: cannot borrow `foo[_]` as mutable more than once at a time
--> src/main.rs:4:33
|
4 | std::mem::swap(&mut foo[0], &mut foo[1]);
| -------------- ----------- ^^^^^^^^^^^ second mutable borrow occurs here
| | |
| | first mutable borrow occurs here
| first borrow later used by call
|
= help: consider using `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices
```
The current help message is nice and goes in the right direction, but I think we can do better for this specific instance and suggest `slice::swap`, which makes this compile
Stabilize `const_cstr_methods`
This PR seeks to stabilize `const_cstr_methods`. Fixes most of #101719
## New const stable API
```rust
impl CStr {
// depends: memchr
pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, FromBytesWithNulError> {...}
// depends: const_slice_index
pub const fn to_bytes(&self) -> &[u8] {}
// depends: pointer casts
pub const fn to_bytes_with_nul(&self) -> &[u8] {}
// depends: str::from_utf8
pub const fn to_str(&self) -> Result<&str, str::Utf8Error> {}
}
```
I don't think any of these methods will have any issue when `CStr` becomes a thin pointer as long as `memchr` is const (which also allows for const `strlen`) .
## Notes
- `from_bytes_until_nul` relies on `const_slice_index`, which relies on `const_trait_impls`, and generally this should be avoided. After talking with Oli, it should be OK in this case because we could replace the ranges with pointer tricks if needed (worst case being those feature gates disappear). https://github.com/rust-lang/rust/pull/107624#discussion_r1101468480
- Making `from_ptr` const is deferred because it depends on `const_eval_select`. I have moved this under the new flag `const_cstr_from_ptr` https://github.com/rust-lang/rust/pull/107624#discussion_r1101555239
cc ``@oli-obk`` I think you're the const expert
``@rustbot`` modify labels: +T-libs-api +needs-fcp
[significant_drop_tightening] Fix#10413Fix#10413
This is quite a rewrite that unfortunately took a large amount of time. I tried my best to comment what is going on to easy review but feel free to ask any question.
The problem basically is that the current algorithm is only taking into consideration single blocks which means that things like the following don't work or show unpredictable results.
```rust
let mutex = Mutex::new(1);
{
let lock = mutex.lock().unwrap();
{
let _ = *lock;
}
}
```
The solve the issue, each path that refers a lock is now being tracked individually.
```
changelog: [`significant_drop_tightening`]: Lift the restriction of only considerate single blocks
```
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
New lint [`redundant_at_rest_pattern`]
Closes#11011
It's always a great feeling when a new lint triggers on clippy itself 😄
changelog: New lint [`redundant_at_rest_pattern`]
Currently, this won't change anything, because we only have one relevant workflow (`CI`), but for future proofing we should probably include the workflow name in the concurrency group.
