Drop an unnecessary intermediate variable
Neither does it shorten the code nor does it provide a helpful name.
`@rustbot` modify labels +C-cleanup +T-compiler
r? `@varkor`
GAT/const_generics: Allow with_opt_const_param to return GAT param def_id
Fixes#75415Fixes#79666
cc ```@lcnr```
I've absolutely no idea who to r? for this...
Allow casting mut array ref to mut ptr
Allow casting mut array ref to mut ptr
We now allow two new casts:
- mut array reference to mut ptr. Example:
let mut x: [usize; 2] = [0, 0];
let p = &mut x as *mut usize;
We allow casting const array references to const pointers so not
allowing mut references to mut pointers was inconsistent.
- mut array reference to const ptr. Example:
let mut x: [usize; 2] = [0, 0];
let p = &mut x as *const usize;
This was similarly inconsistent as we allow casting mut references to
const pointers.
Existing test 'vector-cast-weirdness' updated to test both cases.
Fixes#24151
Reduce log level used by tracing instrumentation from info to debug
Restore log level to debug to avoid make info log level overly verbose (the uses of instrument attribute modified there, were for the most part a replacement for `debug!`; one use was novel).
We now allow two new casts:
- mut array reference to mut ptr. Example:
let mut x: [usize; 2] = [0, 0];
let p = &mut x as *mut usize;
We allow casting const array references to const pointers so not
allowing mut references to mut pointers was inconsistent.
- mut array reference to const ptr. Example:
let mut x: [usize; 2] = [0, 0];
let p = &mut x as *const usize;
This was similarly inconsistent as we allow casting mut references to
const pointers.
Existing test 'vector-cast-weirdness' updated to test both cases.
Fixes#24151
Rename HIR UnOp variants
This renames the variants in HIR UnOp from
enum UnOp {
UnDeref,
UnNot,
UnNeg,
}
to
enum UnOp {
Deref,
Not,
Neg,
}
Motivations:
- This is more consistent with the rest of the code base where most enum
variants don't have a prefix.
- These variants are never used without the `UnOp` prefix so the extra
`Un` prefix doesn't help with readability. E.g. we don't have any
`UnDeref`s in the code, we only have `UnOp::UnDeref`.
- MIR `UnOp` type variants don't have a prefix so this is more
consistent with MIR types.
- "un" prefix reads like "inverse" or "reverse", so as a beginner in
rustc code base when I see "UnDeref" what comes to my mind is
something like `&*` instead of just `*`.
This renames the variants in HIR UnOp from
enum UnOp {
UnDeref,
UnNot,
UnNeg,
}
to
enum UnOp {
Deref,
Not,
Neg,
}
Motivations:
- This is more consistent with the rest of the code base where most enum
variants don't have a prefix.
- These variants are never used without the `UnOp` prefix so the extra
`Un` prefix doesn't help with readability. E.g. we don't have any
`UnDeref`s in the code, we only have `UnOp::UnDeref`.
- MIR `UnOp` type variants don't have a prefix so this is more
consistent with MIR types.
- "un" prefix reads like "inverse" or "reverse", so as a beginner in
rustc code base when I see "UnDeref" what comes to my mind is
something like "&*" instead of just "*".
Allow Trait inheritance with cycles on associated types take 2
This reverts the revert of #79209 and fixes the ICEs that's occasioned by that PR exposing some problems that are addressed in #80648 and #79811.
For easier review I'd say, check only the last commit, the first one is just a revert of the revert of #79209 which was already approved.
This also could be considered part or the actual fix of #79560 but I guess for that to be closed and fixed completely we would need to land #80648 and #79811 too.
r? `@nikomatsakis`
cc `@Aaron1011`
Improve SIMD type element count validation
Resolvesrust-lang/stdsimd#53.
These changes are motivated by `stdsimd` moving in the direction of const generic vectors, e.g.:
```rust
#[repr(simd)]
struct SimdF32<const N: usize>([f32; N]);
```
This makes a few changes:
* Establishes a maximum SIMD lane count of 2^16 (65536). This value is arbitrary, but attempts to validate lane count before hitting potential errors in the backend. It's not clear what LLVM's maximum lane count is, but cranelift's appears to be much less than `usize::MAX`, at least.
* Expands some SIMD intrinsics to support arbitrary lane counts. This resolves the ICE in the linked issue.
* Attempts to catch invalid-sized vectors during typeck when possible.
Unresolved questions:
* Generic-length vectors can't be validated in typeck and are only validated after monomorphization while computing layout. This "works", but the errors simply bail out with no context beyond the name of the type. Should these errors instead return `LayoutError` or otherwise provide context in some way? As it stands, users of `stdsimd` could trivially produce monomorphization errors by making zero-length vectors.
cc `@bjorn3`
typeck: Emit structured suggestions for tuple struct syntax
And tuple variant syntax, but that didn't fit in the subject :)
Now the fact that these are suggestions is exposed both to the layout
engine and to IDEs and rustfix for automatic application.
And tuple variant syntax, but that didn't fit in the subject :)
Now the fact that these are suggestions is exposed both to the layout
engine and to IDEs and rustfix for automatic application.
Fix non-existent-field ICE for generic fields.
I mentioned this ICE in a chat and it took about 3 milliseconds before `@eddyb` found the problem and said this change would fix it. :)
This also changes one the field types in the related test to one that triggered the ICE.
Fixes#81627.
Fixes#81672.
Fixes#81709.
Cc https://github.com/rust-lang/rust/pull/81480 `@b-naber` `@estebank.`
Remove incorrect `delay_span_bug`
The following code is supposed to compile
```rust
use std::ops::BitOr;
pub trait IntWrapper {
type InternalStorage;
}
impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
Self: Sized,
T: BitOr + BitOr<Output = T>,
{
type Output = Self;
fn bitor(self, _other: Self) -> Self {
todo!()
}
}
```
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Fix (but not close) #80207.
The following code is supposed to compile
```rust
use std::ops::BitOr;
pub trait IntWrapper {
type InternalStorage;
}
impl<T> BitOr for dyn IntWrapper<InternalStorage = T>
where
Self: Sized,
T: BitOr + BitOr<Output = T>,
{
type Output = Self;
fn bitor(self, _other: Self) -> Self {
todo!()
}
}
```
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Fix#80207.
Add a new ABI to support cmse_nonsecure_call
This adds support for the `cmse_nonsecure_call` feature to be able to perform non-secure function call.
See the discussion on Zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Support.20for.20callsite.20attributes/near/223054928).
This is a followup to #75810 which added `cmse_nonsecure_entry`. As for that PR, I assume that the changes are small enough to not have to go through a RFC but I don't mind doing one if needed 😃
I did not yet create a tracking issue, but if most of it is fine, I can create one and update the various files accordingly (they refer to the other tracking issue now).
On the Zulip chat, I believe `@jonas-schievink` volunteered to be a reviewer 💯
This commit adds a new ABI to be selected via `extern
"C-cmse-nonsecure-call"` on function pointers in order for the compiler to
apply the corresponding cmse_nonsecure_call callsite attribute.
For Armv8-M targets supporting TrustZone-M, this will perform a
non-secure function call by saving, clearing and calling a non-secure
function pointer using the BLXNS instruction.
See the page on the unstable book for details.
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
- This allows us add fake information after handling migrations if
needed.
- Capture analysis also priortizes what we see earlier, which means
fake information should go in last.
2229: Fix issues with move closures and mutability
This PR fixes two issues when feature `capture_disjoint_fields` is used.
1. Can't mutate using a mutable reference
2. Move closures try to move value out through a reference.
To do so, we
1. Compute the mutability of the capture and store it as part of the `CapturedPlace` that is written in TypeckResults
2. Restrict capture precision. Note this is temporary for now, to allow the feature to be used with move closures and ByValue captures and might change depending on discussions with the lang team.
- No Derefs are captured for ByValue captures, since that will result in value behind a reference getting moved.
- No projections are applied to raw pointers since these require unsafe blocks. We capture
them completely.
r? `````@nikomatsakis`````
