adds simd_select intrinsic
The select SIMD intrinsic is used to select elements from two SIMD vectors using a mask:
```rust
let mask = b8x4::new(true, false, false, true);
let a = f32x4::new(1., 2., 3., 4.);
let b = f32x4::new(5., 6., 7., 8.);
assert_eq!(simd_select(mask, a, b), f32x4::new(1., 6., 7., 4.));
```
The number of lanes between the mask and the vectors must match, but the vector width of the mask does not need to match that of the vectors. The mask is required to be a vector of signed integers.
Note: this intrinsic will be exposed via `std::simd`'s vector masks - users are not expected to use it directly.
Stabilize the copy_closures and clone_closures features
In addition to the `Fn*` family of traits, closures now implement `Copy` (and similarly `Clone`) if all of the captures do.
Tracking issue: https://github.com/rust-lang/rust/issues/44490
Stabilize termination_trait, split out termination_trait_test
For #48453.
First time contribution, so I'd really appreciate any feedback on how this PR can be better.
Not sure exactly what kind of documentation update is needed. If there is no PR to update the reference, I can try doing that this week as I have time.
Improve lint for type alias bounds
First of all, I learned just today that I was wrong assuming that the bounds in type aliases are entirely ignored: It turns out they are used to resolve associated types in type aliases. So:
```rust
type T1<U: Bound> = U::Assoc; // compiles
type T2<U> = U::Assoc; // fails
type T3<U> = <U as Bound>::Assoc; // "correct" way to write this, maybe?
```
I am sorry for creating this mess.
This PR changes the wording of the lint accordingly. Moreover, since just removing the bound is no longer always a possible fix, I tried to detect cases like `T1` above and show a helpful message to the user:
```
warning: bounds on generic parameters are not enforced in type aliases
--> $DIR/type-alias-bounds.rs:57:12
|
LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases
| ^^^^^
|
= help: the bound will not be checked when the type alias is used, and should be removed
help: use absolute paths (i.e., <T as Trait>::Assoc) to refer to associated types in type aliases
--> $DIR/type-alias-bounds.rs:57:21
|
LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases
| ^^^^^^^^
```
I am not sure if I got this entirely right. Ideally, we could provide a suggestion involving the correct trait and type name -- however, while I have access to the HIR in the lint, I do not know how to get access to the resolved name information, like which trait `Assoc` belongs to above. The lint does not even run if that resolution fails, so I assume that information is available *somewhere*...
This is a follow-up for (parts of) https://github.com/rust-lang/rust/pull/48326. Also see https://github.com/rust-lang/rust/issues/21903.
This changes the name of a lint, but that lint was just merged to master yesterday and has never even been on beta.
check stability of macro invocations
I haven't implemented tests yet but this should be a pretty solid prototype. I think as-implemented it will also stability-check macro invocations in the same crate, dunno if we want that or not.
I don't know if we want this to go through `rustc::middle::stability` or not, considering the information there wouldn't be available at the time of macro expansion (even for external crates, right?).
r? @nrc
closes#34079
cc @petrochenkov @durka @jseyfried #38356
Add crate name to "main function not found" error message.
Fixes#44798 and rust-lang/cargo#4948.
I was wondering if it might be cleaner to update the ui tests to add a simple `fn main() {}` for the unrelated tests. Let me know if you would prefer that.
Stabilize inclusive range (`..=`)
Stabilize the followings:
* `inclusive_range` — The `std::ops::RangeInclusive` and `std::ops::RangeInclusiveTo` types, except its fields (tracked by #49022 separately).
* `inclusive_range_syntax` — The `a..=b` and `..=b` expression syntax
* `dotdoteq_in_patterns` — Using `a..=b` in a pattern
cc #28237
r? @rust-lang/lang
Replace feature(never_type) with feature(exhaustive_patterns).
feature(exhaustive_patterns) only covers the pattern-exhaustives checks
that used to be covered by feature(never_type)
Two phase borrows rewrite
This definitely needs a careful review. Both @pnkfelix and @nikomatsakis were involved with the design of this so they're natural choices here. I'm r?'ing @pnkfelix since they wrote the original two-phase borrow implementation. Also ping @KiChjang who expressed interest in working on this. I'm going to leave a few comments below pointing out some of the more dangerous changes I made (i.e. what I would like reviewers to pay special attention too.)
r? @pnkfelix
First of all, the lint is specific for type aliases. Second, it turns out the
bounds are not entirely ignored but actually used when accessing associated
types. So change the wording of the lint, and adapt its name to reality.
The lint has never been on stable or beta, so renaming is safe.
See #48431 for discussion as to why this was necessary and what we hoped to
accomplish. A brief summary:
- the first implementation of 2-phase borrows was hard to limit in the way we
wanted. That is, it was too good at accepting all 2-phase borrows rather than
just autorefs =)
- Numerous diagnostic regressions were introduced by 2-phase borrow support
which were difficult to fix
Warn about ignored generic bounds in `for`
This adds a new lint to fix#42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.
Questions to the reviewer:
* Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!).
* Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`).
* For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in https://github.com/rust-lang/rust/issues/42181#issuecomment-306924389, but I feel that can only happen in a new epoch -- right?
Cc @eddyb
