| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Stabilize std::ops::RangeInclusive and std::ops::RangeInclusiveTo.
|
|
- Reword E0044 help.
- Change error message for types that don't implement `Send`
|
|
|
|
|
|
Remove the coerce_never lint and make the behaviour an error.
|
|
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)
|
|
Types will no longer default to `()`, instead always defaulting to `!`.
This disables the associated warning and removes the flag from TyTuple
|
|
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.
|
|
Show the used type variable when issuing a "can't use type parameters from outer function" error message
Fix #14844
r? @estebank
|
|
It seems whatever was causing problems has been fixed.
|
|
|
|
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
|
|
"mov" is not a valid assembly mnemonic on mips.
|
|
|
|
|
|
before they differed depending on whether optimizations were on or not
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
