| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`
|
|
|
|
This stabilizes `main` with non-() return types; see #48453.
|
|
|
|
Try to reduce amount of time on the asmjs builder
This PR has two commits for two separate strategies:
* First it disables optimizations for all tests, hopefully saving time by not optimizing the test code. This caused a number of run-pass tests to fail which are switched to being ignored here.
* Next it disables a number of test suites which aren't asm.js specific and already run elsewhere
cc #48826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
Since all tests are compiled with LTO effectively in Emscripten this commit
disables optimizations to hopefully squeeze some more time out of the CI
builders.
Closes #48826
|
|
|
|
Make `assert` a built-in procedural macro
Makes `assert` macro a built-in one without touching its functionality. This is a prerequisite for RFC 2011 (#44838).
|
|
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*.
|
|
|
|
They are disallowed because they have different precedence than
expressions. I assume parenthesis in pattern will be soon stabilized and
thus write that as suggestion directly.
|
|
Stabilize `match 2 { 1..=3 => {} }`.
|
|
Stabilize the syntax `a..=b` and `..=b`.
|
|
Stabilize std::ops::RangeInclusive and std::ops::RangeInclusiveTo.
|
|
|
|
Payload of `Literal` token must be escaped.
Also print printable non-ASCII characters.
|
|
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)
|
|
|
|
Fix hygene issue when deriving Debug
The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".
Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.
This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].
I also checked the implementations of the other built-in derives to
ensure they didn't declare any variables.
|
|
The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".
Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.
This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Better docs and associated SUCCESS/FAILURE for process::ExitCode
Follow-up to https://github.com/rust-lang/rust/pull/48497#discussion_r170676525, since that PR was the minimal thing to unblock https://github.com/rust-lang/rust/issues/48453#issuecomment-368155082.
r? @nikomatsakis
|
|
Stabilize FusedIterator
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
Closes #35602
|
|
Also move the check for not having type parameters into ast_validation.
I was not sure what to do with compile-fail/issue-23046.rs: The issue looks like
maybe the bounds actually played a role in triggering the ICE, but that seems
unlikely given that the compiler seems to entirely ignore them. However, I
couldn't find a testcase without the bounds, so I figured the best I could do is
to just remove the bounds and make sure at least that keeps working.
|
|
Add functions for reversing the bit pattern in an integer
I'm reviving PR #32798 now that the LLVM issues have been resolved.
> This adds the bitreverse intrinsic and adds a reverse_bits function to all integer types.
|
|
Fix spelling s/casted/cast/
r? @GuillaumeGomez
|
