Addresses issue #22425. See `src/test/compile-fail/macro-incomplete-parse.rs` for a relevant test:
macro-incomplete-parse.rs:15:9: 15:10 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:15 , //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:27:1: 27:17 note: caused by the macro expansion here; the usage of `ignored_item` is likely invalid in this context
macro-incomplete-parse.rs:27 ignored_item!();
^~~~~~~~~~~~~~~~
macro-incomplete-parse.rs:20:14: 20:15 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:20 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:30:5: 30:21 note: caused by the macro expansion here; the usage of `ignored_expr` is likely invalid in this context
macro-incomplete-parse.rs:30 ignored_expr!();
^~~~~~~~~~~~~~~~
macro-incomplete-parse.rs:24:14: 24:15 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:24 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:32:9: 32:23 note: caused by the macro expansion here; the usage of `ignored_pat` is likely invalid in this context
macro-incomplete-parse.rs:32 ignored_pat!() => (),
^~~~~~~~~~~~~~
This does not address the case of improper expansion inside of an impl { } as seen in issue #21607.
I'm not sure if the note text is ideal, but it can be refined if needed.
A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.
This commit reverts to the earlier behavior (while retaining the
refactoring into traits).
Fixes#24095
cc #24014
Statement macros are now treated somewhat like item macros, in that a
statement macro can now expand into a series of statements, rather than
just a single statement.
This allows statement macros to be nested inside other kinds of macros and
expand properly, where previously the expansion would only work when no
nesting was present.
See: src/test/run-pass/macro-stmt_macro_in_expr_macro.rs
src/test/run-pass/macro-nested_stmt_macro.rs
This changes the interface of the MacResult trait. make_stmt has become
make_stmts and now returns a vector, rather than a single item. Plugin
writers who were implementing MacResult will have breakage, as well as
anyone using MacEager::stmt.
See: src/libsyntax/ext/base.rs
This also causes a minor difference in behavior to the diagnostics
produced by certain malformed macros.
See: src/test/compile-fail/macro-incomplete-parse.rs
`Trait`, prefer the object. Also give a nice error for attempts to
manually `impl Trait for Trait`, since they will be ineffectual.
Fixes#24015.
Fixes#24051.
Fixes#24037.
Fixes#23853.
Fixes#21942.
cc #21756.
Fixes#22757Fixes#22972Fixes#23044Fixes#23151Fixes#23597Fixes#23656Fixes#23929
It also fixes some other corner cases in range patterns, like incorrect spans or not accepting global paths after `...`.
It passes `make check` but needs some additional tests (then it will fix#22546 as well), I'll write them today or tomorrow.
There are still some remnants we could remove from the compiler (e.g. references to "subtraitrefs"; traits still have variance entries in the variance table), but this removes all user-visible bits I believe.
r? @pnkfelix
Fixes#22806 (since such traits would no longer exist)
The primary purpose of this PR is to add blanket impls for the `Fn` traits of the following (simplified) form:
impl<F:Fn> Fn for &F
impl<F:FnMut> FnMut for &mut F
However, this wound up requiring two changes:
1. A slight hack so that `x()` where `x: &mut F` is translated to `FnMut::call_mut(&mut *x, ())` vs `FnMut::call_mut(&mut x, ())`. This is achieved by just autoderef'ing one time when calling something whose type is `&F` or `&mut F`.
2. Making the infinite recursion test in trait matching a bit more tailored. This involves adding a notion of "matching" types that looks to see if types are potentially unifiable (it's an approximation).
The PR also includes various small refactorings to the inference code that are aimed at moving the unification and other code into a library (I've got that particular change in a branch, these changes just lead the way there by removing unnecessary dependencies between the compiler and the more general unification code).
Note that per rust-lang/rfcs#1023, adding impls like these would be a breaking change in the future.
cc @japaric
cc @alexcrichton
cc @aturon
Fixes#23015.
const_eval : add overflow-checking for {`+`, `-`, `*`, `/`, `<<`, `>>`}.
One tricky detail here: There is some duplication of labor between `rustc::middle::const_eval` and `rustc_trans::trans::consts`. It might be good to explore ways to try to factor out the common structure to the two passes (by abstracting over the particular value-representation used in the compile-time interpreter).
----
Update: Rebased atop #23841Fix#22531Fix#23030Fix#23221Fix#23235
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes#22985Closes#21069
[breaking-change]
r? @alexcrichton
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Closes#22985Closes#21069
[breaking-change]
Disallow writing through mutable pointers stored in non-mut Box.
Fix#14270
The fix works by making `cmt::freely_aliasable` result more fine-grained.
Instead of encoding the aliasability (i.e. whether the cmt is uniquely writable or not) as an option, now pass back an enum indicating either: 1. freely-aliasable (thus not uniquely-writable), 2. non-aliasable (thus uniquely writable), or 3. unique but immutable (and thus not uniquely writable, according to proposal from issue #14270.)
This is all of course a giant hack that will hopefully go away with an eventually removal of special treatment of `Box<T>` (aka `ty_unique`) from the compiler.
