Add alignment parameter to `simd_masked_{load,store}`
This PR adds an alignment parameter in `simd_masked_load` and `simd_masked_store`, in the form of a const-generic enum `core::intrinsics::simd::SimdAlign`. This represents the alignment of the `ptr` argument in these intrinsics as follows
- `SimdAlign::Unaligned` - `ptr` is unaligned/1-byte aligned
- `SimdAlign::Element` - `ptr` is aligned to the element type of the SIMD vector (default behavior in the old signature)
- `SimdAlign::Vector` - `ptr` is aligned to the SIMD vector type
The main motive for this is stdarch - most vector loads are either fully aligned (to the vector size) or unaligned (byte-aligned), so the previous signature doesn't cut it.
Now, stdarch will mostly use `SimdAlign::Unaligned` and `SimdAlign::Vector`, whereas portable-simd will use `SimdAlign::Element`.
- [x] `cg_llvm`
- [x] `cg_clif`
- [x] `miri`/`const_eval`
## Alternatives
Using a const-generic/"const" `u32` parameter as alignment (and we error during codegen if this argument is not a power of two). This, although more flexible than this, has a few drawbacks
- If we use an const-generic argument, then portable-simd somehow needs to pass `align_of::<T>()` as the alignment, which isn't possible without GCE
- "const" function parameters are just an ugly hack, and a pain to deal with in non-LLVM backends
We can remedy the problem with the const-generic `u32` parameter by adding a special rule for the element alignment case (e.g. `0` can mean "use the alignment of the element type), but I feel like this is not as expressive as the enum approach, although I am open to suggestions
cc `@workingjubilee` `@RalfJung` `@BoxyUwU`
Tweak output of missing lifetime on associated type
Follow up to https://github.com/rust-lang/rust/pull/135602.
Previously we only showed the trait's assoc item if the trait was local, because we were looking for a small span only for the generics, which we don't have for foreign traits. We now use `def_span` for the item, so we at least provide some context, even if its span is too wide.
```
error[E0195]: lifetime parameters or bounds on type `IntoIter` do not match the trait declaration
--> tests/ui/lifetimes/missing-lifetime-in-assoc-type-4.rs:7:18
|
7 | type IntoIter<'a> = std::collections::btree_map::Values<'a, i32, T>;
| ^^^^ lifetimes do not match type in trait
|
::: /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:292:5
|
292 | type IntoIter: Iterator<Item = Self::Item>;
| ------------------------------------------ lifetimes in impl do not match this type in trait
```
Given an associated item that needs a named lifetime, look at the enclosing `impl` item for one. If there is none, look at the self type and the implemented trait to see if either of those has an anonimous lifetime. If so, suggest adding a named lifetime.
```
error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $DIR/missing-lifetime-in-assoc-type-2.rs:5:17
|
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
help: add a lifetime to the impl block and use it in the self type and associated type
|
LL ~ impl<'a> IntoIterator for &'a S {
LL ~ type Item = &'a T;
|
```
Move the previous long message to a note and use a shorter primary message:
```
error: missing lifetime in associated type
--> $DIR/missing-lifetime-in-assoc-type-1.rs:9:17
|
LL | impl<'a> IntoIterator for &S {
| ---- there is a named lifetime specified on the impl block you could use
...
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
note: in the trait the associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL
help: consider using the lifetime from the impl block
|
LL | type Item = &'a T;
| ++
```
r? `@Nadrieril`
Stabilize `fmt::from_fn`
Resolvesrust-lang/rust#146705, pending its FCP.
As discussed in that tracking issue and rust-lang/rust#117729, this splits `fmt::from_fn` out from the `debug_closure_helpers` feature.
Previously we only showed the trait's assoc item if the trait was local, because we were looking for a small span only for the generics, which we don't have for foreign traits. We now use `def_span` for the item, so we at least provide some context, even if its span is too wide.
```
error[E0195]: lifetime parameters or bounds on type `IntoIter` do not match the trait declaration
--> tests/ui/lifetimes/missing-lifetime-in-assoc-type-4.rs:7:18
|
7 | type IntoIter<'a> = std::collections::btree_map::Values<'a, i32, T>;
| ^^^^ lifetimes do not match type in trait
|
::: /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:292:5
|
292 | type IntoIter: Iterator<Item = Self::Item>;
| ------------------------------------------ lifetimes in impl do not match this type in trait
```
Implement pin-project in pattern matching for `&pin mut|const T`
This PR implements part of rust-lang/rust#130494. It supports pin-project in pattern matching for `&pin mut|const T`.
~Pin-projection by field access (i.e. `&pin mut|const place.field`) is not fully supported yet since pinned-borrow is not ready (rust-lang/rust#135731).~
CC ``````@traviscross``````
```
error[E0207]: the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates
--> $DIR/missing-lifetime-in-assoc-type-1.rs:4:6
|
LL | impl<'a> IntoIterator for &S {
| ^^ unconstrained lifetime parameter
|
help: consider using the named lifetime here instead of an implict lifetime
|
LL | impl<'a> IntoIterator for &'a S {
| ++
```
Constify trait aliases
Allow `const trait Foo = Bar + [const] Baz;` trait alias declarations. Their rules are the same as with super traits of const traits. So `[const] Baz` or `const Baz` is only required for `[const] Foo` or `const Foo` bounds respectively.
tracking issue rust-lang/rust#41517 (part of the general trait alias feature gate, but I can split it out into a separate const trait alias feature gate. I just assumed that const traits would stabilize before trait aliases, and we'd want to stabilize trait aliases together with const trait aliases at the same time)
r? ``@compiler-errors`` ``@fee1-dead``
Emit delayed bug during wfck for stranded opaque
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/235
## Problem
The fundamental issue here is ``OpaqueTypeCollector`` operates on ``rustc_middle::Ty``, but ``check_type_wf`` operates on HIR.
Since [check_type_wf](2f7620a5cc/compiler/rustc_hir_analysis/src/check/wfcheck.rs (L2262)) operates on HIR, it can see the stranded opaque and tries to infer it's hidden type. But ``OpaqueTypeCollector`` operates on ``rustc_middle::Ty``, so the ``OpaqueTypeCollector`` can no longer see a stranded opaque, hence its hidden type could not be inferred.
As a result, the tests ICE'ed at 34a8c7368c/compiler/rustc_hir_analysis/src/collect/type_of/opaque.rs (L253)
## Proposed solution
This PR detects stranded opaque types during wf check and emit a delayed bug for it.
## Alternative solution
`@BoxyUwU` and I had considered rewriting ``OpaqueTypeCollector`` to be a HIR visitor instead of a ``rustc_middle::Ty`` visitor, but we believe a HIR-based ``OpaqueTypeCollector`` will not work and might not worth the cost of rewriting.
## Acknowledgement
This PR is a joint effort with `@BoxyUwU` :3
Default sizedness bounds were not being added to
`explicit_super_predicates_of` and `explicit_implied_predicates_of`
which meant that a trait bound added to a associated type projection
would be missing the implied predicate of the default sizedness
supertrait of that trait.
An unexpected consequence of this change was that the check for multiple
principals was now finding an additional `MetaSized` principal when
eagerly expanding trait aliases. Instead of special-casing trait aliases
as different from traits and not adding a `MetaSized` supertrait to trait
aliases, filter out `MetaSized` when lowering `dyn Trait`.
Further tighten up relaxed bounds
Follow-up to rust-lang/rust#142693, rust-lang/rust#135331 and rust-lang/rust#135841.
Fixesrust-lang/rust#143122.
* Reject relaxed bounds `?Trait` in the bounds of trait aliases.
Just like `trait Trait {}` doesn't mean `trait Trait: Sized {}` and we therefore reject `trait Trait: ?Sized {}`, `trait Trait =;` (sic!) doesn't mean `trait Trait = Sized;` (never did!) and as a logical consequence `trait Trait = ?Sized;` is meaningless and should be forbidden.
* Don't permit `?Sized` in more places (e.g., supertrait bounds, trait object types) if feature `more_maybe_bounds` is enabled.
That internal feature is only meant to allow the user to define & use *new* default traits (that have fewer rules to follow for now to ease experimentation).
* Unconditionally check that the `Trait` in `?Trait` is a default trait.
Previously, we would only perform this check in selected places which was very brittle and led to bugs slipping through.
* Slightly improve diagnostics.
Guard HIR lowered contracts with `contract_checks`
Refactor contract HIR lowering to ensure no contract code is executed when contract-checks are disabled.
The call to `contract_checks` is moved to inside the lowered fn body, and contract closures are built conditionally, ensuring no side-effects present in contracts occur when those are disabled. This partially addresses rust-lang/rust#139548, i.e. the bad behavior no longer happens with contract checks disabled (`-Zcontract-checks=no`).
The change is made in preparation for adding contract variable declarations - variables declared before the `requires` assertion, and accessible from both `requires` and `ensures`, but not in the function body (PR rust-lang/rust#144444). As those declarations may also have side-effects, it's good to guard them with `contract_checks` - the new lowering approach allows for this to be done easily.
Contracts tracking issue: rust-lang/rust#128044
**Known limiatations**:
- It is still possible to early return from the *function* from within a contract, e.g.
```rust
#[ensures({if x > 0 { return 0 }; |_| true})]
fn foo(x: u32) -> i32 {
42
}
```
When `foo` is called with an argument greater than 0, instead of `42`, `0` will be returned.
As this is not a regression, it is not addressed in this PR. However, it may be worth revisiting later down the line, as users may expect a form of early return from *contract specifications*, and so returning from the entire *function* could cause confusion.
- ~Contracts are still not optimised out when disabled. Currently, even when contracts are disabled, the code generated causes existing optimisations to fail, meaning even disabled contracts could impact runtime performance. This issue is blocking rust-lang/rust#136578, and has not been addressed in this PR, i.e. the `mir-opt` and `codegen` tests that fail in rust-lang/rust#136578 still fail with these new HIR lowering changes.~ Contracts should now be optimised out when disabled, however some regressions tests still need to be added to be sure that is indeed the case.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#144266 (Supress swapping lhs and rhs in equality suggestion in extern macro )
- rust-lang/rust#147471 (Assert that non-extended temporaries and `super let` bindings have scopes)
- rust-lang/rust#147533 (Renumber return local after state transform)
- rust-lang/rust#147566 (rewrite outlives placeholder constraints to outlives static when handling opaque types)
- rust-lang/rust#147613 (Make logging filters work again by moving EnvFilter into its own layer)
- rust-lang/rust#147615 (reduce calls to attr.span() in old doc attr parsing)
- rust-lang/rust#147636 (miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Assert that non-extended temporaries and `super let` bindings have scopes
This PR clarifies a point of confusion in the compiler: all bodies have an outer temporary drop scope, including `static` and `const` item bodies[^1]. Whenever a temporary should be dropped in its enclosing temporary scope, it should have a temporary scope to be dropped in so that its drop can be scheduled[^2]. As such, I've updated some relevant comments and made `ScopeTree::default_temporary_scope` and `RvalueScopes::temporary_scope` panic when an enclosing temporary scope isn't found instead of allowing potential bugs where potentially-drop-sensitive temporaries are effectively given static lifetimes.
Since non-extended `super let` bindings are dropped in their block's enclosing temporary scope, this applies to them as well: the enclosing temporary scope should exist.
[^1]: See https://github.com/rust-lang/rust/blob/master/compiler/rustc_hir_analysis/src/check/region.rs#L773-L778 for non-`fn`/closure bodies. The `this.cx.var_parent = None;` enables [lifetime extension to `'static` lifetimes](https://doc.rust-lang.org/stable/reference/destructors.html#r-destructors.scope.lifetime-extension.static) and the `ScopeData::Destruction` scope ensures non-extended temporaries are dropped in the body expression's scope.
[^2]: For certain borrowed temporaries, drops that don't require running destructors may later be removed by constant promotion. That is unrelated to this PR.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#147514 (repr_transparent_external_private_fields: normalize types during traversal)
- rust-lang/rust#147605 (Add doc links between `{integer}::from_str_radix` and `from_str`)
- rust-lang/rust#147608 (cg_llvm: Use `LLVMDIBuilderCreateGlobalVariableExpression`)
- rust-lang/rust#147623 (Clear `ChunkedBitSet` without reallocating)
- rust-lang/rust#147625 (Add a warning when running tests with the GCC backend and debug assertions are enabled)
- rust-lang/rust#147626 (Generalize configuring LLD as the default linker in bootstrap)
r? `@ghost`
`@rustbot` modify labels: rollup
repr_transparent_external_private_fields: normalize types during traversal
Determining whether a type is a 1-ZST will internally do full normalization, so we better do the same when scanning for non-exhaustive types.
r? ``@lcnr``
Split overlapping_{inherent,trait}_impls
This yielded some perf improvement for me. Reduces some calls to `impl_trait_header` query. But I think the llvm optimization is more relevant.
The contract_checks compiler flag is now used to determine
if runtime contract checks should be enabled, as opposed
to the compiler intrinsic as previously.
Refactor contract HIR lowering to ensure no contract code is
executed when contract-checks are disabled.
The call to contract_checks is moved to inside the lowered fn
body, and contract closures are built conditionally, ensuring
no side-effects present in contracts occur when those are disabled.
cmse: improve error messages
tracking issue: https://github.com/rust-lang/rust/issues/81391
tracking issue: https://github.com/rust-lang/rust/issues/75835
Improves the cmse error messages (e.g. by using more accurate spans), and attempts to clean up the control flow a bit. This is partially in preparation for one final addition: warnings when `union` types or types with niches cross the security boundary. That will be a folllow-up.
Meant to be reviewed commit-by-commit
r? ``@davidtwco``
