The overflow-checking attempts to accommodate early evaluation where
we do not have type information yet.
Also, add fixme note about something that has been bothering me.
Many of the modifications putting in `Box::new` calls also include a
pointer to Issue 22405, which tracks going back to `box <expr>` if
possible in the future.
(Still tried to use `Box<_>` where it sufficed; thus some tests still
have `box_syntax` enabled, as they use a mix of `box` and `Box::new`.)
Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
1. Detect and report arithmetic overflow during const-expr eval.
2. Instead `eval_const_expr_partial` returning `Err(String)`, it now
has a dedicated enum of different cases. The main benefit of this
is the ability to pass along an interpretable payload, namely the
two inputs that caused an overlfow.
I attempted to minimize fallout to error output in tests, but some was
unavoidable. Those changes are in a follow-on commit.
This only replaces the conditional arith-overflow asserts with
unconditional errors from the guts of const-eval; it does *not*
attempt to sanely handle such errors e.g. with a nice error message
from `rustc`. So the same test that led me to add this commit are
still failing, and must be addressed.
There's been some debate over the precise form that these APIs should take, and
they've undergone some changes recently, so these APIs are going to be left
unstable for now to be fleshed out during the next release cycle.
macro_rules! is like an item that defines a macro. Other items don't have a
trailing semicolon, or use a paren-delimited body.
If there's an argument for matching the invocation syntax, e.g. parentheses for
an expr macro, then I think that applies more strongly to the *inner*
delimiters on the LHS, wrapping the individual argument patterns.
This commit is an implementation of [RFC 503][rfc] which is a stabilization
story for the prelude. Most of the RFC was directly applied, removing reexports.
Some reexports are kept around, however:
* `range` remains until range syntax has landed to reduce churn.
* `Path` and `GenericPath` remain until path reform lands. This is done to
prevent many imports of `GenericPath` which will soon be removed.
* All `io` traits remain until I/O reform lands so imports can be rewritten all
at once to `std::io::prelude::*`.
This is a breaking change because many prelude reexports have been removed, and
the RFC can be consulted for the exact list of removed reexports, as well as to
find the locations of where to import them.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0503-prelude-stabilization.md
[breaking-change]
Closes#20068
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes#18635.
[breaking-change]
