Add intrinsic to create an integer bitmask from a vector mask
This PR adds a new simd intrinsic: `simd_bitmask(vector) -> unsigned integer` that creates an integer bitmask from a vector mask by extracting one bit of each vector lane.
This is required to implement: https://github.com/rust-lang-nursery/packed_simd/issues/166 .
EDIT: the reason we need an intrinsics for this is that we have to truncate the vector lanes to an `<i1 x N>` vector, and then bitcast that to an `iN` integer (while making sure that we only materialize `i8`, ... , `i64` - that is, no `i1`, `i2`, `i4`, types), and we can't do any of that in a Rust library.
r? @rkruppe
Add error for trailing angle brackets.
Fixes#54521.
This PR adds a error (and accompanying machine applicable
suggestion) for trailing angle brackets on function calls with a
turbofish.
r? @estebank
typeck: remove leaky nested probe during trait object method resolution
addresses #57673 (but not marking with f-x because thats now afflicting beta channel).
Fix#57216
Remove unnecessary dummy span checks
The emitter already verifies wether a given span note or span label
can be emitted to the output. If it can't, because it is a dummy
span, it will be either elided for labels or emitted as an unspanned
note/help when applicable.
Add signed num::NonZeroI* types
Multiple people have asked for them in https://github.com/rust-lang/rust/issues/49137. Given that the unsigned ones already exist, they are very easy to add and not an additional maintenance burden.
This commit extends the trailing `>` detection to also work for paths
such as `Foo::<Bar>>:Baz`.
This involves making the existing check take the token that is expected
to follow the path being checked as a parameter.
Care is taken to ensure that this only happens on the construction of a
whole path segment and not a partial path segment (during recursion).
Through this enhancement, it was also observed that the ordering of
right shift token and greater than tokens was overfitted to the examples
being tested.
In practice, given a sequence of `>` characters: `>>>>>>>>>`
..then they will be split into `>>` eagerly: `>> >> >> >> >`.
..but when a `<` is prepended, then the first `>>` is split:
`<T> > >> >> >> >`
..and then when another `<` is prepended, a right shift is first again:
`Vec<<T>> >> >> >> >`
In the previous commits, a example that had two `<<` characters was
always used and therefore it was incorrectly assumed that `>>` would
always be first - but when there is a single `<`, this is not the case.
The diagnostic for this error prints `the following implementations
were found` followed by the first N relevant impls, sorted.
This commit makes the sort happen before slicing,
so that the set of impls being printed is deterministic
when the input is not.
Add "dereference boxed value" suggestion.
Contributes to #57741.
This PR adds a `help: consider dereferencing the boxed value` suggestion to discriminants of match statements when the match arms have type `T` and the discriminant has type `Box<T>`.
r? @estebank
Suggest correct cast for struct fields with shorthand syntax
```
error[E0308]: mismatched types
--> $DIR/type-mismatch-struct-field-shorthand.rs:8:19
|
LL | let _ = RGB { r, g, b };
| ^ expected f64, found f32
help: you can cast an `f32` to `f64` in a lossless way
|
LL | let _ = RGB { r: r.into(), g, b };
| ^^^^^^^^^^^
```
Fix#52497.
Continue parsing after parent type args and suggest using angle brackets
```
error[E0214]: parenthesized parameters may only be used with a trait
--> $DIR/E0214.rs:2:15
|
LL | let v: Vec(&str) = vec!["foo"];
| ^^^^^^
| |
| only traits may use parentheses
| help: use angle brackets instead: `<&str>`
```
r? @zackmdavis
Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`
This is from this [comment](https://github.com/rust-lang/rust/issues/33417#issuecomment-447111156) I made.
This will expand the impls available for `TryFrom` and `TryInto`, without losing anything in the process.
The emitter already verifies wether a given span note or span label
can be emitted to the output. If it can't, because it is a dummy
span, it will be either elided for labels or emitted as an unspanned
note/help when applicable.
This commit adds a `help: consider dereferencing the boxed value`
suggestion to discriminants of match statements when the match arms have
type `T` and the discriminant has type `Box<T>`.
Attempt to recover from parse errors while parsing a struct's literal fields
by skipping tokens until a comma or the closing brace is found. This allows
errors in other fields to be reported.
