| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fixes #49841
|
|
|
|
|
|
`()`, not `!`.
Note that this commit, since it is trying to be minimal in order to
ease backporting to the beta and release channels, does *not* include
the old future-proofing warnings that we used to have associated with
such fallback to `()`; see discussion at this comment:
https://github.com/rust-lang/rust/issues/49691#issuecomment-381266730
|
|
This commit is just covering the feature gate itself and the tests
that made direct use of `!` and thus need to opt back into the
feature.
A follow on commit brings back the other change that motivates the
revert: Namely, going back to the old rules for falling back to `()`.
|
|
|
|
r=petrochenkov
Check for known but incorrect attributes
fixes #43988
- Change nested_visit_map so it will recursively check functions
- Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect
inline and repr attributes on staements and expressions
- Add regression test for issue #43988
|
|
|
|
This includes a submodule update to rustfmt
in order to allow a stable feature declaration.
|
|
|
|
|
|
- Change nested_visit_map so it will recusively check functions
- Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect
inline and repr attributes on staements and expressions
- Add regression test for isssue #43988
|
|
|
|
Stabilize impl Trait
Blocked on:
- [x] https://github.com/rust-lang/rust/pull/49041 and
- [ ] completion of FCP in https://github.com/rust-lang/rust/issues/34511#issuecomment-373207183 (3 days from now).
I have not yet done any docs work for this-- I probably won't get to it until this weekend (might be a project for the flight to the all-hands).
|
|
|
|
|
|
|
|
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.
|
|
|
|
Reduce the diagnostic spam when multiple fields are missing in pattern
Fix #47457.
|
|
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.
|
|
In addition to the `Fn*` family of traits, closures now implement `Copy` (and similarly `Clone`) if all of the captures do.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`
|
|
|
|
This stabilizes `main` with non-() return types; see #48453.
|
|
|
|
|
|
Fix `unused_import_braces` lint false positive on `use prefix::{self as rename}`
|
|
add intrinsics for portable packed simd vector reductions
Adds the following portable vector reduction intrinsics:
* fn simd_reduce_add<T, U>(x: T) -> U;
* fn simd_reduce_mul<T, U>(x: T) -> U;
* fn simd_reduce_min<T, U>(x: T) -> U;
* fn simd_reduce_max<T, U>(x: T) -> U;
* fn simd_reduce_and<T, U>(x: T) -> U;
* fn simd_reduce_or<T, U>(x: T) -> U;
* fn simd_reduce_xor<T, U>(x: T) -> U;
I've also added:
* fn simd_reduce_all<T>(x: T) -> bool;
* fn simd_reduce_any<T>(x: T) -> bool;
These produce better code that what we are currently producing in `stdsimd`, but the code is still not optimal due to this LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=36702
r? @alexcrichton
|
|
Properly handle collecting default impls of methods with lifetime parameters.
r? @eddyb
Fixes #47309.
|
|
|
|
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
|
|
Rollup of 17 pull requests
- Successful merges: #48706, #48875, #48892, #48922, #48957, #48959, #48961, #48965, #49007, #49024, #49042, #49050, #48853, #48990, #49037, #49049, #48972
- Failed merges:
|
|
MIPS testsuite fixes
This PR adjusts various bits in the testsuite so that more stuff passes on mips*.
|
|
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
|
|
|
|
Reword E0044 and message for `!Send` types
- Reword E0044 help.
- Change error message for types that don't implement `Send`
CC #45092, #46678, #24909, #33307.
|
